Trace with stop mode

[hassan]

Posted on October 21, 2015 at 09:24

Hi, 

I am using Keil to debug STM32F103 using trace. The trace works fine up till the controller enters the stop  mode. After this,  Keil gives the warning no synchronization even after the controller has woken up. 

Should the trace be reconfigured after leaving the stop mode?

[Nickname5522_O]

Posted on October 21, 2015 at 18:21

Hi  abid.hassan,

In 

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/reference_manual/DM00031020.pdf?s_searchtype=keyword

, section 38.16.1, it is mentioned that:

''In Stop mode, the bit DBG_STOP must be previously set by the debugger. This will

 

enable the internal RC oscillator clock to feed FCLK and HCLK in STOP mode''

 

So, set the bit and the trace will work fine.

-Shahrzad-

[Tesla DeLorean]

Posted on October 21, 2015 at 19:10

Support for trace/debug across low power modes is likely to be lackluster, or invasive.

It's important to be able to understand what your code is doing without the assistance of external tools. First be having a clear idea what it will do from static analysis, and second by providing enough diagnostic output to understand the paths it takes dynamically.

[hassan]

Posted on October 23, 2015 at 11:10

I forgot to mention but i am already setting the DBG_STOP bit.

[hassan]

Posted on October 23, 2015 at 11:15

I am actually debugging a freeRTOS project, which can be difficult to debug without trace. Static analysis on RTOS can't really provide much useful information. I was also using UART for debugging but trace seemed like a more cleaner path.

[Tesla DeLorean]

Posted on October 23, 2015 at 17:11

Well, you should probably talk through your problem with Keil's support engineers. They will have the most practical insight.

My insight would be that Cortex trace isn't like old school ICE/LA implementations where all the bus data is available for review. Here you get some insight into the flow, and the software tools have to recreate the system conditions based on the stream coming from the trace hardware.

It's not clear if your underlying issue is from exiting STOP. Can you just avoid actually STOPing, where you go through the motions, but don't STOP and dump the debug connection. ie use a WFI that doesn't trigger a STOP vs one that does.