How to use a UART instead of CDC ACM in Openthread CLI example

Hi, I am using a third party module based on nRF52840. I want to use a standard UART to operate the CLI shell. I am not clear how to do this, any help?

Thanks,

Kaushalya

Parents Reply Children
  • Also at add to my previous comment, by looking at resources list in my project, I can see UART0 Tx is GPIO0.6 and RX is GPIO0.8. I can see when I measure the voltage of these, they are both at 3V (VDD). Unfortunately I dont see any response once I hooked up a USB to TTL cable (3V3) to these ports. This may mean still the project is configured for USB transport layer. How can we verify which transport the project is configured to?

    Thanks,

  • Hi Andreas,

    I've been debugging into this and have some interesting results.

    1. I programed the on-board CPU on the Dev Kit and I could see the UART working from P0.6 and P0.8. So this means project is build correctly with UART as the transport layer.

    2. Then to test the UART connection on my third party module, I build the 'getchar' example project and programmed my module with it. Then the UART was working with P0.6(TX) and P0.8(RX). I built both projects with NRF52840DK_NRF52840.dts file.

    Conclusions

    Based on 1. The OpenThread CLI project is built with UART as the transport layer.

    Based on 2. My third party module's UART and wiring is working as expected.

    So the question now is why the CLI project programmed to my module doesnt work??

    Any ideas?

    Thanks,

  • Hi Andreas,

    Since the same program seems to be behaving differently on Nordic Dev Kit and my module, I wanted to see if the program starts and continue without any errors like a crash.

    So I added the following section to the CLI main.c

    #define LED2_NODE DT_ALIAS(led2)
    static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED2_NODE, gpios);
    ...
    void main(void)
    {
    	gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE);
    	gpio_pin_set_dt(&led, 1);
    	k_msleep (100);
    	...
    }

    Now when I program this to the Dev Kit, the LED3 stays lit up and the CLI shell seems to be working.

    When I program this to my module, the LED (on P0.15) doesnt light up!! So the program doesnt seem to execute properly. 

    Any ideas?

    Thanks heaps,

  • I tried debugging in to my module with the CLI program. When I tried debugging with Dev Kit, I could see the main() got executed, but with my module, it never reaches the main(). It jumps from 

    arch_irq_lock() -> k_is_pre_kernel() -> arch_irq_lock() in a loop. 
    So is this an issue with I am using NRF52840DK_NRF52840.dts on a third party module?
    Apologies for the lengthy reply chain. I am trying to give as much info as possible for you.
    Thanks,
     
  • ok I managed to solve it. I will leave this to help someone as new as me to Nordic SDK may find it useful.

    I thought this may be caused by some rant interrupt or something like that since my module has nothing connected to it except uart cable and the LED on _0.15. So I disabled all unnecessary interfaces from DTS and DTSI.  Eventually the culprit was the RTS and CTS lines as I am using 3 wire cable for UART.

    So I did the following to remove unused RTS and CTS pin mapping from DTSI file.

    	uart0_default: uart0_default {
    		group1 {
    			//psels = <NRF_PSEL(UART_TX, 0, 6)>,
    			//	<NRF_PSEL(UART_RTS, 0, 5)>;
    			psels = <NRF_PSEL(UART_TX, 0, 6)>;
    		};
    		group2 {
    			//psels = <NRF_PSEL(UART_RX, 0, 8)>,
    			//	<NRF_PSEL(UART_CTS, 0, 7)>;
    			psels = <NRF_PSEL(UART_RX, 0, 8)>;
    			bias-pull-up;
    		};
    	};

    One thing strange though is still my P0.15 LED is not lighting up. I have not removed pin mapping for that. 

    Anyway the CLI shell is now working. 

    Cheers,

Related