Why does a rogue breakpoint get inserted in MQX _sys_open()?

[jackblather]

I've come across what looks like a bug.

Sometimes when debugging, the program does not make it to Main_Task(). Instead, the debugger stops at a breakpoint that has been inserted in _sys_open(). I did not set this breakpoint and it's not listed in the breakpoint list. The breakpoint list has just one breakpoint and that's the one at Main_Task(). Pressing continue doesn't do anything as this rogue breakpoint seems to be permanent. When trying to continue, it hits the breakpoint again immediately and then the debugger stops at that breakpoint again.

The program halts at this breakpoint - it doesn't even reach Main_Task(). I tried cleaning/rebuilding the project, restarting DS-5, rebooting the system, etc but that doesn't help. I have to restore everything from backup and reinsert my changes. This happens every once in a while. It's really aggravating because once this happens, there is no way to fix it. I have to restore the entire system from backup and continue from that point and hope it doesn't happen again soon, but eventually it creeps up and I have to restore again.

Is this a MQX problem or DS-5 or PEx or the debugger, or ???

Attached is the Disassembly view of the running code when it hit the breakpoint.

Other projects seem to run fine.

I have noticed that if I work on a project long enough, this happens. It doesn't seem to matter what project it is.

Anybody have a clue why this is happening and/or how to fix?

DS-5 v5.16

Vybrid Tower Rev G

Ubuntu 32-bit

Processor Expert

Thanks in Advance.

[alejandrolozan1]

Hi Jack,

I have checked and the _sys_open function is not a function defined by MQX. It belongs to the DS-5 installation directory.

I have seen a few problems with the last DS-5 versions and MQX. I wonder if you have tried to use a older version of DS-5?

I have seen that 5.15v is more stable.

Best Regards,

Alejandro

[jackblather]

The problem magically disappeared; however, I continued the search to disable this dastardly feature because it *will* return. I found some ARM documentation that says to do this:

set semihosting enabled off

I put that command in the Debug Configuration -> Debugger Tab --> Execute debugger commands.

When I fire up the debugger, the "Commands" window says:

Semihosting server socket created at port 8000

Semihosting enabled automatically due to semihosting symbol detected in image '<....>.axf'

.

.

.

set semihosting enabled off

WARNING(TAB181): Active file handles were closed when semihosting was disabled: 2[:tt], 1[:tt], 3[:tt]

I hope this keeps that pesky bug at bay, but somehow I doubt it.

[jackblather]

Problem came back. ARRRGH. I cannot get anything done because of this bug.

[jackblather · Accepted solution]

The problem turned out to be that one of my source files was using the Semihosting printf() rather than the MQX printf(). It was fixed by adding the proper header files so that my code calls the MQX _io_printf() so the output goes to the Vybrid serial port instead of the semihosting's __2printf().

The "bkpt #0xab" is inserted by the ARM Semihosting facility at compile-time. Some extra functions get added to the embedded code to allow the IDE to act as the console for the embedded system. This has a bug - it's supposed to show printf() output to Eclipse's "App Console". Instead, it just halts the program.

This suggestion is something that Freescale probably can't do anything about: It would be a great help if the semihosting could be turned off in a configuration menu. After some research, I found that some of their other products allow this. Semihosting cannot be turned off in DS-5. This has plagued me for months. The semihosting facility is hidden. It will cause headaches if one not aware of its symptoms when this bug pops up - the system will just stop with no messages explaining why. I hope the ARM guys see this.

Thanks for your help, Alejandro. I appreciate it.

[jackblather]

Hi Alejandro,

Thanks for the info. I hope to delete these functions from the DS-5 installation.

The problem came back last night. I did a lot of research on it and found it's part of this "Semihosting" facility. I think it's part of the ARM debugging facility.. It's very hidden from the user and i have not found a way to disable it. I spotted this message in the "Commands" window when the Debugger starts:

Semihosting server socket created at port 8000

Semihosting enabled automatically due to semihosting symbol detected in image '<....>.axf'

In the 'Disassembly' window, I noticed several functions that have the "bkpt #0xab" instruction in them. I can see that _sys_open(), _sys_close(), and other functions have this breakpoint. Looks like they are part of the Semihosting "feature". I think Semihosting allows a user to redirect output from "printf()" in the embedded code to Eclipse. I have no use for that. I use the MQX "printf()", but the output goes to a serial port.

Any idea how to disable it? That Semihosting thing is preventing me from getting anything done - I cannot advance the program past those breakpoints.

Another weird thing is that this problem comes and goes. It will appear and halt my work for a while and then it will disappear for a week or two only to return and halt my work again.

I have v5.16. I will consider using an older version of DS-5. I have not installed v5.17 because I read it has some new bugs in it.

Thanks.

[alejandrolozan1]

I searched on the web and I found the below command that can be used whe you are debugging:

set semihosting enabled off

I found that in the ARM web page.

Have you tried that?

Best Regards,

Alejandro

[jackblather]

You and I were posting at the same time.

I found that. I hope this causes this bug to stay away.

Crossing my fingers!

Thanks!