The Appollo3 targets require dummy sections in stack and heap regions.
The stack dummy section does not contain any symbols. It is only used
for the linker to calculate the size of the stack sections and assign
values to stack symbols later.
The heap dummy region is used to identify the beginning of available dynamic memory.
The heapsize was incorrectly calculated.
This fixes it by subtracting the Stack size, any memory chunks allocated
before the start of the application (for vectors and/or crash report), and
finally the size of the application from the total RAM size.
The stack start address should be the top of the RAM which is also fixed.
Workaround a bug where the boot stack size configuration option is not
passed on to armlink, the Arm Compiler's linker. Prefer
MBED_CONF_TARGET_BOOT_STACK_SIZE if present, as this is what the
configuration system should provide. Fall back to MBED_BOOT_STACK_SIZE
if MBED_CONF_TARGET_BOOT_STACK_SIZE is not defined, as in the case of
buggy tools. If both MBED_CONF_TARGET_BOOT_STACK_SIZE and
MBED_BOOT_STACK_SIZE are not defined, then we fall back to a hard-coded
value provided by the linkerscript. See
#13474 for more information.
Modified the spi_master_block_write() function yet again. SD related examples still read/erase/write the SD cards as expected and with these alterations the power consumption does not remain high after the SPI transaction has been finished. However i still only tested the SD functionality. Please test other SPI scenarios and different sensors as well to find out if this PR introduces unexpected bugs or not.
Changes:
- deleted the whole if (xfer.ui32NumBytes) condition as i did not find it logical (by that i mean xfer.ui32NumBytes was also true within the following else if (tx_length != rx_length){} block, so basically when the 2 buffers had different lengths an extra transfer has been done for nothing)
- removed the bool Rw = (rx_length >= tx_length) as the comparison >= has no sense anymore after if (tx_length == rx_length) on line 159.
Modified line 145: previously the fill character has been hard coded to 0x00. However in Mbed OS core SPI_FILL_CHAR is defined in the core to be 0xFF by default (one can change that through mbed_app.json for example). This mod allows us to use the same fill character that is defined for Mbed OS.
Also modified spi_master_block_write(): previously it called am_hal_iom_blocking_transfer on line 182, but that prevented succesful SD card writing operations. Now i changed that part to am_hal_iom_spi_blocking_fullduplex and SD functionality seems to be working.
George Psimenos
UbiJCC
Hugues Kamba
Martin Kojtal
Wenn0101
kalle16lab
Kalle-Gustav Kruus
Peter B