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.
Wenn0101
Hugues Kamba
Martin Kojtal
kalle16lab
Kalle-Gustav Kruus
Peter B