• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 31 subscribers
  • Views 550 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.

Original question:

CCS/TMS570LC4357: Branch to _c_int00 From Reset Vector is Not Working

TMS570LS3137: Branch Instruction Success Dependent on Target Address

Grayson Halliday
Prodigy 30 points
Part Number: TMS570LS3137

Hello,

I have been observing an issue similar to https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/962007/ccs-tms570lc4357-branch-to-_c_int00-from-reset-vector-is-not-working/3558660?tisearch=e2e-sitesearch&keymatch=branch%25252520%25252526%25252526%25252520alignment#3558660

I have an exception handler written in assembly which is branched to following an exception. 

For context, data aborts are generated as part of our startup self-test routine. During these data aborts, depending on the location of _exception_handler_, one of the following events occurs:

  1. Successfully branches to _exception_handler_.
  2. Rather than branching to _exception_handler_, PC is incremented to the next instruction (phantomEntry). At this point, debugging efforts become unpredictable (nRST causes a reset to a random location - not 0x0, "Resume" operations result in "step" operations, etc.)

Note the screenshots below taken during a failure case.

A) Data abort is thrown.

 

B) Following an "assembly step into" operation, the PC is incremented to the next instruction rather than branching to _exception_handler_.

The documented success/failure cases can be seen below:

_exception_handler_ Address Test Outcome
0x2FB98 FAILS
0x2FB9C FAILS
0x2FBA0 FAILS
0x2FC10 FAILS
0x2FC0C FAILS
0x2FC08 FAILS
0x2FC18 PASSES
0x2FC1C PASSES
0x2FC20 PASSES
0x2FC28 PASSES
0x2FC2C PASSES
0x2FC30 PASSES
0x2FC88 PASSES
0x30B08 PASSES

In addition, I have verified that the branch instruction is correct via the memory browser as well as the output .bin file during both the failure and success cases.

Any input would be greatly appreciated.

Thanks,

Grayson

  • 0
    TI__Guru 69591 points

    Hi Grayson,

    Started working on your thread and will provide an update ASAP.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    TI__Guru 69591 points

    Hi Grayson,

    Can you please do one testing and let me know the status, whether the issue still present or not.

    1. Please delete the debug folder present in your project:

    2. And now select the "clean" build option

    And select the corresponding project to be clean build

    And click on "clean"

    3. Now again do the testing and let me know the result.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 30 points

    Hi Jagadish,

    Unfortunately, this did not resolve the issue.

    I can work around the issue for now by including _exception_handler_ in a region of working flash. However, we would like to have this root-caused prior to project completion.

    Thanks,

    Grayson

  • 0 in reply to Grayson Halliday
    TI__Guru**** 196156 points

    Hi Grayson,

    In you code, is the interrupt handler ( _exception_handler_ ) shared by the exceptions of phantom, undefine, SVC, data abort, prefetch abort？How does the handler determine the source of the exception?

    Can you try another way to branch code to the correct handler address?

    LDR pc, reset_addr
    LDR pc, undefined_addr 
    LDR pc, svc_addr 
    LDR pc, prefetch_abort_addr
    LDR pc, data_abort_addr
    LDR pc, phantom_addr
    LDR pc, [pc,#-0x1b0]
    LDR pc, [pc,#-0x1b0]

    reset_addr: .long _c_int00
    undefined_addr: .long _exception_handler_ 
    svc_addr: .long _exception_handler_ 
    prefetch_abort_addr: .long _exception_handler_ 
    data_abort_addr: .long _exception_handler_ 
    phantom_addr: .long _exception_handler_ 

  • 0 in reply to QJ Wang
    Prodigy 30 points

    Hi QJ,

    How does the handler determine the source of the exception?

    We read the cpsr register to determine the mode. Data aborts and prefetch aborts are handled the same.

    Can you try another way to branch code to the correct handler address?

    This appears to work! I can step through the expected ldr instruction while servicing a data abort. Verified using addresses 0x2FB98 and 0x2FB9C.

    The next question then is why does a branch instruction fail while a load instruction works? Have you been able to reproduce this locally?

    Cheers,

    Grayson

  • 0 in reply to Grayson Halliday
    TI__Guru**** 196156 points

    Hi Grayson,

    Branch instructions contain a signed 2’s complement 24 bit offset. The branch address is PC plus the shifted offset:

    In your example, 

    0xEA000BEFC: the branch address is 0xBEFC<<2 + 0x10+0x8  (PC is 2 words ahead of the current instruction)

    it is 0x2FC08

    If you place the handler to other location, you must change the offset in all the related BL instructions (at 0x08, 0x10, 0x14, etc)

  • 0 in reply to QJ Wang
    Prodigy 30 points

    Hi QJ,

    Thank you for the analysis. However, I'm not sure I understand the root cause.

    If the branch instruction target is 0x2FC08, isn't this the expected behaviour for the above test? During other tests where the exception handler location is moved, shouldn't the branch target resulting from a b _exception_handler_ instruction be calculated dynamically during compilation?

    Thanks,

    Grayson

  • 0 in reply to Grayson Halliday
    TI__Guru 69591 points

    Hi Grayson,

    QJ was on vacation till JAN 2nd, please expect some delay in his reply.

    --
    Thanks & regards,
    Jagadish.