esb, shockburst, running on nrf5340dk's

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

0 mej7000 10 months ago in reply to ovrebekk
"CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING was assigned the value y, but got the value n. Missing dependencies: SOC_SERIES_NRF52X"

...

ovrebekk said:
For larger payloads this macro can't really be used, you would have to assign data to the tx_payload.data[] buffer in some other way.

Thanks. I was surprised to see the macro limited to 63 and feared I was misunderstanding something.

As a test I did the following, which seems to work fine:

CONFIG_ESB_MAX_PAYLOAD_LENGTH=64

tx_payload.length = 64;

I think I am ready to start with the BLE/ESB sample.

ovrebekk said:
You will find a separate sample for the nRF5340 netcore, while the prx and ptx sample can be built either for the nRF5340 appcore, or for one of the nRF52 devices.

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

flash app_netcore to 5340 cpunet(s)

flash prx and ptx to the cpuapp(s)
- Cancel
- Vote Up 0 Vote Down
- Sign in to reply
- Verify Answer
- Cancel

0 ovrebekk 10 months ago

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?

flash app_netcore to 5340 cpunet(s)

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

0 mej7000 10 months ago in reply to ovrebekk

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...

I am not getting Nordic_lbs advertising.
There doesn't seem to be any ESB communication happening.
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

0 ovrebekk 10 months ago in reply to mej7000

Hi Michael

mej7000 said:
It seems that --board nrf5340dk_nrf5340_cpuapp_ns doesn't work, but --board nrf5340dk_nrf5340_cpuapp works.

Yes, the nrf5340dk_nrf5340_cpuapp_ns board hasn't been tested and is unlikely to work properly.

mej7000 said:
I am not getting Nordic_lbs advertising.

The device will advertise a different name, as set in prj.conf:

CONFIG_BT_DEVICE_NAME="Nordic_MPSL_LBS"

You can't see this device either?

mej7000 said:
There doesn't seem to be any ESB communication happening.

Did you make the change in esb_peripherals.h as mentioned in the log?

Essentially you need to replace SWI0 with SWI3 in this file:

/** The ESB event IRQ number when running on an nRF5 device. */
#define ESB_EVT_IRQ        SWI3_IRQn
/** The handler for @ref ESB_EVT_IRQ when running on an nRF5 device. */
#define ESB_EVT_IRQHandler SWI3_IRQHandler

I hope to find a better way to fix this in a future update. Now that I think if it maybe I can undef and redefine these somehow in the application files, to avoid having to change the SDK files.

mej7000 said:
ptx appears to be sending 8 times, before generating errors.

The application FIFO is 8 items large, which is why it appears to work 8 times. In reality none of the messages are being sent, which usually means there is no PRX enabled to pick up the packets. Alternatively it could be an issue if you didn't change the SWI definition as mentioned above.

mej7000 said:
Also, I am not committed to using 5340 if you think a single core (nrf52832?) would work easier/better?

Using the nRF52 series is definitely easier. Unless you have a need for the additional performance or peripherals of the nRF5340 I would recommend sticking to one of the nRF52 devices.

If you still can't find the issue based on my input above I will take a look at your build and see if I can spot the issue.

Best regards
Torbjørn

0 mej7000 10 months ago in reply to ovrebekk

I reflashed a nrf52832 and still didn't get the BLE advertising. As I have done in the past, I was using LightBlue, but switched over to nRF Connect (which automatically upgraded to the latest version). "Nordic_MPSL_LBS" showed up in the list. I switched back to LightBlue thinking LightBlue was the problem and "Nordic_MPSL_LBS" showed up there as well! I killed all the apps and reflashed the 52832 and it showed up right away in both. I can't seem to get it not to work!

It's not entirely clear why it started working, but now I can't break it, so something seems to have resolved my problem. Makes no sense to me that one App upgrade would make a difference, but that was the only change I recognized...?

The LED's don't respond at all, neither in Advertising nor on ButtonPress, but the Button1 seems to notify its status over BLE. ESB data is exchanged between two 52832's (monitored in serial). I see what you mean that although the two are working there is no connection between BLE and ESB data.

I am curious about this. Yes, I did read that, but I can't find esb_peripherals.h in my local repo or on yours. Am I doing something wrong?

ovrebekk said:
Did you make the change in esb_peripherals.h as mentioned in the log?

Essentially you need to replace SWI0 with SWI3 in this file:

This Sample is brilliant and 90% of what I was looking for. Thanks! Switching to nrf52 did seem to make it easier, but that is probably because I am still figuring out how to work the nrf53.

My goal now is to send data and commands through BLE and a ESB star network

Data Flow: ptx(child)->prx(parent)->BLE->App
Command Flow: App->BLE->prx/ptx(parent)->ptx/prx(child)

I would think that would make a killer Nordic Sample/Solution for a lot of users. I have done something similar with ESP32 using UART peripheral.

What you provided already has been invaluable and gets me very close to what I need. If you have any more suggestions or guidance on getting to my ultimate goal please let me know. thanks, mike