FlsLoader_Write causing sporadic resets

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

cross mob
abhishek1a
Level 1
Level 1
5 likes given 5 questions asked 10 sign-ins


I am working on a bootloader that receives application files over CAN and writes them to flash memory.
Everything was fine until one day; it just could not execute the FlsLoader_Write routine properly anymore.
The controller would reset after writing a few blocks of flash memory. The number of blocks it could write before it failed is inconsistent across download attempts and the different files.

FlsLoader_Write is the function that does the writing to flash memory.
All the calls to FlsLoader_Write are only from one file.
The call to FlsLoader_Write is protected from interrupts by disabling them.
Also, this FlsLoader_Write, along with some other functions, is copied to RAM at init and executed from RAM at runtime.

After some debugging, I ended up with this fix.
Added the #pragma indirect to all the functions of FlsLoader that are placed in RAM. I guessed that calling the RAM functions was a longer jump than expected, so the assembly instruction generated was incorrect. Adding this pragma would let the linker generate the less efficient longer jump statement. This fix solved the problem for a while. As new features were added and the size of the bootloader code grew, this problem came back again. Now I am not sure what to do.

As per the compiler user manual, the linker generates an error if the target address is out of reach ( +/-16MB ). When this happens, use the pragma indirect to generate a less efficient indirect call to the function. But my problem was at runtime, not link time.

I checked the linker and compiler flags used for the build process. All the files use the same settings for Memory Qualifiers
--default-near-size=0
--default-a0-size=0
--default-a1-size=0
It looks like all the qualifiers were already set to be able to use maximum addressing possible.


Why does this problem occur at runtime? Shouldn't the linker throw an error at the linking stage?
Should any other section of the code be using this pragma?

Most importantly, how should I debug this now?

The controller is Aurix 387.
Here is the compiler user manual: http://www.tasking.com/support/tricore/ctc_user_guide_v6.2r2.pdf

0 Likes
1 Solution
Yuva
Moderator
Moderator
Moderator
250 replies posted 250 sign-ins 100 solutions authored

Hello,

As this is part of MC-ISAR which is licensed, we request you to please contact your local Infineon, distributor or software reseller contact.

Thanks.

View solution in original post

0 Likes
1 Reply
Yuva
Moderator
Moderator
Moderator
250 replies posted 250 sign-ins 100 solutions authored

Hello,

As this is part of MC-ISAR which is licensed, we request you to please contact your local Infineon, distributor or software reseller contact.

Thanks.

0 Likes