esb, shockburst, running on nrf5340dk's

[mej7000]

I have 3 nrf boards connected. 2x nrf52832 and 1x nrf5340.

esb_tx is running on nrf52832(682782977)
esb_rx is running on nrf52832(682497942) & nrf5340(1050025410)

west build -b nrf5340dk_nrf5340_cpunet -p builds correctly and flashes without error

PS C:\nrf\esb_prx> west flash -d build_1
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner nrfjprog
There are multiple boards connected.
1. 1050025410
2. 682782977
Please select one with desired serial number (1-2): 1
-- runners.nrfjprog: Flashing file: build_1\zephyr\zephyr.hex
[ #################### ] 2.055s | Erase file - Done erasing
[ #################### ] 0.243s | Program file - Done programming
[ #################### ] 0.243s | Verify file - Done verifying
Applying pin reset.
-- runners.nrfjprog: Board with serial number 1050025410 flashed successfully.

esb_rx is working on the nrf52, but not on the nrf53.

... To be through, I powered down esb_tx_nrf52832(682782977) and flashed another nrf5340dk(1050077823) and programmed it to be esb_tx:

PS C:\nrf\esb_ptx> west flash -d build_1
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner nrfjprog
There are multiple boards connected.
1. 1050025410
2. 1050077823
3. 682497942
Please select one with desired serial number (1-3): 2
-- runners.nrfjprog: Flashing file: build_1\zephyr\zephyr.hex
[ #################### ] 2.044s | Erase file - Done erasing
[ #################### ] 0.235s | Program file - Done programming
[ #################### ] 0.236s | Verify file - Done verifying
Applying pin reset.
-- runners.nrfjprog: Board with serial number 1050077823 flashed successfully.

Although 1050077823 (nrf5340-esb_tx) flashed correctly. Blinky continues to run (as it already had) on nrf5340-esb_tx, which probably makes sense, but I'm not getting any kind of esb response from either (nrf52832 or nrf5340) esb-rx.

There is something I am not understanding about how to flash to nrf5340_CPUNET? Maybe it's flashing correctly, but esb needs to be called from CPUAPP to start it working?? I'm close, but missing something...

Ultimately the goal is to have a network of nrf5340's in a Star configuration. I see that there is shared memory between CPUAPP and CPUNET. I assume somehow it's used to pass data from CPUAPP to CPUNET for transmission/reception. I don't exactly understand how that works either, but I figure the first step is to get the esb Sample to work on nrf5340dk's without modification. But, if there are additional samples that target this use case I would be interested in reviewing those too.

The final configuration goal is to have the center of the star network also be running BLE-UART (so the central esb in the Star Network will relay the esb data from the nodes to a BLE app). I am assuming that there is no problem running both esb and BLE at the same time.

esb_prx_ptx.zip

[ovrebekk]

Hi Michael

mej7000 said:

CONFIG_ESB_MAX_PAYLOAD_LENGTH=64

tx_payload.length = 64;

Looks good. tx_payload.length can be changed from payload to payload, but should be no larger than CONFIG_ESB_MAX_PAYLOAD_LENGTH. The data buffer will be sized according to the CONFIG_ESB_MAX_PAYLOAD_LENGTH parameter. 

mej7000 said:

It looks like I just need to flash the following and counter data moves from ptx->prx->BLE?

1. flash app_netcore to 5340 cpunet(s)
2. flash prx and ptx to the cpuapp(s)

There is no link between the ESB and BLE functionalities in the current example, any ESB -> BLE link would have to be added. The BLE functionality is just a straight port of the peripheral_lbs sample in the SDK. 

Otherwise I agree with your summary

Best regards
Torbjørn

[mej7000]

Thanks. Here is what I found with the BLE/ESB demo.

I flashed peripheral_lbs sample to the 5340 to make sure I understood the sample. peripheral_lbs worked as expected. I could both read btn1 and set led3.

C:\nrf\ncs-esb-ble-mpsl-demo:
It seems that --board nrf5340dk_nrf5340_cpuapp_ns doesn't work, but --board nrf5340dk_nrf5340_cpuapp works.

I included a screen shot and rezipped the demo, although I didn't modify anything I did do 3 nrf5340 builds, so in case I did something wrong there...

1. I am not getting Nordic_lbs advertising.
2. There doesn't seem to be any ESB communication happening.
3. ptx appears to be sending 8 times, before generating errors.

Also, I am not committed to using 5340 if you think a single core (nrf52832?) would work easier/better? Ultimately, all I need to do is have one "parent" in the network that relays ESB data to a BLE peripheral and to the App. The "child" nodes will only run ESB in a star topology. In the past (other hardware) I have used a proprietary protocol with one device additionally running a BLE UART to pass data to the App.

nrf52832

I had better luck with nrf52832 builds. ESB communications happened right away, but I am still not getting any BLE advertising. I included my version with both 5340 and 52832 builds.

ncs-esb-ble-mpsl-demo (2).zip

[ovrebekk]

Hi

mej7000 said:

Packet length will be ~50bytes, so I'm guessing about <300µs transmission time. As long as I'm within a few ms I should be good. I'm sure there will be refinements once the system is working.

The transmission time is not an issue, since it is relatively constant. You just add this time to the timestamp you receive before you update the local time, to compensate. 

The question is the delay between uploading the ACK payload and it actually being sent, I would expect this delay to be much more random, and as such you will not be able to compensate for it. 

But lets cross that bridge when we get there

mej7000 said:

I zipped the entire demo, with my additions, if it helps to look at it. I tried to follow your example for directory structure and to not modify anything I didn't have to.

It is possible for a project to define local Kconfig parameters that only exist for this particular project. These are defined in a file called Kconfig located in the root folder, and since you don't have these parameters in your project the build will fail. Simply copying the Kconfig file from the peripheral_uart sample into the ptx and prx sample folders should fix this. If there already existed a Kconfig file in these projects you would need to merge them. 

Also, the peripheral_uart sample needs a chosen node called nordic,nus-uart in the device tree, which is included in a file called app.overlay. In the case of the ptx and prx samples I would recommend adding this to the board specific overlays located in the board folder. 

I have attached a modified version of your example with these things fixed for the prx sample, and I can now build it (I didn't test the functionality though, I will leave that with you). I tested it based on the 52840DK board, you might have to make some additional changes to have it work for the 52DK: 

ncs-esb-ble-mpsl-demo-nod-mod.zip

To look over all the changes I did you can just open the git bash and check the diff. 

Best regards
Torbjørn

[mej7000]

Thanks! I'm still figuring Kconfig out and I understand what you mean with the app.overlay. I should have at least recognized the files existing in the peripheral_UART sample. I missed that one...

I have (4) 52840dk boards that should be delivered today. In the meantime I added app.overlay to the demo-per-uart sample to accommodate the 52832. That allowed it to compile fine.

However, I had warnings/errors in the prj.conf, uart_async_adapter and app_bt_uart files. I couldn't figure out how to fix that so I moved uart_async_adapter and app_bt_uart into the src folder, adjusted cmake, and all the errors went away in the c and the prj.conf files.

I assume I needed to do more with either kconfig or cmake to get those files to work in the common folder, but I couldn't figure it out with the files in the common folder.

I've gotten to 0 Errors/0 Problems in the compile. It seems very close, but I'm getting "<err> peripheral_uart: Cannot initialize UART callback".

Given that this is the unmodified UART sample that runs fine as a stand alone, there must be something in the configuration that is still holding it back?

It was problems with the "callback" that forced me to move the files out of "common" and into "src".

ncs-esb-ble-mpsl-demo-per-uart.zip

[ovrebekk]

Hi Mike

The UART async adapter is an optional module that you only need if you are planning to use a CDC ACM (USB) comport, it is not necessary if you are using a physical UART. You can read more here. In other words I would just remove this altogether if you don't actually need it. 

The set ballback function typically fails when the UART ASYNC API is not properly enabled. Are you sure that CONFIG_UART_ASYNC_API is properly enabled in the configuration? 

Is it the PTX sample, PRX sample or both that you are struggling with? 

Best regards
Torbjørn

[mej7000]

Hi, It's the PRX. I'm focusing on getting the BLE UART working at this point.

[00:00:00.000,518] <inf> main: ESB PRX BLE Multiprotocol Example
[00:00:00.000,518] <inf> peripheral_uart: Initialize Bluetooth UART
[00:00:00.000,823] <err> peripheral_uart: Cannot initialize UART callback

CONFIG_UART_ASYNC_API=y is set in the prj.conf file and everything compiles without error.

CONFIG_BT_NUS_UART_ASYNC_ADAPTER wasn't in the prj.conf file, so it looks like it's not being used anyway. Enabling CONFIG_BT_NUS_UART_ASYNC_ADAPTER=y, caused a compile error so I took that out. It doesn't look like it's enabled in the peripheral_uart sample either. I tried taking the file out completely, but that didn't make a difference.

	if (IS_ENABLED(CONFIG_BT_NUS_UART_ASYNC_ADAPTER) && !uart_test_async_api(uart)) {
		/* Implement API adapter */
		uart_async_adapter_init(async_adapter, uart);
		uart = async_adapter;
	}

Peripheral_uart sample works as a standalone. At this point I think everything from the peripheral_uart sample has been incorporated, unchanged, into the demo. The Demo compiles fully, but there still seems to be something in the way I combined it with the demo that is causing "Cannot initialize UART callback". But since there are no errors I don't know what to change or where to look?

I attached the code. It builds fine for 52832 or 52840.

ncs-esb-ble-mpsl-demo-per-uart (2).zip

[ovrebekk]

Hi Mike

I am taking an early weekend so I won't have time to look into this today unfortunately. I will test your code on Monday and see if I can spot the issue. 

As a side note, the only real difference between the LBS service used in my sample and the NUS service is that the former configures the characteristics as 1 byte length while the later uses variable length characteristics. You could quite easily configure one to be similar to the other.

Do you actually need the UART functionality from the peripheral_uart example, or is it only the BLE functionality that you want to use? 
If yes, couldn't you just remove all the UART related code from the app_bt_uart module? 

The way I like to structure these examples is to have the app_bt_xxx modules handle Bluetooth related functionalities only. Any code interfacing sensors or other interfaces should run either from main.c, or from another module. 

Best regards
Torbjørn

[mej7000]

Hi, Thanks. Enjoy the weekend!

You are correct in that all I really want to do is pass a ~64 byte length to/from BLE (and relay those 64byes to/from shockburst). I had considered adapting bt_lbs, but initially thought incorporating peripheral_uart would be easier... I'll look at adapting bt_lbs.

In the meantime I've determined that either one of these settings prevent the callback function working correctly. Commenting out both of those and BLE UART works as expected, but I am unsure of why they're a problem.

CONFIG_CONSOLE_HANDLER=y
CONFIG_CONSOLE_GETCHAR=y

*** Booting nRF Connect SDK v2.5.1 ***
[00:00:00.000,518] <inf> main: ESB PRX BLE Multiprotocol Example
[00:00:00.000,549] <inf> peripheral_uart: Initialize Bluetooth UART
[00:00:00.000,854] <err> peripheral_uart: Cannot initialize UART callback

ncs-esb-ble-mpsl-demo-per-uart (3).zip

[ovrebekk]

Hi Mike

Good to hear that you got it working

I can see that the CONSOLE_HANDLER configuration selects (enables) the interrupt driven driver here. I assume this is why it prevents the async based code from working properly. 

Best regards
Torbjørn

[mej7000]

Hi Torbjørn,

I am hoping you can help me with the ble-esb-mpsl-demo. I saw that you updated it yesterday. I upgraded to nRF Connect SDK v2.6.0 to match the requirements.

You code worked exactly as expected. It's the lbs part that is a problem for me. Instead of the boolean from the button, I need to relay the esb_rx data as it arrives directly to BLE so I needed to modify that part of the code. It is close to working... The attached image shows what I changed and where I think the problem is.

Standard esb_tx is already setup in my custom application. I don't believe it makes a difference, but I am using the standard esb_tx sample as the sender not the esb_tx from your demo. I think that is why I am getting the "Counter" warning.

I never need esb_tx and BLE to run at the same time. I only need esb_rx and BLE to timeslot.

1. removed all nrf5340 files for my own clarity, I'm using nrf52840dk board.
2. copied lbs.c and lbs.h into the project so that I could modify/replace: bt_lbs_send_button_state()
3. adjusted CMake to reflect file changes
4. commented out CONFIG_BT_LBS and CONFIG_BT_LBS_POLL_BUTTON

when I press the button I now call "bt_lbs_send_button_state_2()" with a pointer to a data array. I receive the mock data array over BLE as expected.

However, if I use the esb_callback function to call "bt_lbs_send_button_state_2()" I get the "No ATT channel for MTU...etc..." problem.

Calling "bt_lbs_send_button_state_2()" directly from within the esb callback caused a kernel panic so I added a workqueue.

As always, you help is greatly appreciated!

6303.ncs-esb-ble-mpsl-demo.zip

[ovrebekk]

Hi Mike

What if you try to send 20 bytes only, rather than 64? Does it work fine then? 

Since I only used the LBS sample in the example I didn't bother configuring the BLE stack for extended data length or ATT MTU, which is probably why you are having issues getting larger notifications to work. 

Could you try to copy the configuration from a different example I worked on recently, which is set up for high throughput? 
You will find the relevant appcore config here and the netcore config here. 

Best regards
Torbjørn