• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 82 subscribers
  • Views 145 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

F29H859TU-Q1: Help debugging linker error #10483-D in project code

Gus Martinez
Mastermind 30261 points

Part Number: F29H859TU-Q1

I'm seeing error below during linking step in my code. 

[9]error #10483-D: unprotected calls from output section "safetyModuleD_codeAPR_Flash" to unprotected symbol "_DebugP_logZone" are not allowed: SECURE_GROUP mismatch; the call is in SECURE_GROUP "CPU1_STACK2_STACK" and the callee is in SECURE_GROUP "sbox_CommonCode_STACK_COMMONCODE"; The linker can not resolve this mismatch because "_DebugP_logZone" uses the stack for arguments and/or return values; relocation type "R_C29_PCREL32" in file "./sdl/sdl_cmpss_ctrip.o" at offset 0x000084 in section ".text.cmpss_test_cmpss_ctrip" with id (6) mapped to output section "safetyModuleD_codeAPR_Flash" represents an unprotected call to unprotected symbol "_DebugP_logZone" in file "./DebugP_freertos.o" in section ".text._DebugP_logZone" with id (4) mapped to output section "CPU1_CommonCodeModule_codeAPR_Flash"

Both secure groups in question are specified in the linker command file as "PUBLIC". My understanding is that the linker would add the necessary trampolines/landing pads to make this call secure. Why is this then an unprotected call error?

linker.cmd snippets:

    SAFETYMODULED_CODEAPR_FLASH         : origin = 0x10029000, length = 0x00003000
                                          SECURE_GROUP(CPU1_STACK2_STACK, PUBLIC,
                                          READS=(SAFETYMODULED_DATAAPR_RO,
                                          SHAREDMEM_PROTECTEDSTATEVARS_APR),
                                          WRITES=(SAFETYMODULED_DATAAPR_RW,
                                          SHAREDMEM_CONTROLVARS_APR,
                                          PERIPHAUTOREGION2,
                                          PERIPHAUTOREGION5,
                                          PERIPHAUTOREGION6,
                                          PERIPHAUTOREGION8,
                                          PERIPHAUTOREGION9,
                                          PERIPHAUTOREGION14,
                                          PERIPHAUTOREGION16,
                                          PERIPHAUTOREGION17,
                                          PERIPHAUTOREGION19,
                                          PERIPHAUTOREGION21,
                                          PERIPHAUTOREGION22,
                                          PERIPHAUTOREGION24,
                                          PERIPHAUTOREGION25,
                                          PERIPHAUTOREGION26,
                                          PERIPHAUTOREGION28))
 
    CPU1_COMMONCODEMODULE_CODEAPR_FLASH : origin = 0x10015000, length = 0x00012000
                                          SECURE_GROUP(sbox_CommonCode_STACK_COMMONCODE, PUBLIC,
                                          READS=(CPU1_COMMONCODEMODULE_DATAAPR_RO),
                                          WRITES=(CPU1_COMMONCODEMODULE_DATAAPR_RW))

 

  • 0
    TI__Mastermind 30261 points

    I received my answer through an separate channel. Documenting here for reference.

    Parameter passing is supported as long as the following restriction from the user guide is kept in mind. https://software-dl.ti.com/codegen/docs/c29clang/rel2_0_0_STS/compiler_manual/security/indexC29.html

     “Functions with variadic arguments or those that pass or return structures and/or non-fundamental types use the stack for storage according to the rules of the C29x ABI. Such functions can’t be the callee of an inter-STACK call because the stack pointer changes.”

    The linker cannot resolve the SECURE_GROUP mismatch because "_DebugP_logZone" uses the stack for arguments and/or return values; To fix this, ensure "_DebugP_logZone" uses only registers for arguments or move it to a compatible SECURE_GROUP.