FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

What might be the cause of the debugger reporting a double fault when executing the 'svc 0' call to start FreeRTOS on the M4 core of an STM32MP157?

Spamfast
Associate II

‎2021-07-30 01:57 AM

I'm using the 2.1.0 ecosystem with an STM32MP157A-EV1 and am having some problems with running a customized FreeRTOS build on the M4 core while running Linux on the A7s.

I have modifed the linker script so that the code is in SRAM1&SRAM2, resource table & OPENAMP rings & buffers in SRAM3 and data in the rest of SRAM3 and the bss in the RETRAM above the vector table. I'm using FreeRTOS v10.3.1 rather than v10.2.1 that is provided by STM32CubeIDE 1.5.1 & the 1.3.0 FW pack but the port.c code looks the same on both.

My code works fine running in engineering mode with FreeRTOS running my tasks fine. However when I try to use either the built-in STLink on the EV1 or an external Segger J-Trace Pro Cortex-M the system faults when it tries to execute the 'svc 0' call during scheduler start.

If I build a simple dummy FreeRTOS CubeIDE-generated project I can now - after some wrestling with the debuggers - get that to start FreeRTOS okay via Linux.

Any ideas on what else to check would be appreciated.

Labels:
0 Kudos
2 REPLIES 2
Spamfast
Associate II

‎2021-07-30 02:20 AM

To clarify, the problem only occurs when running via Linux i.e. when not running in engineering mode and it only happens for some FreeRTOS builds not every one. A bit vague, yes, but I'm hoping someone else might have had a similar experience and found the fix.

0 Kudos
Spamfast
Associate II

‎2022-06-16 07:18 AM

I worked out what the problem was a while ago. It turns out that the JTAG debugger attaches after the code has begun to run and may be in an ISR when it takes control. I've added some code to delay enabling interrupts (actually the whole start up) for debug builds to give the debugger a chance to attach. This also gets around the non-imdempotent start-up of OPENAMP preventing it from starting again if an attempt to restart it occurs without the Linux rproc tearing its end down first i.e. when stopping the M4 via sysfs.

I've also added the following code to the start of the M4 reset handler to detect if it occurs.

Reset_Handler:
    /*
     * Make sure we're in task mode not handler mode otherwise the system will
     * crash on entry to FreeRTOS. (STM32MP15x issues during debug from Linux
     * start.)
     */
    mrs r0, PSR
    ands r0, #0xff
    beq 1f
    bkpt #0
    b .L_Reset
1:

The .L_Reset subroutine simply resets the CPU.

0 Kudos
Top