nRF9160-DK USB serial broken if USB not connected before boot

[Jonathan]

I notice that the USB Serial (the lowest numbered COM port of the three, that's connected to the Cortex-M33) isn't opened in a Serial Terminal before the application starts, it never works. If you reboot the CPU, it then works fine.

1. Connect the DK to the PC.

2. Observe COM3, COM4 and COM5 appear.

3. Open a serial terminal on COM3.

4. Observe that the serial terminal doesn't work - no output is printed and no input appears to reach the MCU.

5. Press the reboot button on the DK.

6. Observe that serial terminal is fine - text appears and MCU responds to input.

7. Disconnect the Serial Terminal from COM3. MCU should still be running at this point.

7. Connect the Serial Terminal to COM3 again. MCU should still be running at this point.

4. Observe that the serial terminal doesn't work - no output is printed and no input appears to reach the MCU.

I have an Actinius Icarus and this is quite happy to have the USB serial connected and disconnected, so I'm fairly sure it's not my code (unless it's pin config). On the DK I am configuring the serial terminal thus:

        let cdc_uart = Uarte::new(
            p.UARTE0_NS,
            uarte::Pins {
                txd: pins0.p0_29.into_push_pull_output(Level::High).degrade(),
                rxd: pins0.p0_28.into_floating_input().degrade(),
                cts: Some(pins0.p0_27.into_floating_input().degrade()),
                rts: Some(pins0.p0_26.into_push_pull_output(Level::High).degrade()),
            },
            UartParity::EXCLUDED,
            UartBaudrate::BAUD115200,
        );

and on the Icarus:

       let cdc_uart = Uarte::new(
            p.UARTE0_NS,
            uarte::Pins {
                txd: pins0.p0_09.into_push_pull_output(Level::High).degrade(),
                rxd: pins0.p0_06.into_floating_input().degrade(),
                cts: Some(pins0.p0_25.into_floating_input().degrade()),
                rts: Some(pins0.p0_07.into_push_pull_output(Level::High).degrade()),
            },
            UartParity::EXCLUDED,
            UartBaudrate::BAUD115200,
        );

[Kenneth]

Have you made any progress?

I would expect some of the UART input pins (CTS or RXD) is floating and causing the code to fail, could be either of the com ports (application or modem). If you have the possibility to measure those pins before open com port and after a reset I would expect you would find the problematic pin(s). Maybe they need to be pulled high/low to avoid them floating in such case.

[Jonathan]

As I'm using the official Nordic nRF9160-DK (PCA10090 v0.8.2), I didn't expect to have to add various pull-ups or pull-downs to get the serial port to work.

Can you confirm that you're stating there is a hardware issue with the nRF9160-DK? Do you know if a later version of the board resolves this issue?

[Kenneth]

Typically all IO's are considered generic, and the SEGGER chip that is the UART-USB bridge will not take control over any pins (e.g. set correct level for UART) until the COM port is opened no.

[Jonathan]

So ... is that something your secure_platform_manager should do when compiled for the PCA10090? Should I check if there's a newer version available?

[Kenneth]

It is intentionally this way, have been for most (if not all) nRF SDK out there. It could be very problematic if the SEGGER chip claimed two pins if they were used for other purpose in the application.

Kenneth