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

[mej7000]

Thanks! That makes it much clearer. Pipes are different from what I thought, but I feel good that the design should work. I am planning on using the ptx HW_ID as part of the data packet for the iOS App anyway. It sounds like that might be useful for ESB addressing as well.

ovrebekk said:

Another advantage of the pipe system is that the PRX can pre-load ACK payloads for the different pipes in advance, so that whichever PTX sends data to you next will get the correct ACK payload in return.

This is super interesting. I hadn't considered using different responses on different pipes. I've preloaded the ACK with a timestamp and that works really well. It may make sense to have a "timestamp" pipe, a "data" pipe and a "command" pipe... there might be something really useful I can do with that.

[ovrebekk]

Hi Mike

You could allocate the pipes any way you see fit, certainly. But there is something to be said for the "if it works don't fix it" reasoning as well, if you have a working system already you might just stick to that

When preloading an ACK with a timestamp do keep in mind that you might not know exactly when the next packet will come from a PTX, and as such how much delay there will be in the process of preparing the timestamp and it being received by one of the PTX's. This will introduce some inaccuracy in the timesync.

I am guessing you don't need microsecond level of synchronization though, and that you can accept a bit of error. 

Best regards
Torbjørn

[mej7000]

You make a great point. As development unfolds it's good to know I have the option... There will be redundancy in with the timestamp ACK responses every 5-10 seconds. Network traffic won't be much, but I do need to handle any occasional collisions. 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.

I basically have the child (ptx) done and now it's time to circle back to the "parent" (prx). The parent relies heavily on your "ncs-esb-ble-mpsl-demo" as that is the node to split BLE and ESB duty.

I made very minor additions to get LED2 to toggle (just to indicate successful BLE write). Compiled and everything works as expected.

What I need to do now is replace the "peripheral_lbs" with "peripheral_uart" so that I can receive ESB rx_payload and relay it out over BLE and also push BLE data/commands out through ESB tx_payload.

As always I am open to suggestions, but I've been trying to add "peripheral_uart" (which was compiled and working as a stand alone) to your ncs-esb-ble-mpsl-demo. "../common/uart_async_adapter.c" seems to be fine added to the CMakeList file, but if I add "../common/app_bt_uart.c" to the CMakeLists file I get compile errors that I don't understand.

Is my approach sound or is there a better way of modifying your demo to use peripheral_uart? I also tried removing peripheral_lbs, but that didn't work any better.

I've also loaded the prj.conf file with everything from peripheral_uart. Just that alone didn't cause any compile problems, but I noticed that even in the original demo there are warnings about missing CONFIG's that clearly exist in the prj.conf file (I don't fully understand why I am getting those warnings in the original demo, but it seems to be working correctly)

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.

../common/app_bt_uart.c is commented out in the CMakeList file, so that it compiles correctly, but uncomment that and you get the following errors.

target_sources(app PRIVATE
src/main.c
../common/app_bt_lbs.c
../common/uart_async_adapter.c
# ../common/app_bt_uart.c
)

...

-MT CMakeFiles/app.dir/C_/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c.obj -MF CMakeFiles\app.dir\C_\nrf\ncs-esb-ble-mpsl-demo\common\app_bt_uart.c.obj.d -o CMakeFiles/app.dir/C_/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c.obj -c C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c
In file included from C:/ncs/v2.5.1/zephyr/include/zephyr/toolchain/gcc.h:92,
from C:/ncs/v2.5.1/zephyr/include/zephyr/toolchain.h:50,
from C:/ncs/v2.5.1/zephyr/include/zephyr/sys/time_units.h:10,
from C:/ncs/v2.5.1/zephyr/include/zephyr/sys/util.h:615,
from C:/ncs/v2.5.1/zephyr/include/zephyr/devicetree.h:25,
from C:/ncs/v2.5.1/zephyr/include/zephyr/device.h:12,
from C:/nrf/ncs-esb-ble-mpsl-demo/common/uart_async_adapter.h:22,
from C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:10:
C:/ncs/v2.5.1/zephyr/include/zephyr/device.h:85:41: error: '__device_dts_ord_DT_CHOSEN_nordic_nus_uart_ORD' undeclared here (not in a function)
85 | #define DEVICE_NAME_GET(dev_id) _CONCAT(__device_, dev_id)
| ^~~~~~~~~
C:/ncs/v2.5.1/zephyr/include/zephyr/toolchain/common.h:132:26: note: in definition of macro '_DO_CONCAT'
132 | #define _DO_CONCAT(x, y) x ## y
| ^
C:/ncs/v2.5.1/zephyr/include/zephyr/device.h:85:33: note: in expansion of macro '_CONCAT'
85 | #define DEVICE_NAME_GET(dev_id) _CONCAT(__device_, dev_id)
| ^~~~~~~
C:/ncs/v2.5.1/zephyr/include/zephyr/device.h:211:37: note: in expansion of macro 'DEVICE_NAME_GET'
211 | #define DEVICE_DT_NAME_GET(node_id) DEVICE_NAME_GET(Z_DEVICE_DT_DEV_ID(node_id))
| ^~~~~~~~~~~~~~~
C:/ncs/v2.5.1/zephyr/include/zephyr/device.h:228:34: note: in expansion of macro 'DEVICE_DT_NAME_GET'
228 | #define DEVICE_DT_GET(node_id) (&DEVICE_DT_NAME_GET(node_id))
| ^~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:62:36: note: in expansion of macro 'DEVICE_DT_GET'
62 | static const struct device *uart = DEVICE_DT_GET(DT_CHOSEN(nordic_nus_uart));
| ^~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:53:23: error: 'CONFIG_BT_NUS_UART_BUFFER_SIZE' undeclared here (not in a function)
53 | #define UART_BUF_SIZE CONFIG_BT_NUS_UART_BUFFER_SIZE
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:67:22: note: in expansion of macro 'UART_BUF_SIZE'
67 | uint8_t data[UART_BUF_SIZE];
| ^~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c: In function 'uart_cb':
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:55:26: error: 'CONFIG_BT_NUS_UART_RX_WAIT_TIME' undeclared (first use in this function)
55 | #define UART_WAIT_FOR_RX CONFIG_BT_NUS_UART_RX_WAIT_TIME
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:160:32: note: in expansion of macro 'UART_WAIT_FOR_RX'
160 | UART_WAIT_FOR_RX);
| ^~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:55:26: note: each undeclared identifier is reported only once for each function it appears in
55 | #define UART_WAIT_FOR_RX CONFIG_BT_NUS_UART_RX_WAIT_TIME
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:160:32: note: in expansion of macro 'UART_WAIT_FOR_RX'
160 | UART_WAIT_FOR_RX);
| ^~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c: In function 'uart_work_handler':
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:55:26: error: 'CONFIG_BT_NUS_UART_RX_WAIT_TIME' undeclared (first use in this function)
55 | #define UART_WAIT_FOR_RX CONFIG_BT_NUS_UART_RX_WAIT_TIME
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:222:60: note: in expansion of macro 'UART_WAIT_FOR_RX'
222 | uart_rx_enable(uart, buf->data, sizeof(buf->data), UART_WAIT_FOR_RX);
| ^~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c: At top level:
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:577:1: error: expected identifier or '(' before '{' token
577 | {
| ^
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:39:19: error: 'CONFIG_BT_NUS_THREAD_STACK_SIZE' undeclared here (not in a function); did you mean 'CONFIG_WFA_QT_THREAD_STACK_SIZE'?
39 | #define STACKSIZE CONFIG_BT_NUS_THREAD_STACK_SIZE
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/ncs/v2.5.1/zephyr/include/zephyr/sys/util.h:232:28: note: in definition of macro 'ROUND_UP'
232 | ((((unsigned long)(x) + ((unsigned long)(align) - 1)) / \
| ^
C:/ncs/v2.5.1/zephyr/include/zephyr/kernel/thread_stack.h:223:21: note: in expansion of macro 'Z_KERNEL_STACK_SIZE_ADJUST'
223 | sym[Z_KERNEL_STACK_SIZE_ADJUST(size)]
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
C:/ncs/v2.5.1/zephyr/include/zephyr/kernel/thread_stack.h:260:9: note: in expansion of macro 'Z_KERNEL_STACK_DEFINE_IN'
260 | Z_KERNEL_STACK_DEFINE_IN(sym, size, __kstackmem)
| ^~~~~~~~~~~~~~~~~~~~~~~~
C:/ncs/v2.5.1/zephyr/include/zephyr/kernel/thread_stack.h:339:41: note: in expansion of macro 'K_KERNEL_STACK_DEFINE'
339 | #define K_THREAD_STACK_DEFINE K_KERNEL_STACK_DEFINE
| ^~~~~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:652:1: note: in expansion of macro 'K_THREAD_DEFINE'
652 | K_THREAD_DEFINE(ble_write_thread_id, STACKSIZE, ble_write_thread, NULL, NULL,
| ^~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:652:38: note: in expansion of macro 'STACKSIZE'
652 | K_THREAD_DEFINE(ble_write_thread_id, STACKSIZE, ble_write_thread, NULL, NULL,
| ^~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:558:13: warning: 'configure_gpio' defined but not used [-Wunused-function]
558 | static void configure_gpio(void)
| ^~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:513:25: warning: 'nus_cb' defined but not used [-Wunused-variable]
513 | static struct bt_nus_cb nus_cb = {
| ^~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:462:36: warning: 'conn_auth_info_callbacks' defined but not used [-Wunused-variable]
462 | static struct bt_conn_auth_info_cb conn_auth_info_callbacks;
| ^~~~~~~~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:461:31: warning: 'conn_auth_callbacks' defined but not used [-Wunused-variable]
461 | static struct bt_conn_auth_cb conn_auth_callbacks;
| ^~~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:233:12: warning: 'uart_init' defined but not used [-Wunused-function]
233 | static int uart_init(void)
| ^~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:79:29: warning: 'sd' defined but not used [-Wunused-const-variable=]
79 | static const struct bt_data sd[] = {
| ^~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:74:29: warning: 'ad' defined but not used [-Wunused-const-variable=]
74 | static const struct bt_data ad[] = {
| ^~
[116/227] Building C object zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/fatal.c.obj
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: 'C:\ncs\toolchains\c57af46cb7\opt\bin\cmake.EXE' --build 'C:\nrf\ncs-esb-ble-mpsl-demo\prx\build52832'
PS C:\nrf\ncs-esb-ble-mpsl-demo\prx>

ncs-esb-ble-mpsl-demo (3).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