Bootloadable size expands to remaining flash size with custom linker script

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

cross mob
lock attach
Attachments are accessible only for community members.
Hvdbrand
Level 1
Level 1
First solution authored 10 sign-ins 5 sign-ins

Dear all,

We are using a CY8C5868AXI-LP032 on which we have both a bootloader and a bootloadable application. We need to bootloader to check the version and type of the bootloadable application. Therefore, we use a linker script to put the .loadableVersion section at a known memory address. This known memory address is the last row of the bootloadable application. We fixed the start of the bootloadable application at 0xD000 and the total flash size is 0x40000.

This all has been working fine for quite some time, but as our image is increasing in size we encountered an issue. When the .loadableVersion is placed at address 0x1ff00 everything worked fine. However, we increased the .rodata and thereby pushed .loadableVersion just to 0x20000. (I added 56 bytes to push it over the edge.) At this point, BootloaderComponent_ValidateApplication() started to fail (With BootloaderComponent being the Bootloader component that is placed on the TopDesign.  Stepping through the function, showed that the application has a size of 0x33000 bytes,  which together with offset of 0xD000 means that the checksum is calculated over the entire flash including the checksum region. Therefore, the calculated checksum does not match the expected checksum. (When I removed the 56, I saw a size of 0x13000 bytes, which matches the 50 % flash usage reported by PSoC Creator 4.4).

I have tried removing the manual placement of .loadableVersion and this leads to the correct checksum calculation. However, this is not a solution as I can no longer find the application version and type that is to be checked by the bootloader.

I have the suspicion that the checksum calculation (which I expect is done by cyelftool.exe -B etc) is bothered by our custom linker script. Does anybody have a clue how I could adapt the linker script to keep the .loadableVersion section at the expected address in flash (start of last line of bootloadable) while not upsetting the checksum calculation?

I added our customization of the linker script as a zip file. I was unable to upload a file with .ld extension.

0 Likes
1 Solution
Hvdbrand
Level 1
Level 1
First solution authored 10 sign-ins 5 sign-ins

I spent some more time on this with a colleague.

We tried placing the .loadableVersion section at LENGTH(rom) -  3* CY_FLASH_ROW_SIZE.

This failed when doing this at the position where .loadableVersion is located, but succeeded if we put the same linker instructions following the .data section.

Placing the loadableVersion section at LENGTH(rom) -  3* CY_FLASH_ROW_SIZE would be a valid workaround for our case. Are there any limitations to be expected because of the larger flash region that is used? (Maybe longer flashing or more flash wear?)

View solution in original post

0 Likes
2 Replies
Hvdbrand
Level 1
Level 1
First solution authored 10 sign-ins 5 sign-ins

I spent some more time on this with a colleague.

We tried placing the .loadableVersion section at LENGTH(rom) -  3* CY_FLASH_ROW_SIZE.

This failed when doing this at the position where .loadableVersion is located, but succeeded if we put the same linker instructions following the .data section.

Placing the loadableVersion section at LENGTH(rom) -  3* CY_FLASH_ROW_SIZE would be a valid workaround for our case. Are there any limitations to be expected because of the larger flash region that is used? (Maybe longer flashing or more flash wear?)

0 Likes
Alakananda_BG
Moderator
Moderator
Moderator
50 likes received 250 sign-ins 250 replies posted

Hi @Hvdbrand 

 Are there any limitations to be expected because of the larger flash region that is used?

>>We cannot exactly tell what might be the limitation but it may result in longer flashing time since the flash size used is more.

Regards,

Alakananda