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

[jgreen]

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.

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)

[kar1]

hello,

I have same issue with MCUxpresso on Windows 11, nothing appears by changing com ports configurations. also nothing on putty and teraterm.

there is another chat related to this terminal issue on Windows 11!

Re: nothing in terminal view for debugging. - NXP Community

thanks

[bytemanaccel]

About the settings I've found that was set to UART console, to change it:

Quickstart Panel _> Miscellaneous -> Quick Settings -> SDK Debug Console

then you can choose between Semihost or UART.

Regards.

[mbra16]

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? 

[jgreen]

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. 

[mbra16]

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. 

[lpcxpresso_supp]

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

[saislakk]

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

[jgreen]

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.

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.

[lpcxpresso_supp]

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

[jgreen]

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]

[jgreen]

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.

[bytemanaccel]

Thanks for sharing, could you please let me know where I've to go in order to change the timeout setting?

Thanks!