• State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 87 subscribers
  • Views 820 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 277485
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

move from 9160DK to Thingy91 problem: bt_hci_core: No HCI driver registered

bluebeam

I try to test my BLE code on Thingy91's 52840. The code was tested ok on the 9160DK board. Without changing anything, I have the error like this: bt_hci_core: No HCI driver registered

I found this thread which described the same problem:

https://devzone.nordicsemi.com/f/nordic-q-a/76092/bt_hci_core-no-hci-driver-registered-on-thingy91_nrf52840

I added CONFIG_BT_HCI=y and CONFIG_BT_CTLR=y. That seems to solve the problem.

Can you explain why is that? Is the nrf52840 on Thingy91 any different from the one on the nrf9160DK?

Another problem I  have is with the uart port. I'd like to use UART0 as debug output and redirect it to the Spare pins(1~4) so I can monitor them. I added an overlay file (attached) but that doesn't seem to work. I can't see any activities on the pins. The same code on 9160DK works fine and have the serial logging output (to a PC). I'm not sure what did I miss? Thanks!

thingy91_nrf52840.overlay

Parents
  • 0

    I added CONFIG_BT_HCI=y and CONFIG_BT_CTLR=y. That seems to solve the problem.

    Can you explain why is that? Is the nrf52840 on Thingy91 any different from the one on the nrf9160DK?

    I added CONFIG_BT=y to the prj.conf of the hello_world sample, built it for the boards nrf9160dk_nrf52840 and thingy91_nrf52840 and checked the file <build>/zephyr/.config of both boards. I saw that CONFIG_BT_HCI was enabled by default for both, however CONFIG_BT_CTLR was only enabled for the board nrf9160dk_nrf52840. This is because this config is enabled through the board file zephyr/boards/arm/nrf9160dk_nrf52840/Kconfig.defconfig, which is not the case for the thingy91_nrf52840: https://github.com/nrfconnect/sdk-nrf/blob/db8b7c368bb1a58e5954513826607c5c57a952ba/boards/arm/thingy91_nrf52840/Kconfig.defconfig 

    Another problem I  have is with the uart port. I'd like to use UART0 as debug output and redirect it to the Spare pins(1~4) so I can monitor them. I added an overlay file (attached) but that doesn't seem to work. I can't see any activities on the pins. The same code on 9160DK works fine and have the serial logging output (to a PC). I'm not sure what did I miss? Thanks!

    For the Thingy91, the easiest would probably to use USB peripheral to log, instead of UART. The Thingy91 does not have an onboard debugger like the 91 DK that exposes the UART as a COM port. Check out the sample 

    Best regards,

    Simon

  • 0 in reply to Simon

    Thanks for the response. I guess that makes sense if it has a different default configuration.

    Following the same spirit I did a comparison of my build/zephyr/.config and found that the DK build has CONFIG_UART_CONSOLE=y but the thingy build doesn't have it. So I added it and that solves the problem.

    But then I notice I'm also missing CONFIG_UART_NRFX=y in the Thingy build. But in both .config file there's CONFIG_UART_NRFX=y. (And I don't have it in my prj.conf file) So where does that come from? Is there another 'default' config somewhere to make this happen?

    All these CONFIG_xxxx are very confusing. Too many configurations to remember and too many places to check. It's frustrating.

  • 0 in reply to bluebeam
    bluebeam said:
    But then I notice I'm also missing CONFIG_UART_NRFX=y in the Thingy build. But in both .config file there's CONFIG_UART_NRFX=y.

    Could you elaborate what you mean here? The two sentences seems contradictory, if you found CONFIG_UART_NRFX=y in the thingy's .config, you're not missing it in the build of the thingy.

    Comparing the .config file might be overwhelming, it is probably easier to compare the Kconfig files and _deconfig file between the two board folders. If you're building the same application using the two boards, all the differences between the .config of the boards are due to the board folders (it's the same chip, but in different boards).

    However, the boards should be set up correctly by default. I will look into tomorrow why CONFIG_BT_CTLR is not enabled for the Thingy:91. 

  • +1 in reply to Simon

    I would like to expand on my earlier answer

    The .config files shows all configurations, both the ones you've set, and the ones that is being selected as a consequence. The reason you don't need to set CONFIG_UART_NRFX=y directly in the prj.conf file is because it is set indirectly by CONFIG_SERIAL=y, first if CONFIG_SERIAL=y it will make the file Kconfig.nrfx visible, then Kconfig.nrfx will set CONFIG_UART_NRFX=y, since you're using a Nordic chip. Cmake will then run some logic, and eventually the Nordic specific serial driver is enabled. The take away here is that you should be able to use the same sample for different chips/boards, and Zephyr will automatically select the correct driver for you, depending on your hardware configuration (dts and overlay) and board. E.g. if you want to use SPI, you only need to add CONFIG_SPI in the prj.conf, and if you want to use UART you only need to add CONFIG_SERIAL in the prj.conf file.

Reply Children
  • 0 in reply to Simon

    Yes, that's exactly what I tried to ask. I did not have CONFIG_UART_NRFX in the prj.conf. So "someone" must make it happen. So it's from the board configuration. You explained it well. Thanks.

    This all make sense just a lot of learning. But I think I start to get it.

Related
Terms of service