- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am using an STM32F412 microcontroller with the CYW43012 and I need to reserve some space in Flash memory to save some non-volatile data.
What is the recommended way to modify the linker script for a WICED project?
My project seems to be using 43xxx_Wi-Fi/WICED/platform/MCU/STM32F4cc/GCC/STM32F412/memory_with_bootloader.ld so I could edit that file, but I would rather contain the changes to my application (which I currently just check out into 43xxx_Wi-Fi/apps) and not change the WICED supplied code.
regards,
Charles
Solved! Go to Solution.
- Tags:
- linker scripts
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As such we don't ask the customer to modify linker script because most of these type of use-cases are usually handled by DCT.
If you insist to find a way with linker script, here is what I do (might not be the perfect CY recommended way)
The below mentioned sequence I have followed for BCM94343WWCD2 (STM32F412 + CYW4343W)
- Migrate to 43xxx_Wi-Fi/WICED/platform/MCU/STM32F4xx/GCC/STM32F412/memory_with_bootloader.ld and add your own section(m_test_2) from APP_DATA section
MEMORY
{
BTLDR_VECTORS (rx) : ORIGIN = 0x08000000, LENGTH = 512
SHARED_API (rx) : ORIGIN = 0x08000200, LENGTH = 512
BTLDR_CODE (rx) : ORIGIN = 0x08000400, LENGTH = 15K
DCT1_FLASH (rx) : ORIGIN = 0x08004000, LENGTH = 16K
DCT2_FLASH (rx) : ORIGIN = 0x08008000, LENGTH = 16K
APP_CODE (rx) : ORIGIN = 0x0800C000, LENGTH = 970K
m_test_2 (rx) : ORIGIN = 0x080FE800, LENGTH = 7K /* test section */
SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 256K
BTLDR_SRAM (rwx) : ORIGIN = 0x2001BC00, LENGTH = 17k /* Boot loader stack at the end. */
}
2. Now migrate to 43xxx_Wi-Fi/WICED/platform/MCU/STM32F4xx/GCC/app_with_bootloader.ld and this before the DISCARD section
.myFlashBufBlock 0x080FE800 :
{
KEEP(*(.myFlashBufSection)) /* keep my variable even if not referenced */
} > m_test_2
/DISCARD/
:
3. Just to run a simple test, I had put one variable in this section from my application and then checked the .map file to validate the same. You can also use readelf for the same validation process.
const unsigned char __attribute__((section (".myFlashBufSection"))) buf[128]="WICED is awesome";
There are other GNU specific help articles which elaborates more on working with the linker script. You can check those if this is what you were not looking for.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can use the application section in DCT to store the non-volatile data. This does not require you to modify the default linker script and you can directly use WICED framework from your application without getting your hands dirty in the linker script.
DCT has various sections, among which, users are recommended to use the APP section only to store some custom non-volatile data. You can check the snip.dct_read_write example to check the implementation and see if that serves the purpose that you were looking for
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I looked at DCT and decided that it was more suited to configuration data that doesn't change often.
I have a value that changes several times a day and must be saved in Flash so that I can always access the last known value. I have an array in Flash and write the last known value to the next free entry in the array. So I only have to worry about erasing the segment and garbage collecting when that array fills up.
Would DCT be appropriate for non-volatile data that changes this often?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, you are correct in assuming that DCT is predominantly used for storing WLAN related configuration data. But the application section of DCT can be re-purposed to suit your use-case. Please let us know if the snip.dct_read_write application is not helpful enough for you to implement your own application with a different array/structure.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks RaktimR_11.
I already have a solution implemented, so I can't really justify spending lots of time trying to understand how DCT works and whether I can use it.
But getting back to my original question (because there will always be situations where your customers need to do this).
What is the recommended way to customise the linker script?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As such we don't ask the customer to modify linker script because most of these type of use-cases are usually handled by DCT.
If you insist to find a way with linker script, here is what I do (might not be the perfect CY recommended way)
The below mentioned sequence I have followed for BCM94343WWCD2 (STM32F412 + CYW4343W)
- Migrate to 43xxx_Wi-Fi/WICED/platform/MCU/STM32F4xx/GCC/STM32F412/memory_with_bootloader.ld and add your own section(m_test_2) from APP_DATA section
MEMORY
{
BTLDR_VECTORS (rx) : ORIGIN = 0x08000000, LENGTH = 512
SHARED_API (rx) : ORIGIN = 0x08000200, LENGTH = 512
BTLDR_CODE (rx) : ORIGIN = 0x08000400, LENGTH = 15K
DCT1_FLASH (rx) : ORIGIN = 0x08004000, LENGTH = 16K
DCT2_FLASH (rx) : ORIGIN = 0x08008000, LENGTH = 16K
APP_CODE (rx) : ORIGIN = 0x0800C000, LENGTH = 970K
m_test_2 (rx) : ORIGIN = 0x080FE800, LENGTH = 7K /* test section */
SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 256K
BTLDR_SRAM (rwx) : ORIGIN = 0x2001BC00, LENGTH = 17k /* Boot loader stack at the end. */
}
2. Now migrate to 43xxx_Wi-Fi/WICED/platform/MCU/STM32F4xx/GCC/app_with_bootloader.ld and this before the DISCARD section
.myFlashBufBlock 0x080FE800 :
{
KEEP(*(.myFlashBufSection)) /* keep my variable even if not referenced */
} > m_test_2
/DISCARD/
:
3. Just to run a simple test, I had put one variable in this section from my application and then checked the .map file to validate the same. You can also use readelf for the same validation process.
const unsigned char __attribute__((section (".myFlashBufSection"))) buf[128]="WICED is awesome";
There are other GNU specific help articles which elaborates more on working with the linker script. You can check those if this is what you were not looking for.