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?

[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.  

[Henry Dang]

1. Data is clocked out from the PC on TX line to the nRF device, but nRF is not sending back anything on the RX line so it has to do with the nRF.

2. Call the function properly this time but it doesn't make a difference unfortunately.

[Vidar Berg]

So no data is being sent out on the TX pin from the nRF on startup, correct? I'm not sure if I can explain that. The register content you posted earlier shows that data has been transmitted so it seems strange it's not reflected on the output. I assume the same board still works with the UART example? Is it possible that you may have swapped the TX and RX

[Henry Dang]

That is indeed the problem. Swapping TX and RX and it's working correctly now. This seems strange because the UART example is working fine with the previous TX and RX configuration but for CLI example I have to swap it.