• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 214 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS570LC4357: Issues executing THUMB instructions in IRQ

Thomas Hickey
Prodigy 70 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

I am currently working on a project and in this project we are using the compile flag "--code_state=16" to compile the project for THUMB instructions. I am running in to an issue where I am entering an IRQ, and upon entering this IRQ the T bit in the CPSR register gets switched from 1 to 0 (THUMB to ARM), but the instructions within this IRQ are still THUMB instructions. Upon executing one of the THUMB instructions (a movs instruction) within the IRQ I get an Undefined Instruction Hard Fault. I am unsure as to whether this is due to trying to execute a THUMB instruction while in ARM mode or if it is because of something else. I have attached an image of the state of the core registers before executing the instruction that causes a hard fault & after the instruction that causes the hard fault. I have also attached a picture of the disassembly of the C code to show exactly what instruction is causing the issue. Any pointers on how to resolve this issue would be greatly appreciated.

Thank you,

Thomas

Before:

After: 

Disassembly:

  • 0
    TI__Guru**** 192486 points

    Hi Thomas,

    The UNDEF exception is caused by a unkown or a undefined instruction. The UNDEF happens at "bl #0x42892" (R14_Undef -2), right? I think the THUMB supports lb instruction.

    From your snapshots, before and after the interrupt, the T bit of CPSR is 0

  • 0 in reply to QJ Wang
    Prodigy 70 points

    According to arm documentation wouldn't the undefined instruction occur at "movs r0, #0" as the J & T bits are both 0 so it would be (R14_Undef - 4)?

    https://developer.arm.com/documentation/ddi0406/cb/System-Level-Architecture/The-System-Level-Programmers--Model/Exception-descriptions/Undefined-Instruction-exception?lang=en

    In addition to this, the pictures I attached in my first post are both in the IRQ. The one labeled "Before" is before executing the instruction that causes the UNDEF, "After" is after executing the instruction that causes the UNDEF. I have attached new pictures to show the state of the CPSR register before entrance of the IRQ & after entrance of the IRQ. As you can see, before entering the IRQ I am in THUMB mode, after entering the IRQ I am in ARM mode.

    Before Entering IRQ:

    After entering IRQ:

  • +1 in reply to Thomas Hickey
    Guru 92251 points
    Thomas Hickey said:
    As you can see, before entering the IRQ I am in THUMB mode, after entering the IRQ I am in ARM mode.

    From a quick-look at Exception entry and exit summary and c1, System Control Register in the Cortex-R5 and Cortex-R5F Technical Reference Manual r1p1, on exception entry:

    The T bit is set based on the state of the TE bit in the SCTLR

    Has your program set the TE bit in the SCTLR, or left it at the reset value?

    Where the reset TE bit value is configured by the primary input TEINIT, which I think TI have strapped to give a reset value so that exceptions are taken in ARM mode.

    While the TE bit in the SCTLR isn't marked as read-only, if changed it will affect all exceptions until the next reset, which I think means you can mix-and-match different exceptions as ARM or THUMB mode.

    Thomas Hickey said:
    I am currently working on a project and in this project we are using the compile flag "--code_state=16" to compile the project for THUMB instructions.

    I think the HALCoGen approach for IRQ handlers is to use a specific pragma to generate the IRQ in ARM mode, and thus override the setting for the reset of the project. E.g.:

    #pragma CODE_STATE(vPortRTOSRunTimeISR, 32)
#pragma INTERRUPT(vPortRTOSRunTimeISR, IRQ)
void vPortRTOSRunTimeISR(void)

    Would a #pragma CODE_STATE(<IRQ_handler>, 32) to cause your IRQs handlers to be in ARM mode solve the problem, or do you need the IRQ handlers to actually run in THUMB mode?

  • 0 in reply to Chester Gillon
    Prodigy 70 points

    Thank you for the information about the TE bit, this is what I was looking for. Yes, I was trying to get the portion of code within the IRQ to execute in THUMB mode as well.