I
used Stm32CubeMx with STM32Cube_FW_F0_V1.4.0 to generate my project on
STM32F030CC with FreeRTOS and EWARM toolchain. The debugger "lost track" the first time FreeRTOS tried to pendSV. After that, I had to pause the debug session to see the micro loop inside a strange
memory area around 0x1FFFDA7C (which I dsicovered later was the system memory) in the disassembly window only. I restarted everything a couple of time, verified if any ISR were being called, which they were not, and ended up with the same result, always. Finally I switched debugger from J-Link Plus to ST-Link and my problem disappeared.
Symptom was really an unexpected system reset followed by unexpected
boot load from system memory.
Any insights about this particular issue? ST-Link is fine, but I hate working with so few breakpoints available.
SEGGER J-Link ARM V9.30
Host firmware 2014 Oct 28 19:25
Emulator Firmware 2015 Oct 9 20:34
used Stm32CubeMx with STM32Cube_FW_F0_V1.4.0 to generate my project on
STM32F030CC with FreeRTOS and EWARM toolchain. The debugger "lost track" the first time FreeRTOS tried to pendSV. After that, I had to pause the debug session to see the micro loop inside a strange
memory area around 0x1FFFDA7C (which I dsicovered later was the system memory) in the disassembly window only. I restarted everything a couple of time, verified if any ISR were being called, which they were not, and ended up with the same result, always. Finally I switched debugger from J-Link Plus to ST-Link and my problem disappeared.
Symptom was really an unexpected system reset followed by unexpected
boot load from system memory.
Any insights about this particular issue? ST-Link is fine, but I hate working with so few breakpoints available.
SEGGER J-Link ARM V9.30
Host firmware 2014 Oct 28 19:25
Emulator Firmware 2015 Oct 9 20:34