nRF9160DK serial port VCOM1 not working as expected

[Burt]

Hi,

I built the nrf/samples/bluetooth/hci_lpuart program in SDK v3.1.1. I am using an nRF9160DK board version 1.1.0. I did add several printk statements to zephyr/samples/bluetooth/hci_uart/src/main.c. I built on Linux. After I program the nRF52840, I will see this on minicom

*** Booting nRF Connect SDK v3.1.1-e2a97fe2578a ***                                                  
*** Using Zephyr OS v4.1.99-ff8f0c579eeb ***                                                         
main() entered                                                                                       
main() after bt_enable_raw()                                                                         
main() before while loop                                                                             
main() in while loop  

and that makes me happy. But there are two problems:

1) if I move the programming switch from nRF52 to nRF91, I no longer see the nice output. I have looked at the nRF9160DK Hardware Users Guide, and that states that VCOM1 is connected to the nRF52840, period. There is nothing stated in the documentation to suggest that printk should stop working when the programming switch is moved.

2) On Serial Terminal, I will see characters with a garbage font. I also see that garbage font if I connect my DK board to a WIndows machine and use Teraterm. But with Teraterm, I can issue a Control->Reset Terminal operation, and the font problem goes away. I do not see any similar mechanism on Serial Terminal.

My colleague had told me that he was having problems getting any printk to show up from the hci_lpuart program. So everything here was done in service of checking his findings. Truthfully I think I am working on a different SDK level, v3.1.1, but that is just a detail.

Burt Silverman

[Burt]

Okay, I understand one mistake I made: I forgot that the push button reset switch only resets the processor corresponding to the PROG/DEBUG switch. And I was using the push button reset switch. But this brings up another issue, at least when using Teraterm:

The nRF9160 will show all the messages starting at BOOT when I switch the board power from OFF to ON, for example

*** Booting nRF Connect SDK v3.1.1-e2a97fe2578a ***
*** Using Zephyr OS v4.1.99-ff8f0c579eeb ***
main() entered
main() after bt_enable_raw()
main() before while loop
main() in while loop
[00:00:00.484,588] <inf> nrf_modem_lib_trace: Trace thread ready
[00:00:00.492,248] <inf> nrf_modem_lib_trace: Trace level override: 2
+CEREG: 2,"7BFB","00F53601",7
+CSCON: 1
+CEREG: 2,"7BFB","00F53601",7,0,17

But the nRF52840 will not print the earliest messages, for example, compare what I showed in my earlier post (using reset switch) to what I see after power up:

main() before while loop
main() in while loop

I'm somewhat sure there is a trick to get the printing to start from the very beginning even with a power reset, but I don't know what it is.

Today I am not seeing the weird font problem, although I have only tried Windows and not Linux.

Thank you.

Burt Silverman

[Michal]

Hello Burt,

When you flash some simple application to both MCUs, do you get the same issue with lack of some logs from nRF52840 as well?

Best regards,

Michal

[Burt]

Yes, in fact, I flashed the nRF9160 with the cellular at_client off the shelf, and now neither one shows the boot message when I do a power up. So I would like your help with figuring out the prj.conf settings that fix this behavior. Once again, it is now happening on both processors on the nRF9160DK board. I can't tell you what I was previously running on the nRF9160 so that it showed boot messages, and this is such a basic issue that I expect that you and your team can tell me the trick. It's kind of frustrating that the default behavior in the samples doesn't show the boot messages upon power up. Maybe there is a good reason but it is frustrating. Thanks, Michal.

Burt

ps using v3.1.1 SDK 

[Michal]

I will dig deeper into it, do some testing and I will get back to you, possibly by the end of the week.

Best regards,

Michal

[Burt]

Thanks, Michal.

Burt

[Michal]

Hello, just wanted to let you know that I did some tests on the nRF9160 DK and for me VCOM1 only works when I toggle the nRF91-nRF52 switch to the nRF52 side.

I will continue to dig into it, I'll try to get back to you again sometime late next week.

Best regards,

Michal

[Burt]

Thanks again, Michal.

[Michal]

Sorry, no other news except that I'm trying to find out internally about the design of nRF9160 DK and this issue.

I will get back to you next week.

Best regards,

Michal

[Burt]

Thanks, Michal.

Lately, I have been programming zephyr/samples/bluetooth/hci_uart into the nRF52840 and I am seeing no problems with the console--even with a power switch reset. If I get energetic I will give nrf/samples/bluetooth/hci_lpuart another try. I encourage you to use that latter nRF52840 program if you do more testing. Especially SDK v3.1.0 and v3.1.1.

Your finding that the VCOM1 only works when the switch is toggled to the nRF52 side: even with the power reset button? We know that the push button reset will only reset the processor corresponding to the switch you mentioned.

I'm still curious how that issue about bad fonts comes about--the one I could only fix with Teraterm. Ask around if any experts have an idea about that. I am sure I have seen it in the past--but not often.

Burt

[Burt]

Michal, I cannot reproduce this anymore. I am going to chalk it up to possible user error. Given that I mentioned minicom originally, perhaps I had neglected to kill minicom prior to using Serial Terminal. I could have had minicom running in a GNOME Terminal window hidden somewhere on my Ubuntu desktop. Maybe, maybe not.

Rather than me close this out immediately, I will use the ticket to ask a slightly different question: if minicom is running on a tty port, is it possible to have Serial Terminal balk at then connecting, to let one know that he is about to do a bad thing? Do a bit of research and then we can decide what to do with this ticket. Thanks.

Burt

[Michal]

Just wanted to let you know that I have provided the feedback to our nRF Connect for Desktop team.

Thank you Burt!

Best regards,

Michal