Peripheral UART example does not run on 7002DK

[Fisherdude]

I have been successfully using the Peripheral UART example on a 5340DK board. I tried rebuilding for the 7002DK, and am getting runtime errors. The UART initializes, but the call to bt_enable() returns EAGAIN:

[00:00:17.895,446] [0m<inf> peripheral_uart: Wait for DTR[0m
[00:00:18.395,874] [0m<inf> peripheral_uart: DTR set[0m
[00:00:18.411,468] [0m<inf> peripheral_uart: Uart initialized[0m
[00:00:18.420,532] [0m<inf> fs_nvs: 2 Sectors of 4096 bytes[0m
[00:00:18.420,532] [0m<inf> fs_nvs: alloc wra: 0, fe8[0m
[00:00:18.420,562] [0m<inf> fs_nvs: data wra: 0, 0[0m
[00:00:19.421,752] [1;31m<err> bt_hci_driver: Endpoint binding failed with -11[0m
[00:00:19.421,783] [1;31m<err> bt_hci_core: HCI driver open failed (-11)[0m
[00:00:19.421,813] [1;31m<err> peripheral_uart: Failed to enable Bluetooth (err: -11)[0m

Any suggestions? Am I naive to assume the 5340 should work the same on both the 5340DK and 7002DK boards?

Thanks,
Rick

[AHaug]

Hi,

Am I naive to assume the 5340 should work the same on both the 5340DK and 7002DK boards?

To some extent, but not too naive. I'll try to explain here. The nrf5340 on the nRF7002DK has other assignments than the sole 5340SoC on the nRF5340DK has. In the nRF7002DK its job is to control the nRF7002 Wifi chip + the application you develop. 

The next thing that you will have to consider when mixing in BLE with the nRF700x series is the fact that you can do both BLE and Wifi simultaneously, but you will have to implement a routine that multiplexes the 2.4GHz WiFi and BLE radio usage since there is only one radio present on the board. See this sample for reference: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/wifi/ble_coex/README.html 

Another reference I recommend that you use is the WiFi fundamentals course at our academy pages (https://academy.nordicsemi.com/courses/wi-fi-fundamentals/), as well as any other relevant nRF Connect SDK fundamentals/intermediary and BLE fundamentals course found here https://academy.nordicsemi.com. The WiFi course does not go through WiFi + BLE coexistence, but its still a good reference.

To summary:

To implement peripheral_uart support for the nrf5340 I would recommend that you use the wifi-ble_coexistence sample as a basis and try to integrate the peripheral_uart implementation on top of this. This should allow you to understand better how coexistence between WiFi and BLE works on the nRF7002DK. 

Let me know if this answers your question,

Kind regards,
Andreas

[Fisherdude]

Thanks, Andreas. I'll look at the documentation and see if it helps. I'm not currently *intentionally* enabling the wi-fi on the nRF7002DK, although that is the plan going forward. So certainly the coexistence documentation will help there. 

[Fisherdude]

More information. I had been programming the board via "Debug with Ozone". When I used the "Flash" option in nRF Connect VS Code, I initially got an error. When I let Flash erase and restore the image, it started working.

So bottom line, the UART Peripheral example *does* work with no modification between the two boards (other than the board selection) if it gets fully programmed.

Any ideas on how the network MCU may have been corrupted, and why doing an erase and flash with Ozone did not restore it?

Thanks

[AHaug]

My thoughts is that when you do it through Ozone you don't necessarily get the full firmware that you need for the application. Lets say that you for instance only upload the application .elf or that you only upload an .elf file when using Debug with Ozone to program the board, you don't get the also required bootloader MCUBoot (given that you have that) or any other required images in the multi-image build that is the firmware for a 7002DK.

When flashing with VS Code, you're using "West Flash", which in turn is built to ensure that you get all the relevant images from the build folder when flashing.

Just a disclaimer, this is just my thoughts and I've not verified it since I have little experience with using Ozone, but it's worth investigating from your end.

On newer DKs it is also often required to do a recover when flashing for the first time to unlock some registers (this is prompted when attempting to flash a new DK for the first time in VS Code), so that might be why you had to erase it with West Flash.

Fisherdude said:

So bottom line, the UART Peripheral example *does* work with no modification between the two boards (other than the board selection) if it gets fully programmed.

Thats good to hear! I see that the nRF7002DK is not mentioned under requirements for the peripheral UART sample, so just note that the sample has not been fully tested for that board.

Kind regards,
Andreas

[Fisherdude]

AHaug said:

On newer DKs it is also often required to do a recover when flashing for the first time to unlock some registers (this is prompted when attempting to flash a new DK for the first time in VS Code), so that might be why you had to erase it with West Flash.

I'm sure this is the root cause of what I was seeing. Good to know!