Recommended way to modify linker script for a WICED application

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
CharlesOram
Level 3
Level 3
First like received Welcome!

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

0 Likes
1 Solution

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)

  1. 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.

View solution in original post

0 Likes
5 Replies
RaktimR_11
Moderator
Moderator
Moderator
500 replies posted 250 replies posted 100 replies posted

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

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?

0 Likes

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.

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?

0 Likes

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)

  1. 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.

0 Likes