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.

LAUNCHXL2-RM46: Prefetch and data abort with RTOS and interrupts

Part Number: LAUNCHXL2-RM46
Other Parts Discussed in Thread: HALCOGEN

Hi,

I am working with LaunchPad XL2-RM46 and CCS 8.2.0 (compiler for ARM, TI v18.1.5.LTS). I wrote a RTOS based on a simplification of the freeRTOS. This RTOS use only static allocation of the memory and the assembly code for handling the context switching from a task to another one is the same generate by HALCoGen (04.07.00) for a RM46 processor with freeRTOS. I also use the same interrupts (RTI COMP0, SSI and SVC) for handling the RTOS work.

If I use only the RTOS scheduler with its 3 interrupts, everything works fine. I tryed to create 3 tasks, 2 for blinking the two user's LEDs on the board and 1 for suspending a task or trying other task controllers. Everything is OK. When I try to use other interrupts, for example, for handling PWM signals output with the eTPWM module, the code works fine for some cycles and then I have an abort condition. I am having big trouble to find the source of this problem.

The situation looks a bit strange, because when I run (in debug) the application the first time, I usually have a prefetch abort condition after about 22k times the eTPWM interrupt is triggered, but not always. All the other times, I have a data abort error, exactly  after 8188 eTPWM interrupt triggers (there is a counter inside the ISR). I tryed to change the total stack dimension (in the linker file) and the user, IRQ and SVC stacks dimension (updating the _coreInitStackPointer_ function), but it did  not fix the issues (and the counter value is always 8188).

Following the relevant registers values when the data abort interrupt is fired:

PC = 0x00000010 (== position of "B  _dabort" in the interrupt vector)

SP = R13_ABT = 0x08001F00 (== top of the stack "abortSp" fixed inside the _coreInitStackPointer_ function)

LR = R14_ABT = 0x000002B0

R0 = 0xE8FD9800

CP15_DATA_FAULT_STATUS  =  0x00000808 (Reserved value... I don't know the meaning; I checked the Cortex-R4 TRM r1p3, page 129)

CP15_DATA_FAULT_ADDRESS  =  0xE8FD97FC  ( == R0 - 4)

The LR register point to an instruction in the "portSAVE_CONTEXT" assembly function, inlined in the ISR of the RTOS Tick (RTI Comp0 interrupt), here the Disassembly output:

229               portSAVE_CONTEXT
          $C:/*******/src/portAsm.asm:225:247$(), osPortPreemptiveTick():
00000294:   F57FF04F            dsb        sy
00000298:   E92D0001            stmdb      sp!, {r0}
0000029c:   E24DD004            sub        sp, sp, #4
000002a0:   E84D2000            stmda      sp, {sp} ^
000002a4:   E8BD0001            ldm        sp!, {r0}
000002a8:   E9204000            stmdb      r0!, {lr}
000002ac:   E1A0E000            mov        lr, r0
000002b0:   E8BD0001            ldm        sp!, {r0}
000002b4:   E94E7FFF            stmdb      lr, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11, r12, sp, lr} ^
000002b8:   E24EE03C            sub        lr, lr, #0x3c

It is clear that the problem is the access to a prohibited address of the memory (0xE8FD97FC), probably because of a corruption of the stack, but I cannot find when and where the stack is corrupted.

The eTPWM ISR change only the value of some eTPWM registers and of a static global variable, not related with the RTOS.

Any suggestions about how to better investigate this problem? Any idea about what could be the error?

Thanks in advance for any help.

PS. I wrote also the code for a MODBUS RTU communication with the SCI interface, using the support of the DMA and N2HET modules. The application use the same RTOS plus DMA and HET interrupts. The MODBUS communication works fine for some messages, than I have the same issues described before (but with different registers values).

  • I did more tests...
    The self test is disabled.
    The Cortex-R4 doesn't support a hardware nesting of IRQ interrupts, so I tried to set the eTPWM interrupt as FIQ, instead of IRQ. In this way the application seems to work correctly without problems.
    Why is it not working if the eTPWM interrupt type is IRQ, but it does if the type is FIQ? Any idea?

    Thanks
  • Hello,
    Your question is addressed to our expert!

    Best regards,
    Miro
  • Thanks Miro, but I found the source of my problem.

    There was an unwanted call to a SWI inside the ISR handling the OS ticks counter increment. The aim of the call to a SWI was to go in privileged mode, but an ISR is already in privileged mode... So the SWI call was kept pending until the end of the "tick ISR".
    Now it is still not 100% clear the interaction with other ISRs, but probably one of the core registers was corrupted, with a consequent almost unpredictable behavior of the code.
  • Hello,
    I am glad you have solved the problem. Thanks for updating!

    Best regards,
    Miro