Code only executes when semihosting

[botmail242]

Posted on June 28, 2016 at 21:11

I have a STM32F4 Discovery board. I have GDB connected to OpenOCD and when I run my program on GDB it executes perfectly. When I disconnect the board and program it via ST-Link nothing happens. I tried and older program that I wrote and it worked on both GDB and ST-Link. What could be causing it to work on GDB in semihosting mode? And when I stop semihosting, the program stops running...

[Radosław]

Posted on June 28, 2016 at 22:59

Semihosting required debug conection with target.  Software with semihosting will never work when program STM via stlink utility.

[botmail242]

Posted on June 29, 2016 at 05:25

So if I remove all code that requires semihosting it should work..? (I literally chopped my code down to a blinking LED and it still isn't writing via ST-Link)

[AvaTar]

Posted on June 29, 2016 at 08:20

Which toolchain ?

My preferred one (Crossworks) does explicitly wait in the startup code for the debugger to connect, if semihosting is enabled. With other words, it does so by design.

[botmail242]

Posted on June 29, 2016 at 12:45

GNU Embedded ARM Toolchain. I have no idea how it works on the back end, to be honest.

[Tesla DeLorean]

Posted on June 29, 2016 at 13:24

If you can't see where the problem is then try presenting the problem in a way others can see it?

[AvaTar]

Posted on June 29, 2016 at 13:29

> GNU Embedded ARM Toolchain. I have no idea how it works on the back end, to be honest.

I don't know how it works with your toolchain. But basically, semihosting means part of the ''code'' (functionality) is done on the host, i.e. on the PC. Most often this is clib standard IO code. Crossworks supports even file operations (fopen,fclose, fseek,remove, etc.) on the host. I guess it fails either in the startup, or a specialized semihosting library which is used.

[botmail242]

Posted on June 29, 2016 at 18:10

''If you can't see where the problem is then try presenting the problem in a way others can see it?'' I'm not going to send all of my code and expect someone to bug hunt for me. I'm just asking if anyone has any general insight as to why this happens.

I don't think it was the toolchain. I created a fresh project, copied my files over, and ran it without any issues. I must have messed with a driver file... Thanks for the support

[Tesla DeLorean]

Posted on June 29, 2016 at 20:58

I'm just asking if anyone has any general insight as to why this happens.

It would seems it is hung up waiting for a response it will never receive, from software you aren't running. I'd halt it in my debugger or from the ST-LINK Utilities, and correlate where it is against the .MAP or .LST and make that determination.

[carmine]

Posted on June 30, 2016 at 18:30

As stated before, semihosting uses the assembly instruction BKPT to transfer the control to the debugger. Without a live debug session, the CPU remains halted at the first BKPT instruction.

In GNU ARM Eclipse generated projects comment out the macro OS_USE_SEMIHOSTING at project level to disable semihosting.