vPortSVCHandler crashing on i.MX 6SoloX Cortex-M4

Hi all, Some info about my tools: Microcontroller: i.MX 6SoloX (heterogeneous chip with A9 and M4) Toolchain: ARMGCC with Mingw32 and Cmake FreeRTOS version: 8.0.0 (From the provided BSP by NXP) When starting the scheduler, in prvPortStartFirstTask, the “svc 0” triggers the svc handler. But on entering the handler my debugger reports multiple errors on reading the pxCurrectTCB: Multiple errors reported. 1) Failed to execute MI command: -var-create – * (pxCurrentTCB)->pcTaskName[0] Error message from debugger back end: Cannot access memory at address 0x20005108 2) Unable to create variable object 3) Failed to execute MI command: -data-evaluate-expression (pxCurrentTCB)->pcTaskName[0] Error message from debugger back end: Cannot access memory at address 0x20005108 4) Failed to execute MI command: -var-create – * (pxCurrentTCB)->pcTaskName[0] Error message from debugger back end: Cannot access memory at address 0x20005108 The variables where still accesable before the “svc 0” instruction. I am using the CM4F port that was included in the BSP. I have attached the minimal code that reproduces the issue on my machine.

vPortSVCHandler crashing on i.MX 6SoloX Cortex-M4

However, I would also like to mention that the issue is not 100% reproducable. Sometimes my debugger halts (SIGTRAP) on the “svc 0” command and I’m unable to step over it. Also the actual crashing occurs at the following two lines of code " ldr r3, pxCurrentTCBConst2 n" " ldr r1, [r3] n" Once these two lines are executed the code jumps to 0xDEADBEEE and all my General Registers are set to 0xDEADBEEF. I’m not sure why and how this is caused.

vPortSVCHandler crashing on i.MX 6SoloX Cortex-M4

turns out I was tracking two seperate problems: 1) I added -ggdb to the linker, asm, c and ld flags in my CMakeList. This does not work well with FreeRTOS and the eclipse/segger gdb debugger. Removing these fixed my program (mostly) 2) Sometimes “svd 0” halts the debugger. Why I don’t know. But is is clear that this is a seperate issue.

vPortSVCHandler crashing on i.MX 6SoloX Cortex-M4

Cannot access memory at address 0x20005108
I hope that there will be more usefull answers after mine: but what comes to my mind: have you checked the entire debug properties? Did you indicate exactly the right part? Did you fill in the path the the correct gdb executable ( not a generic one that is in your PATH )? When it executes ldr r3, pxCurrentTCBConst2, is it in thumb mode already? just a few quick guesses…

vPortSVCHandler crashing on i.MX 6SoloX Cortex-M4

have you checked the entire debug properties? Did you indicate exactly the right part?
Yes everything seems to be in order, I have checked the actual command that gets printed in the terminal.
Did you fill in the path the the correct gdb executable ( not a generic one that is in your PATH )?
Yes, I have hardcoded the gdb server and client.
When it executes ldr r3, pxCurrentTCBConst2, is it in thumb mode already?
How can I check wether the cpu is in thumb mode? I am compiling with -mthumb

vPortSVCHandler crashing on i.MX 6SoloX Cortex-M4

I’m not sure these are FreeRTOS issues as such but look more like toolchain issues. I’m not sure what ARMGCC with Mingw32 is exactly, but it sounds like you are developing on a Windows host but not using a native Windows toolchain. You can look up “ARM GCC Launchpad” on Google to find a native toolchain, then try compiling with the simplest of command line options to start with.

vPortSVCHandler crashing on i.MX 6SoloX Cortex-M4

Hi Richard, It was a toolchain issue, apparently the -ggdb option messed everything up. However I still have a seperate issue, which is that I need to completely reset the board (remove the power) if I want to debug more than one time. Here is the ideal workflow: 1) Connect the debugger and step through the program normally 2) Stop the session 3) Connect the debugger and step through the program normally However, step 3 fails and causes an impassible sigtrap on “svc 0” during the second debug session. I suspect that because this is a RAM application some things aren’t reset properly between sessions. But I’m not sure how I can sove this and where I should be looking. I’m currently using ‘reset 0’ during programming and I’m passing the board to the gdb server. So this reset should already be the most optimal for my board. Do you know why it’s not possible for me to start a proper debug session for the second time, without powering down the board in between? Or should I make a sererate issue for this topic?

vPortSVCHandler crashing on i.MX 6SoloX Cortex-M4

No, sorry, don’t know, but normally debug probes enable various different reset options on each connect (hard reset, nRST, soft reset, etc.) so suspect it will be a combination of the reset mode you are using and whatever peculiarities there are in your hardware with regards to the boot sequence (especially between the two cores – is the other core held in reset or is it messing with the core you are debugging?).

vPortSVCHandler crashing on i.MX 6SoloX Cortex-M4

According to segger the debugger first connects to the A9, than to the M4. Te same thing in reverse when disconnecting. When the M4 is halted, the A9 is also halted; but when the M4 is reset, the A9 is not reset. So it could be possible that the A9 is messing with the M4, but I wonder why this is only apperent when executing the “svc 0” command.