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:

I believe that is allowable as all the ptx nodes will be in transmit mode and only switch to prx when waiting for an ACK. I anticipate having multiple ptx on one pipe and using different pipes for additional "groups" of ptx. The limited testing (3 ptx nodes on one pipe) seems to be working. I anticipate up to 10-12 ptx nodes per pipe. Does that scenario sound ok to you? 

Having multiple PTX's transmitting to the same PRX is a pretty common use case. Whether or not it is feasible depends more on the total number of packets you expect pr second, and what your latency requirements are, than how many PTX's you have in total.
The ability to configure the retransmit time in ESB is a feature primarily designed for this use case: By configuring each PTX with a unique non-overlapping retransmit delay you can ensure that in case of a packet collision the two PTX's will retransmit the packet at different points in time, avoiding a collision on the next retransmit.  

mej7000 said:

I am very anxious to get to the ESB/BLE part. I just want to make sure I have the basic ESB down before I move forward.

Sounds like a wise strategy

mej7000 said:

I'm not certain as to what clock is used for the cpunet and/or shockburst? 

The ESB library relies mostly on the natural timing of the radio peripheral, except for ACK timeout and retransmit timing which is handled by a TIMER module sourced from the HF clock. 

mej7000 said:

I'm using "k_uptime_get()" to time the events and it seems that it relies on CONFIG_SYS_CLOCK_TICKS_PER_SEC which is set to 32768, so I believe (guessing) the accuracy of k_uptime_get is dependent on the XL1/XL2 external oscillator?

The Zephyr timing methods uses the LF clock, correct, in order to allow decent sleep currents. By default the LF clock will be sourced from the external LF crystal, but you can also use internal source if no crystal is available (at a great hit to accuracy obviously). 

mej7000 said:

Can I put the single output TXCO clock line on only one of the XLx pins? Is it possible to put TXCO clock on XL1 and leave XL2 floating?

This is certainly possible from a hardware perspective. I am not sure how you would configure this in Zephyr though, I need some time to look into this. 

Best regards
Torbjørn

[mej7000]

Thanks! That sounds good. My transmissions are minimal. A few, at most, per second.

Thanks for checking the hardware. If it helps, here is exactly what I was thinking for the Raytac MDBT53-1M module and the SiT1566 TCXO (Y1).

https://www.mouser.com/datasheet/2/371/SiT1566_datasheet-1511368.pdf

https://www.raytac.com/download/index.php?index_id=60

 

[ovrebekk]

Hi Michael

The schematic looks fine. 

Software wise you should be able to configure external rail to rail LF clock by using the configuration parameter described here:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.5.1/kconfig/index.html#CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING

Best regards
Torbjørn

[mej7000]

Thanks. I was able to compile successfully. However it generated the following warning...

"warning: The choice symbol CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING (defined at
drivers/clock_control/Kconfig.nrf:51) was selected (set =y), but CLOCK_CONTROL_NRF_K32SRC_XTAL
(defined at drivers/clock_control/Kconfig.nrf:37) ended up as the choice selection. See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING and/or look up CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING in the menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful too."

I don't really understand what the setting actually does and I couldn't find an explanation anywhere... closest I found was this in devzone:

"Since you are using an oscillator instead of a low frequency crystal, try configuring the oscillator to EXT_FULL_SWING or EXT_LOW_SWING(depending on the oscillator)."

I also found these alternatives settings:

# CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING=y
# CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_LOW_SWING=y
# CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
# CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

It seems CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING  is related to the type of clock source and that XL2 floating is not a problem... Can you help me understand what these options are for?

Also, (from the ptx sample) is this the best way to define the payload?

static struct esb_payload tx_payload = ESB_CREATE_PAYLOAD(0,

    0x01, 0x00, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08);

based on the ptx sample it appears that if I want a payload of char[40] I would have to do the following:

static struct esb_payload tx_payload = ESB_CREATE_PAYLOAD(0,

    0x01, 0x00, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A,

    0x01, 0x00, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A,

    0x01, 0x00, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A,

    0x01, 0x00, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A);

And, if ESB_CREATE_PAYLOAD .payload - "Comma separated list of character data to put in the TX buffer. Supported values consist of 1 to 63 characters." What happens if your ESB_MAX_PAYLOAD_LENGTH is longer than 63, like 128?

CONFIG_ESB_MAX_PAYLOAD_LENGTH=128

config ESB_MAX_PAYLOAD_LENGTH

    int "Maximum payload size"

    default 32

    range 1 252

    help

      The maximum size of the payload.

I would think that ESB_CREATE_PAYLOAD would need to support up to 252 characters, but maybe I am misunderstanding?

[ovrebekk]

Hi Michael

Can you confirm that the issues with the CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING configuration occur when you're building for the nRF5340? 

It seems this configuration is only supported for the nRF52 series, not the nRF53. I will need to check what the recommended way is for enabling this on the nRF53 side and get back to you. 

mej7000 said:

I would think that ESB_CREATE_PAYLOAD would need to support up to 252 characters, but maybe I am misunderstanding?

The ESB_CREATE_PAYLOAD macro is just a convenience macro for easily defining a static payload in the code. It uses another macro under the hood to handle a dynamic number of arguments (for the data bytes), and this macro is limited to 63 input variables. 

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. 

Best regards
Torbjørn