Menu

#180 trace functions cause Hard Fault when there is no active debugging.

Next release
closed-works-for-me
None
1
2015-05-24
2015-04-09
J K
No

[Resolution: probably lack of properly power cycling the target board]

I'm not sure this is a bug or just something expected, so I'll apologies in advance.

The trace_puts/printf functions work great when debugging, but when you run the hardware on it's own, the trace functions cause a hard-faults. I was going to try and see if I could fix it but the fault occurs in a small part of code written in assembly. I've attached a picture of the hardfault, I got by connecting to the running(crashed) target.

To reproduce:
Create a project with the blink example.
Build the project and then debug a basic board with a LED.
It will work fine the console will say hello world then count while the LED blinks.
Stop the debugging, disconnect the debugger.
Then re-power the board, it will hardfault at trace_puts("Hello ARM World!"). So there will be no blinking.
(If you comment out all the trace_puts the LED blinks fine on it's own in that last step)

plug-in version 201504061754
Eclipse version Luna SR2 4.4.2
Java version V8 update 40 (build 1.8.0_40-b26)
operating system Win 8.1 x64
toolchain version GNU 4.9 2015q1

1 Attachments

Discussion

  • Liviu Ionescu (ilg)

    for cortex-m0/m0+ the behaviour is correct, if you use trace via semihosting, the implementation uses BKPT to talk to the debugger, and if the debugger is not there, it crashes.

    for cortex-m3/m4/m7, which have a more elaborate exception processing, I was able to detect this exception and return to the caller, as nothing happened :-)

    if you want the debug version to run without the debugger, I suggest you use the ITM output.

     

    Last edit: Liviu Ionescu (ilg) 2015-04-09
  • Liviu Ionescu (ilg)

    • status: open --> open-accepted
    • assigned_to: Liviu Ionescu (ilg)
     
  • J K

    J K - 2015-04-09

    Thanks for explaining it. But I am using a cortex-m3, the STM32F103VC.

     
  • Liviu Ionescu (ilg)

    then we have a problem. I'll investigate.

     
  • Liviu Ionescu (ilg)

    I just checked this on my STM32F4DISCOVERY board and it works.

    however there is a small detail, you need to power cycle the board, simply reseting it is not enough.

    could you confirm that this procedure works for your board too?

     
  • Liviu Ionescu (ilg)

    to be sure it is not related to the processor, I double checked on my STM32F103RB board, and it works too, after power cycling the board the LED is blinking as expected.

     
  • Liviu Ionescu (ilg)

    any progress?

     
  • J K

    J K - 2015-05-11

    Sorry I've been a bit busy. I tried removing the power and reapply the power to my main project without success.(I assume that's what you mean when you say power cycling)

    I'll try with the blinky default project and with a dev board, when I get a chance and let you know.

     
  • Liviu Ionescu (ilg)

    since this could not be reproduced, I suggest we close this ticket.

     
  • J K

    J K - 2015-05-24

    I've tried with some more eval boards and the problem doesn't seem to show up. So it's fine to close it. Sorry for wasting your time.

     
  • Liviu Ionescu (ilg)

    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,3 +1,5 @@
    +[Resolution: probably lack of properly power cycling the target board]
    +
     I'm not sure this is a bug or just something expected, so I'll apologies in advance. 
    
     The trace_puts/printf functions work great when debugging, but when you run the hardware on it's own, the trace functions cause a hard-faults. I was going to try and see if I could fix it but the fault occurs in a small part of code written in assembly. I've attached a picture of the hardfault, I got by connecting to the running(crashed) target.
    
    • status: open-accepted --> closed-works-for-me