• State
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 10 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMS570LS1227: Unexpected _copyAPI2RAM_ assembly function behavior

Jacob Byers
Prodigy 40 points

Part Number: TMS570LS1227

We are developing a product with bootloader + application.  

We have referenced the (SPNA186) SafetyMCUBootloader code, where the sys_core.asm file contains an  assembly function by the name _copyAPI2RAM_. 

 

We've been using this successfully for years, but have recently made some minor modifications to the flash that is written to RAM and have been experiencing a persistent Undefined Abort.  

 

After some debugging, we think we've identified the issue - the _copyAPI2RAM_ function defines 3 constants at the beginning of the function, and during execution those constants are treated as instructions before reaching the true instructions (i.e. copy loop, etc).  Our modifications changed the size of the bytes to be written to flash, which subsequently changed the apparent assembly instructions that size represented.  

 

From what we've found, the solution is to move the definition of those 3 constants, flash_load, flash_run, and flash_size, to the end of the function.  

 

  • 0
    TI__Guru* 77346 points

    Hi Jacob,

    Thanks for bringing this to our notice.

    This seems like a literal pool placement problem inherent to ARM assembly. When constants are defined inline at the beginning of a function, the ARM Cortex-R4 processor's pipeline fetches and attempts to execute those constant values as opcodes. Previously, the specific byte values of your flash size happened to decode into benign or skippable instructions. When you changed the flash size, the new constant values decoded into an undefined instruction, triggering the Undefined Abort

    Moving the constants after the function's return instruction ensures:

    1. The processor never reaches them during normal execution flow
    2. The ldr instructions that reference these constants use PC-relative offsets to read them as data, not execute them as code

    I will verify again and take appropriate action for this.

    --
    Thanks & regards,
    Jagadish.