Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
fix rom start & size for CY8CKIT_062_WIFI_BT & CY8CPROTO_062_4343W #11138
This fixes a mistake that was merged to master in #11053
This corrects the flash base address and size, and makes it compatible with the new method that was introduced in 5.13.1 for merging the Cortex M4 and Cortex M0+ images. Essentially, instead of setting the rom start to be the start of the M4 area, it will now be set to the start of the M0+ area which precedes the M4. The linker file handles adding the M0+ area instead of post-build scripts.
This does not fix bootloader support. That will be introduced in a future PR.
This has been tested with CY8CKIT_062_WIFI_BT & CY8CPROTO_062_4343W, using GCC_ARM, and mbed-os-example-blinky. The application starts up fine on each board after this change.
Please merge urgently as this fixes master for these targets and unblocks other PRs.
Pull request type
The mbed_overrides.c file handle situation with the device peripheral initialization if bootloader is enabled (CM4 does it), otherwise - this does CM0+ if bootloader is disabled for the PSA targets.
@hennadiykytsun @vmedcy - This change paves the way for managed bootloader support (for the Cortex M4 application) by providing values that the mbed os build tools use to set and verify the start of flash. It is compatible with the new method that you are using to merge the CM0+. The flow that I believe can work (if logic added to the linker files) is that if building a bootloader (for M4) or application (for M4) that does not plan to use a bootloader, then include the CM0+ area. If building an application that will use a bootloader, then do not include the CM0+ area. If there are different settings in mbed_overrides.c for when building a bootloader or not, then perhaps these can be wrapped in a config macro.