- This topic has 7 replies, 2 voices, and was last updated 5 months ago by
.
-
Posts
-
I’m working on a new app that downloads, runs and debugs fine from VisualGDB on a new, custom SOM we’ve designed using a STM32H7A3. But if I stop the app, disconnect VGDB and power cycle or reset the board with the VGDB debugger disconnected, the app doesn’t appear to start. I blink an LED almost immediately after initializing the clock and GPIO so I have a pretty good indication of when or if the app starts. I used CubeMX to generate the startup and peripheral initialization code. The SOM uses external crystals for HSE and LSE and I use the CubeMX generated SystemClock_Init() function.
I wrote a very simple blinky program that blinks the LED on my SOM. It downloads, runs and debugs fine from VGDB and it also starts running (blinking the LED) immediately after power cycling or hitting the reset button just as I’d expect. This blinky program doesn’t use the HSE or LSE so that might be a clue. My new app starts up using the debugger 99% of the time but on rare occasions, I’ve seen it hang waiting for the HSE or LSE to startup in the SystemClock_Init() function. I’m working on this problem (I think I need to adjust the decoupling caps on the crystals) but it happens only rarely when downloading from VGDB and I have never seen the new app start at all without the debugger.
I’ve used STM32CubeProgrammer to make sure the new app is still loaded in flash at 0x08000000 after power up and it looks right to my eye. However, I can’t start the app from CubeProgrammer. I can download the new app .bin file using CubeProgrammer and it says it completes the file download, verifies the download, that the application is running and the start operation achieved successfully but I don’t see the LED blinking. Nor can I start the new app using CubeProgrammer after I downloaded it with the VGDB debugger. I can download and start the simple blinky program from CubeProgrammer.
Could there be something I’m doing or not doing that is preventing my main program from starting without a debugger attached?
Thanks
I’m back working on this problem and have a new piece of information. My main app was built by importing a .ioc file from CubeMX. This app blinks an LED right after configuring the clock and initializing the GPIO which is my clue that it has started running. It’s this main app that runs fine from the debugger and blinks the LED but I don’t see any blinking LED after reset or after power up (no debugger). I built another app with from the same .ioc file with the same code up to and including blinking the LED but nothing else. It works fine, I can see the LED blinking, from the debugger and after reset and after power up as expected. I’m using the STM32 CubeMonitor-Power debugger and I can see the current change whenever the LED is blinking. When I start the main app from reset or power up, no blinking LED and no change in current. The current just jumps up to the “normal” baseline 7 milliamps and stays there. As if the program doesn’t even start running. Given that my simple startup program works in all conditions, it seems like I’ve got the hardware setup correctly. Could I have done something in my main app to set some register that prevents my app from running outside of the debugger?
Thanks – Gene
It is hard to say what your problem is without seeing some code.
As for your question “Could I have done something in my main app to set some register that prevents my app from running outside of the debugger?”
Possibly. There have been occasions where I’ve had hardfaults appear out what at the time seemed like thin air. After resetting your board you can connect a debugger to the target and examine the call stack.
Debug >> Attach to Running Embedded Firmware (assuming it is running and is halted somewhere, your editor should jump to that spot, and pause the execution)
Have you made any modifications to your linkerscript intentional or otherwise? You could be placing your program in SRAM.
@bflannery – That was helpful, I was trying to Debug >> Attach to Process without success. Now that I’m using Debug >> Attach to Running Embedded Firmware like you suggested I can see that the program is stuck at the hard fault handler when it is running from reset or from power up/down. It still runs fine from the VGDB debugger. Now I have to figure out where and what’s causing the hard fault.
I’m still baffled by why it runs fine in the debugger but hard faults otherwise.
I would examine the call stack first.
Then you should also ensure that DEBUG_DEFAULT_INTERRUPT_HANDLERS is set to 1 if you are using the startup file that visualgdb generates. Likely there is an interrupt you are not handling. You can also write some code for your hard fault handler to dump the cpu registers to see what the source of the hard fault was.
Good news: I’ve got my app running properly from inside the debugger, after hitting the reset button and after power down/power up. There were 2 problems, one obvious and one not. The obvious problem was I had the “When running without debugger” option in the VisualGDB Project Properties -> Embedded Frameworks -> Fast Semihosting and Embedded Profiler option set to “Wait for debugger to attach”. It should be set to “Ignore profiling/semihosting calls”. Pretty obvious, but it took a while for me to actually catch the error in my app after re-attaching the debugger and examining the call stack. Once I saw the app was hung in some part of the Fast Semihosting calls, I knew where to look.
I was hoping that would be the obvious solution to my problem but there was more. I use CubeMX to set up the clocks and peripherals and then import it into my Visual GDB app. I had my CubeMX project set up to use HAL and LL drivers for different peripherals. As a last resort, I rebuilt the CubeMX project to use only the HAL library. That and the Fast Semihosting option fixed the problem. I didn’t take the time to narrow down the problem to which combination of LL and HAL driver was the issue, I’m just holding my nose and using all HAL drivers.
That’s really good news but now I have to re-write a bunch of working LL code to use the HAL library. Oh well, nobody ever said embedded software development was for sissies.
Thanks for all the help along this painful journey.
- You must be logged in to reply to this topic.