Getting CLI to work over UART on custom board

[Henry Dang]

Hi support,

I'm currently using pca10040 on my custom board and want to be able to implement the CLI over uart port. My SDK is 15.2.

To get started, I test my board's hardware with the uart example and it's working fine (the only modification I have to made is changing TX_PIN_NUMBER and RX_PIN_NUMBER). However, when I try the cli example, with the same change to the pin number, I'm not getting anything over my uart terminal.

Any idea what I'm missing? I have tried both Tera Term and Putty and made sure my set up is the same as the documentation.

Thanks in advance!!!

[Vidar Berg]

Hi,

It's good that you already validated the HW by running the UART example. So, maybe it's not related to the UART. Do you have the optional 32Khz mounted on your custom board? If not you need to make sure the internal RC oscillator is selected (ie., set  CLOCK_CONFIG_LF_SRC=0 in sdk_config.h)

[Henry Dang]

Hi Vidar,

Thank you for your quick reply. My board doesn't have the optional 32Khz mounted so I have disabled CLOCK_CONFIG_LF_SRC. However, uart is still not working. Any other places I can check?

[Vidar Berg]

Have you tried to debugging in Segger embedded studio and with the "Debug" configuration instead of "Release". If not I think it may be worth trying. There are some ASSERT checks in the CLI backend that will be excluded otherwise.

[Henry Dang]

All of my APP_ERROR_CHECK is passed and ret is returning 0 which means NRF_SUCCESS. I also have it in debug mode. 

[Vidar Berg]

Thanks for confirming. Note that the ASSERT() macro is unlike the APP_ERROR_CHECK() maco excluded from "release" builds. But that doesn't matter now as you're already using the Debug configuration. 

I noticed now that you're using the PCA10040 configuration which is for the nRF52 DK + 52832 while the original question is tagged with nRF52840 DK (PCA10056). Please try the PCA10056 if your target is a nRF52840.

[Henry Dang]

Sorry for the confusion, my target is the PCA10040 on my custom board. The tag is because I'm using the nrf52840 dk to test/develop code on. 

[Vidar Berg]

Please try to read out the UARTE registers as well to see if it looks as expected. E.g., go over PSEL registers, see if any of the event registers are set, .TXD.AMOUNT != 0, etc. 

[Henry Dang]

My registers look similar to yours, with the major difference just being that I'm using pin 22 and 23 for TX and RX respectively

[Henry Dang]

[Vidar Berg]

Thanks for checking. The registers indicate that data has been transmitted (DMA amount is 3 bytes, and the tx event is triggered), which makes me suspect that it might not be a SW configuration problem after all even though it worked with the UART example earlier.

Some more ideas of what you can try:

1. Probe the TX line with Logic analyzer or scope to verify if data is clocked out

2. Call nrf_drv_clock_hfclk_request(NULL); on startup to turn on the HF crystal oscillator. It will increase the baudrate accuracy.

3. Try with a different USB UART bridge

4. Lower the baudrate. E.g., 38400

[Henry Dang]

Still no luck with all the changes:

1. TX line in clocked out and I can verify it on the scope

2. When I called nrf_drv_clock_hfclk_request(NULL), the ASSERT(m_clock_cb.module_initialized) in the function failed.

3. Swap out another cable but still no luck

4. Test out lower baudrate (38400 and 9600) but no response as well.

I see this on the rtt_cli, not sure if it's related 

[Vidar Berg]

Thanks again for checking. With regards to point 1, if data is clocked out, but not received by the PC, doesn't that indicate that the problem is external to the nRF? 2. It must be called after the clock init. You can do it at the same time you request the LF clock.