Posted on November 15, 2012 at 19:33Hello,
I am new to debugging on the STM32 and I have a STM32L152-EVAL board and I am trying to bring up the new open source version of RTX on this board. My setup is as follows.
This is setup on a Mac running Mountain Lion
STM32L152-EVAL hardware
ST-Link V2 USB dongle (NOT using the onboard ST-Link V1)
gcc toolchain (arm-none-eabi version 4.6.3)
Eclipse/GDB debugger
st-util GDB server (from texane/stlink on github)
CMSIS-RTOS RTX Version 4.51
The problem that I'm having is that when I go to fire up the RTOS, it comes back with an error condition saying that it thinks that the processor is in handler mode (IRQ handler). I look at the CPSR, and sure enough it has a value of 0x1000020 which suggests that it we should be handling the 0x20 interrupt (a DMA channel if I read it right). This is even when I start up from the reset handler. Now this is while I'm debugging with Eclipse/GDB.
Now here is the interesting thing. If I stop the GDB server it goes back to the normal thread mode when I reset the processor. I ASSUME this is because the GDB/ST-Link V2 is using the DMA channel to snoop around memory and such, maybe even connect to the Cortex M3 core itself.
The problem I have is that the RTX kernel wants to check to make sure that it is not in ISR mode, and and I can't start it up because It thinks that it is in ISR mode when I'm running the debugger. This seems true all time, not just when I'm in single step mode.. So it makes it kinda impossible to debug my code.
Any suggestions on how to work around this ?
Since I do have the source for the kernel, one work around may be to accept the one IRQ mode, but that seems like an ugly hack..
Any thoughts ? Also note that I'm using the CMSIS version of RTX with all it's wrappers and such. And the ISR check seems to be in those wrappers, not in the core RTX code..
Thanks for the help in advance
Jack
