MCUXpresso often won't do PRINTF to Console in 'hello world' example

cancel
Showing results for 
Search instead for 
Did you mean: 

MCUXpresso often won't do PRINTF to Console in 'hello world' example

2,329 Views
jgreen
Contributor III

Hi, I found that sometimes I don't get any PRINTF output in debugger Console window. So I reverted to the 'hello world' example and found that also has the problem.

I'm running the 'hello world example from SDK-_2-2, MCUXpresso 11.0.0_2516 for LPC55S69 on Mac OS-X.

When PRINTF works, I see message in Console window (if I recall correctly) about telnet successful, and no such message when PRINTF issn't working.

At one point I wondered if I'd run out of memory/resources so I closed all my other apps and browser windows and then it did seem to work, but that may have been a fluke because that never made it work when it next stopped working.

Is there some log file somewhere that would give info about anything that went wrong? 

Screenshot attached where I've stepped past the PRINTF line with no console output.

Screenshot 2019-07-30 at 18.44.53.png

I've pasted info from IDE support info below...

Binaries path: /Applications/MCUXpressoIDE_11.0.0_2516/ide/plugins/com.nxp.mcuxpresso.tools.bin.macosx_11.0.0.201905221151/binaries/

Tools path: /Applications/MCUXpressoIDE_11.0.0_2516/ide/plugins/com.nxp.mcuxpresso.tools.macosx_11.0.0.201905131304/tools/

Wizards path: /Applications/MCUXpressoIDE_11.0.0_2516/ide/plugins/com.nxp.mcuxpresso.tools.wizards_11.0.0.201902141834/Wizards/

Product: MCUXpresso IDE
Version: MCUXpresso IDE v11.0.0 [Build 2516] [2019-06-05]
Operating system: Mac OS X
VM: Java HotSpot(TM) 64-Bit Server VM (64 bit)

0 Kudos
9 Replies

1,255 Views
mbra16
Contributor II

I have the exact same issue. I'm working on a LPC804, and yesturday printf worked just fine. Today, after I rebooted my PC, the same exact programs' printf does no longer work. I've checked that semihost was indeed selected, and that "use tellnet port for stub messages" is ticket. Now even if I make a new  project and run it, the "hello world" does not show up. 
Can this maybe have to do with the debug configurations? 

0 Kudos

1,255 Views
jgreen
Contributor III

Hi Martin,

Here's a few things I found when I had this problem...

1. In the attached screenshot, when starting debugger, if I didn't get message in 'Console' window "[MCUXpresso Semihosting Telnet console for..." then I knew printf output will not be working.

2. I increased timeouts "Telnet service creation delay (ms)" and "Telnet service connection timeout (ms)" and that made it much more reliable.

HTH

Jon. Screenshot 2019-10-29 at 15.21.13.png

0 Kudos

1,255 Views
mbra16
Contributor II

Thanks! I found out that the settings were somehow switched, using UART for SDK Debug Console. When I put it back to Semihost, it worked again. I'm confident I didn't change it to UART by myself, never the less, the problem is now resolved. 

0 Kudos

1,255 Views
lpcxpresso_supp
NXP Employee
NXP Employee

What I don't see in your screenshot is a message saying that the telnet console for semihosting was started ("[MCUXpresso Semihosting Telnet console for <projectName> started on port <port> @ 127.0.0.1]"). Please confirm that:

  1. "Semihost" was selected in the SDK Wizard as an "SDK Debug Console" when project was created

  2. "Use telnet port for stub messages" is enabled in Window => Preferences => MCUXpresso IDE => Debug Options (Advanced).

Greetings,

MCUXpresso IDE Support

0 Kudos

418 Views
saislakk
Contributor I

Hi,

I have a similar problem. I could see 

"[MCUXpresso Semihosting Telnet console for 'LPC1769_GPIO LinkServer Debug' started on port 58709 @ 127.0.0.1]" 

during debug. But when I'm trying to run the code, it says 

Terminated with 127. 

Please help me with the issue. 

Target MCU: LPC 1769

IDE Version : MCUXpresso IDE v11.3.0 [Build 5222] [2021-01-11]

Platform: MacOs X.

Thanks,

Sai

0 Kudos

1,255 Views
jgreen
Contributor III

Hi MCUXpresso IDE Support, thank for your response.

Regarding your questions...

1. I'm unable to confirm this, but PRINTF to Console does frequently work ok, so Console settings are most likely ok.

2. On my MAC-OSX install I don't have that menu option, but I can get to "Debug Options (Advanced)" via other routes and I do have "Use telnet port for stubbed messages" selected - see attached screenshot.Screenshot 2019-07-31 at 10.14.14.png

My issue is that this sometimes works and sometimes doesn't.

I've attached a screenshot that shows the telnet was started ok this time and the PRINTF to Console worked ok this time. The screenshot also shows my "Debug Options (Advanced)".

Now I know about "Debug Options (Advanced)" maybe I might try extending the timeout period etc on those occasions when I find it isn't working.

Is there some way (e.g. log file) that I can find out what went wrong when the telnet doesn't get started?

Thanks

Jon.

0 Kudos

1,255 Views
lpcxpresso_supp
NXP Employee
NXP Employee

You could choose from the list of consoles, the one ending in "Debug messages" and check whether "Awaiting telnet connection to port 3330 ..." appears in all pass/fail situations. Maybe when printf does not work, semihosting server cannot be started. You can also try using other ports.

There's also .log file in the .metadata folder in your workspace that might contain some useful information.

Greetings,

MCUXpresso IDE Support

0 Kudos

1,255 Views
jgreen
Contributor III

I've got a log file for the case that semi-host PRINTF isn't working - see attached.

If my interpretation of the log is correct then call to PRINTF results in log message like this:-

!ENTRY com.crt.log 1 0 2019-08-12 10:39:40.423
!MESSAGE Stream is null in [MCUXpresso Semihosting Telnet console for 'Firmware_S2_ntag_i2c_explorer_blink LinkServer Debug' started on port 49727 @ 127.0.0.1]Screenshot 2019-08-12 at 10.54.18.png

0 Kudos

1,255 Views
jgreen
Contributor III

Thanks for your reply. I already checked "Debug messages" and check whether "Awaiting telnet connection to port 3330 ..." - I'ts the same in log in both pass and fail situation.

I'll take a look at the log file you suggested next time it fails.

Extending the timeout seems to have made it more reliable - not has a single failure so far today.

0 Kudos