nRF9160DK serial port VCOM1 not working as expected

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

Parents
  • 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

    
    
  • 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

  • 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 

  • 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

Reply Children
Related