Zephyr: nrf52840_pca10056: Leading spurious 0x00 byte in UART output

[carlescufi]

Note to future readers:
This is a hardware issue, due to the fact that at boot time, nRF52840 pins float, and so the buffer will likely pull them low weakly. That weak state is buffered by the mux, making the segger chip see a continuously low signal.
It is exclusive to the nRF52840 Development Kit (nrf52840_pca10056) and does not affect other Nordic nRF Development Kits.
Workaround: Use nrfjprog -r instead of pressing the reset button on the board.

When booting up, Zephyr generates a framing error that is interpreted by the Segger CDC ACM driver implementation in the debug MCU as a byte of value 0x00. This ends up in the serial port input of the application on the Desktop. Usually this doesn't matter because we are just outputting text, but in some cases we send data with a protocol and that is a big issue because it throws the protocol out of sync.
In particular this prevents btmon from correctly parsing the header of the first packet after reset when building Zephyr with CONFIG_BT_DEBUG_MONITOR.

To reproduce simply build samples/hello_world for the nrf52840_pca10056 board and reboot it, then check the output on the CDC ACM serial port and on a logic analyzer.

Note the leading 0:

$ stty -F /dev/ttyACM0 speed 115200
$ od -t x1 < /dev/ttyACM0
0000000 00 2a 2a 2a 2a 2a 20 42 6f 6f 74 69 6e 67 20 5a
0000020 65 70 68 79 72 20 4f 53 20 76 31 2e 31 34 2e 30
0000040 2d 72 63 31 2d 31 33 30 30 2d 67 38 32 66 34 64
0000060 34 66 35 61 38 34 33 20 2a 2a 2a 2a 2a 0a 0a 48
0000100 65 6c 6c 6f 20 57 6f 72 6c 64 21 20 6e 72 66 35

Trace showing the framing error that is also interpreted by the logic analyzer as a 0x00:

[joerchan]

I have noticed the same issue before, and the way I fixed it then was be removing all GPIO configuration of the PINS, and only assigning them to the UART peripheral.
So removing all calls to nrf_gpio_pin_set/output/input on the RXD/TXD/RTS/CTS pins might fix this issue.

[carlescufi]

@joerchan Thanks for the input. I think there are 2 issues here:

1. The Segger firmware is seeing a 0x00 with a framing error and still forwarding it up the CDC ACM port without the framing error.
2. Zephyr generates this glitch in the GPIO output during the boot process

I have contacted @simtind about 1., and he will escalate that to Segger.
Regarding 2., I am hoping that @anangl and @jarz-nordic can give me some feedback.

[anangl]

1. Zephyr generates this glitch in the GPIO output during the boot process

I don't think it is caused by the Zephyr application. On the logic analyzer, I can see this break signal on the TXD line (resulting in the byte 0x00 received) only when I perform the pin reset (either by pressing the reset button or executing nrfjprog --pinreset). When I do a soft reset (call NVIC_SystemReset from the application or execute nrfjprog --reset) the issue is gone. The TX line goes low when the chip is held in reset, so it is beyond the control of the Zephyr application. It seems that only the Segger firmware could do something about it.

[anangl]

I tried also with other Nordic DKs, i.e.:

• pca10028
• pca10040
• pca10090

but I didn't succeed to replicate the issue on any of them. So far I saw this unwanted break signal only on pca10056.

[carlescufi]

After further investigation, this is indeed an issue with the nrf52840_pca10056 Development Kit PCB. Closing since this is a hardware issue.