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
  • Hello, Loic!

    Which of the two cores are you targeting with the sample? To use hci_uart with the nRF5340 For any HCI sample I believe you must use the network core, as the application core doesn't have access to radio resources.

    Best regards,
    Carl Richard

  • Hello Carl!

    Thank you for your reply. As far as I understood, the network core does not support the HCI UART : (+) Is nrf5340 support only bluetooth hci_uart mode on cpunet? - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com)

    Just to avoid miscomprehension, I am selecting the board variant "nrf5340dk_nrf5340_cpuapp" and I selected the code sample available in "ncs\v1.5.0\zephyr\samples\bluetooth\hci_uart".

    I am not sure if I understood it right but here is how I see it : the hci_uart sample code exposes the HCI interface of the network core over the UART of the application core. Is that right ?

    If it is correct, that's why I am currently building the sample code on SEGGER Embedded Studio for the application core. I tried to do it for the network core but I couldn't get it working...

    If you need any other detail, I will be happy to answer you !

    Kind regards,

    Loïc

  • Hello again!

    loic murith said:
    Thank you for your reply. As far as I understood, the network core does not support the HCI UART : (+) Is nrf5340 support only bluetooth hci_uart mode on cpunet? - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com)

    What's meant with the answer here is that the only HCI sample that we currently can ensure support for on the nRF5340 network core is hci_rpmsg. However, from what I can see hci_uart should work on both of the cores given the correct configuration and overlays. Please have a look in the board folder of the hci_uart sample and look at the files there for reference. For the nRF5340 application core a file called "nrf5340dk_nrf5340_cpuapp.overlay" is required. In this file you can also specify the desired UART pins to use.

    Best regards,
    Carl Richard

  • 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

  • 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

Reply
  • 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

Children
  • 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