Program won't start after power cycle or reset

Sysprogs forums Forums VisualGDB Program won't start after power cycle or reset

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #35300
    GeneM
    Participant

    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

     

    • This topic was modified 4 months, 2 weeks ago by GeneM.
    • This topic was modified 4 months, 2 weeks ago by GeneM.
    #35303
    bflannery
    Participant

    Are your hardware boot pin(s) in the correct state to boot from 0x08000000?

    #35304
    GeneM
    Participant

    I believe so, BOOT0 is pulled low and my blinky program starts from power up with BOOT0 pulled low. But it is jumpered and I’ve tried it both pulled high and pulled low. No joy.

    • This reply was modified 4 months, 2 weeks ago by GeneM.
    #35667
    GeneM
    Participant

    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

    #35680
    bflannery
    Participant

    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.

    #35692
    GeneM
    Participant

    @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.

     

    #35716
    bflannery
    Participant

    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.

Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.