ESB module stops transmitting payloads

[dingari]

I have been encountering a rather latent bug in a  product that we are developing. It consists of a custom nRF52832 board, that is connected to an nRF52-DK via ESB, and the DK relays the payloads to a computer via serial UART. Both sides use SDK v15.0.0.

The problem arises very randomly. What happens is that after some time we repeatedly get `NRF_ERROR_NO_MEM` when calling `nrf_esb_write_payload`. It seems like the ESB module isn't processing the TX fifo anymore, and the whole communication channel comes to a halt. I've stopped the application in the debugger when this happens, and indeed `m_tx_fifo.count` is 8 (full), and more interestingly `m_nrf_esb_mainstate` is `NRF_ESB_STATE_PTX_RX_ACK`.

The modules are set up to ack on every packet, and occasionally the PRX side sends payloads along with the ack.

Furthermore, this seems to be more apparent with increased payload lengths. Initially, we were sending payloads of ~100 bytes. Reducing it down to 40 bytes, we didn't notice this error.

Some of our attempts to recover from this state are:

• Manually starting TX with `nrf_esb_start_tx`, but that doesn't work since t he module isnt in the idle state.
• Flushing the TX queue, but it just fills right back up since the module doesn't transmit any payloads.
• Re-initializing the ESB module on the PTX side by calling `nrf_esb_init` again, but that just results in the same error right away.

This is how the config is set up for the PTX side:

nrf_esb_config_t nrf_esb_config = NRF_ESB_DEFAULT_CONFIG;
nrf_esb_config.protocol           = NRF_ESB_PROTOCOL_ESB_DPL;
nrf_esb_config.bitrate            = NRF_ESB_BITRATE_2MBPS;
nrf_esb_config.event_handler      = event_handler;
nrf_esb_config.mode               = NRF_ESB_MODE_PTX;
nrf_esb_config.selective_auto_ack = false;
nrf_esb_config.tx_output_power    = NRF_ESB_TX_POWER_4DBM;

 

And this is the PRX side:

nrf_esb_config_t nrf_esb_config = NRF_ESB_DEFAULT_CONFIG;
nrf_esb_config.payload_length     = 8;
nrf_esb_config.protocol           = NRF_ESB_PROTOCOL_ESB_DPL;
nrf_esb_config.bitrate            = NRF_ESB_BITRATE_2MBPS;
nrf_esb_config.mode               = NRF_ESB_MODE_PRX;
nrf_esb_config.event_handler      = nrf_esb_event_handler;
nrf_esb_config.selective_auto_ack = false;
nrf_esb_config.tx_output_power    = NRF_ESB_TX_POWER_4DBM;

Looking at it now, I can see that there is a discrepancy in the `payload_length` field of the config. Does this field have any effect if using `NRF_ESB_PROTOCOL_ESB_DPL`?

[ovrebekk]

Hi 

You would need to set the payload_length equal to the largest payload that you might send, otherwise the length field in the payload might not be large enough to cater for the larger payloads. 

Up to 63 byte payloads a 6-bit length field can be used, but for larger payloads the length field will have to be increased to 8 bits, and this is set by the payload_length configuration. 

That being said I would expect this issue to result in an error immediately, unless you are sending payloads of varying length. Can you confirm if this is the case?

Best regards
Torbjørn

[dingari]

Hi, I've updated the payload_length field on both the PTX and PRX to the max payload length (>63 bytes), and I haven't run into the error (at least not yet, and I've not found any systematic way of reproducing it).

The strange thing is that the module was transmitting ~100 byte payloads without a problem with the old configuration.

Anyway, I'll mark this as closed for now, but it would be very beneficial if the nrf_esb_write_payload payload would assert on this condition.

[ovrebekk]

Hi 

Thanks for the feedback. I thought we had a check on this already, but apparently not. I will report it to the developers

Best regards
Torbjørn

[ovrebekk]

Hi again

It seems my earlier comment wasn't entirely correct. It is the NRF_ESB_MAX_PAYLOAD_LENGTH define (line 91 of nrf_esb.h) that determines if 6 or 8 bit length field is used, not the payload_length configuration. 

Can you confirm whether or not you changed this define?

Best regards
Torbjørn

[dingari]

Hi, we have always had NRF_ESB_MAX_PAYLOAD_LENGTH  set to 252. I only changed the payload_length fields in the config.

So, if not the payload_length field, what else could be causing this issue?

[ovrebekk]

Hi

I think I will have to reproduce the problem on my end to be able to investigate further. 

I think I should have the information I need in this case to set up a similar test, unless there is anything else you think might be relevant in the way that you used the protocol when the problem occurred?

Also, do you consider the issue fixed on your end?
Because of upcoming travel and vacation on my end it might take some time to get to the bottom of this. 

Best regards
Torbjørn

[dingari]

Hi,

I haven´t had time to verify exactly if the issue is solved (it's rather hard/impossible to systematically reproduce). But in the short time I tested the potential fix, it was working fine.

I'll report back when I can say for certain if the fix worked.

Have a nice vacation!