• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 330 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.

TMS570LS3137: Spurious Data Abort Interrupt with HALCOGEN / FreeRTOS

Fabrice Mousset
Prodigy 80 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN

Tool/software:

Hello,

I have to finish a software based on TMS5730LS3137 + HALCOGEN + FreeRTOS. This software was started by someone else which left the company.

I do not have any experience with this CPU, so it takes me many weeks to understand how it works!

I finally found the root cause of the application spurious crashes, it was a DABT on address 0xFFFFFFB0.

After further research, I saw that this error was raised in FreeRTOS xTaskResumeAll() function. Sometimes, when taskYIELD_IF_USING_PREEMPTION() is called, the CPU is still in user mode!

I changed the routine to check current mode and raise to system mode when required.

Now the software works without any failure.

What I cannot understand, is why sometimes CPU is in user mode at this moment.

Is this a known issue?

  • 0
    Prodigy 80 points

    I have spent a little more time on this issue.

    I saw that the exception is triggered during pvPortMalloc() call (cf. screenshot below):

    This is a wild hack, so I change it to something less "dangerous".

    I changed the definition of portYIELD_WITHIN_API() to this:

    #define portYIELD_WITHIN_API()		{\
    BaseType_t x = (_get_CPSR() & 0x1F); \
    if (x == 0x10) prvRaisePrivilege(); \
    portSYS_SSIR1_REG = portSYS_SSIR1_SSKEY; \
    asm( " DSB " ); asm( " ISB " ); \
    if (x == 0x10) asm( " CPS #0x10"); \
    }

    Now, my application works as expected, but I don't know if it is a good idea or if something else is wrong in my software

  • +1 in reply to Fabrice Mousset
    Prodigy 80 points

    After some exchanges on FreeRTOS Forum, it looks like HALCOGEN generated code is missing MPU_pvPortMalloc() and MPU_vPortFree()!

    Adding those routines solves my issue in a cleaner way (cf https://forums.freertos.org/t/cortexr4-spurious-data-abort-interrupt/22301/16).

    To complete my reply, I had to change a little bit the implementation of `prvRaisePrivilege()`. Because the implementation done by TI always force the switching into System mode!
    I added a simple check, to only switch into System mode when CPU is in User mode (as `MPU_vPortFree()` / `MPU_pvPortMalloc()` may be called for IRQ mode)

    Perhaps HALCOGEN should be updated!