This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF5340-DK : trouble with hci_uart sample

Hi !

I want to send simple HCI commands, such as reset, to the nRF5340 via UART. Therefore, I'm using the sample "hci_uart" available with nRF Connect SDK v1.5.0. I am sniffing the UART lines on the dev. kit with a logic analyzer but I cannot manage to measure anything. To try to understand what is going on, I put some breakpoints in the code and I observed that SoC never reaches the code in the while(1) loop in the main and systematically gets stuck in the file "cpu_idle.S". Is it normal ?

I did not modify anything in the code but I can imagine I do something wrong... please, can anybody help me clarifying this issue ?

I am available to give you any other information.

Kind regards.

Parents Reply
  • Hello again Carl!

    Thank you very much for this information. I checked the file which contains the following lines :

    /* SPDX-License-Identifier: Apache-2.0 */

    &uart0 {
    compatible = "nordic,nrf-uarte";
    current-speed = <1000000>;
    status = "okay";
    hw-flow-control;
    };

    Actually, when I manage to sniff data on UART line such as "*** Booting Zephyr OS build v2.4.99-ncs1  ***" I see that the baudrate is 115200 and not 1000000 as specified in the .overlay file. Do you know what could cause this ?

    Moreover, can you please explain me what can I add in this file to specify the UART pins ?

    Thank you very much for your help !

    Kind rgards,

    Loïc

Children
  • Hi!

    You're sniffing the log messages printed over UART, which by default is using baudrate 115200. Try to setup and sniff the correct pins. Below is an example of how you can specify them:

    /* SPDX-License-Identifier: Apache-2.0 */
    
    &uart0 {
    	compatible = "nordic,nrf-uarte";
    	current-speed = <1000000>;
    	status = "okay";
    	hw-flow-control;
    	rx-pin = <44>;
    	tx-pin = <45>;
    	cts-pin = <46>;
    	rts-pin = <47>;
    };

    Make sure that the UART you are using for HCI isn't conflicting with the UART that is used for logging. I believe it should be fine in this case, if it's not you can try the following overlay file instead:

    /* SPDX-License-Identifier: Apache-2.0 */
    
    &uart1 {
    	compatible = "nordic,nrf-uarte";
    	current-speed = <1000000>;
    	status = "okay";
    	hw-flow-control;
    	rx-pin = <44>;
    	tx-pin = <45>;
    	cts-pin = <46>;
    	rts-pin = <47>;
    };
    
    / {
    	chosen {
    		zephyr,bt-c2h-uart=&uart1;
    	};
    };


    Best regards,
    Carl Richard

  • Hello again Carl !

    Thank you very much for your valuable help and your availability ! I found out that when I'm building and flashing the code with west, it takes into account what's inside the .overlay file. 

    I have now fully access to the HCI over UART at the desired baudrate which is exactly what I needed ! Great !

    If I can ask one last question on this topic, I would like to know where to find the information of the relation between the pin numbers (<44>, <45>, etc...) and the hardware pins of the chip and/or pin name (P0.00, P0.01, etc...) ? I searched in the datasheet of the nRF5340 but I did not find it.

    Once again, thank you very much for your help !

    I wish you a great week-end !

    Kind regards,

    Loïc

  • Hello again, Loic!

    Good to hear that it works now! For SES to take new overlays into account you must reopen the project or do "Project" -> "Run CMake". The pins I used in the example are on port 1 (P1.xx). The pin number for P1 pins are given by 32+<desired_pin>, so taking 44 as example you're using P1.12. 

    I'm very glad to help and thank you. I wish you a good weekend too!

    Best regards,
    Carl Richard

  • Hi Carl, where is this documented or what's the logic behind the 32+<desired P1 pin> ?

    Reason I'm asking this is, I've been testing hci over uart on the adafruit_feather_nrf52840 board. And for the uart CTS, I've been testing the pins P1.08-> D5 as well as P0.08->D12 pins, for both cases, my device-tree config was,

            cts-pin = <8>;

    and it works both cases. Appreciate some clarity here as to why I'm seeing this behavior.

Related