Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32

Forum List Topic List

[ prev topic ]  

Debug stays at Reset_Handler, step into/over buttons are disabled

Posted by yuantuh on 2016-02-02 03:47

Hello,

For the first time debug was successful without any problem, but after that (terminated and ran debug again) debug stays Reset_Handler forever, see attachment. Step Into/Over buttons were gray. Restarting Eclipse did not help. The project was gnerated by CubeMX with FreeRTOS and run OK (without debug) on custom STM32F427 board.

I am using the latest AC6 and ST-LINK/V2.

Yuantu

debug.jpg (202.27 Kb)
Reads: 10148
Link
Posted by mazensaad on 2016-02-16 19:21

Hi,

I am not sure ): but the picure is indcating that the code is running OK , if you want to stop it click on the puse button
and then it will activate the step into and step over buttons


best regards
Eng.Mazen Aljeddani

Link

Posted by mkerr@atspl.com.au on 2016-10-31 03:46

Hi Yuantu,

Did you resolve your issue? I’m trying to work out if i’m see the same issue.

When I start debugging, the application never halts at main(). To get it to halt I need to suspend the thread, run “monitor reset halt” in the console, then resume the thread. This works most of the time.

Then when I step through the code, the instruction pointer appears to jump around the code. Then it gets stuck in SystemClock_Config().

But if i then disconnect the debugger, and reset the board, the application (simple LED blinker) appears to run correctly.

Did you resolve your issue? Can elaborate on what it actually was and what you did to resolve it?

Regards, Matt.

Link

Posted by diabolo38 on 2016-10-31 10:18

if your code is compiled at -o2 -os or -o3 it’s quite normal for step over not to folow the sequenital flow as it got optilmized
if you need full debug only used -o0 even -og (debug) will supress some variable visibility.

if you have enabed rtos awarness in the opencd config brake at main shall not be used
it seam that brake prior os start and so any thread present will confused the IDE/debugger.
what you do with manual brake set look as some work arround it .
Also i notice degung rtos aware debug is not quite robust/stable. I could seen similar issue with brake at main etc.
typicaly to debug priro os started use non rtos aware debug config (you can have both debug conf )
and do not enable rtos awarness unless you need to view all task state and call stack
i’m personally ok with non rtos aware debug until to deal and debug with above requirement.

if you get stuck at system clock config is suspect yoru clock config is not correct or ?
if you can’t debug but have some proof app is running “brake/pause” shall run always
it may brake in assembly or most of time is rtos idle task or scheduler but stil shall run.

Link
Posted by mkerr@atspl.com.au on 2016-11-02 22:24

Hi diabolo38, thanks for your comments.
It looks like the default optimization level is optimize for size (-Os). I have change this to optimize for Debug (-Og).
I haven’t enabled rtos awareness. However, the debugger appears to behaving nicely now, so enabling rtos awareness is something i’m interested in. I have read where it is mentioned in the openocd documentation, however it isn’t entirely clear how i should be updating my configuration file to best best debug FreeRTOS. Do you know where i can find examples of how best to do this?
I’m not entirely sure what I have done to fix my debugging issue. What I could see is that the board was resetting (PIN reset), but i’m not sure if it was the ST-Link doing it, or the LSE Startup timeout. Changes I made were; grounding the BOOT0 pin (it was floating), and changing the reset_config by removing “srst_only”.
When debugging, my application automatically stops on main(), so I’m now happy biggrin

Link
Posted by mkerr@atspl.com.au on 2016-11-02 22:53

Sorry diabolo38, I told a lie. I did change my OCD configuration file:

/# use hardware reset, connect under reset
/#reset_config srst_only srst_nogate
reset_config srst_nogate

However when I select “Use Local Script” in the Debug Configuration, I get the error “SCRIPT NOT FOUND”.
So instead I have copied the configuration file to: /home/gateway/eclipse/plugins/fr.ac6.mcu.debug_1.11.0.201610101240/resources/openocd/scripts/st_board
The configuration file in the /st_board directory contains:

/# use hardware reset, connect under reset
reset_config srst_only srst_nogate

What I did need to do was comment out the reset command in /target/stm32f4x.cfg:

/# use hardware reset, connect under reset
/# connect_assert_srst needed if low power mode application running (WFI...)
/#reset_config srst_only srst_nogate connect_assert_srst

So it appears that all I have done to the OCD configuration is remove “connect_assert_srst”.

Link
Posted by diabolo38 on 2016-11-03 08:36

their are some thread here and how to on the net for rtos aware debug.

basiclay
you need to add a line on the openocd cfg
add a variable in your code (free rtos compat) for debugger to catch it
and voila.

likley your reset problem was h/w or that reset cfg.

i personaly used nucleo,discovery and a few custom baord with standard openocd cfg and almost never change configuration.

Link