This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Possible error in nRF5 SDK for ESB DPL transmissions with "selective auto ack" (

Hi folks,

I've found no beeter way of reporting this (no public SDK repo which allows issues with code reference).

I tried to TX ESB DPL frames from an nRF52840 to different versions of nRF24. The frames made it on air, but didn't get acknowledged.

To make a long story short, I assume the following code in  `nrf_esb.c` is wrong:

static void start_tx_transaction()
{
    ...snip...

    switch (m_config_local.protocol)
    {
        case NRF_ESB_PROTOCOL_ESB:
            ...snip...
            break;

        case NRF_ESB_PROTOCOL_ESB_DPL:
            ... snip ...
            // note: noack shouldn't be negated befor OR'ing onto S1 field
            //m_tx_payload_buffer[1] |= mp_current_payload->noack ? 0x00 : 0x01;
            m_tx_payload_buffer[1] |= mp_current_payload->noack ? 0x01 : 0x00;

            memcpy(&m_tx_payload_buffer[2], mp_current_payload->data, mp_current_payload->length);

... snip ...

The unmodified code leads to RF frames with "no ack" bit in PCF set if the "noack" bool in the `nrf_esb_payload_t` struct is false.

So the flag is effectivly negated, leading to unintended behavior in PTX mode with selective acknowledgement.

Regards,

Marcus

Parents
  • Addition: This is for SDK 15.2, haven't checked 15.03.

    A code repository with issue tracking would be helpful (referencing codefiles, lines etc.) would be helpful and ease up reporting such issues (version agnostic)

  • Hello,

    Can you provide detailed chip marking on the nRF24L- devices you are using here? Have you bought these through a nordic distributor?

    Best regards,
    Kenneth

  • Sorry, I can't provide reliable info on this, as my peers are different Unifying dongles.

    For CU0007 I assume nRF24LU1+, while CU0012 is assumed to be TI CC2544 (shows same behavior).

    Other peers I used are all nrf52840 (Nordic USB dongle, Makerdiary MDK, Makerdiary MDK USB Dongle) .

    To be honest, everything works as define per specs: If a frame with "no ack" bit set is sent to a PRX with "selective auto ack" there's no ack in reply.

    The problem is, that I have to set the "noack" boolean to true in the nrf_esb_payload_t struct, to get an RF frame with unset "no ack" flag bit transmitted (when using selective ack in TX on nRF5 SDK).

    The code snippet which is responsible for this "flag negation" is part of the initial post (wring version commented out, correct version in line below).

Reply
  • Sorry, I can't provide reliable info on this, as my peers are different Unifying dongles.

    For CU0007 I assume nRF24LU1+, while CU0012 is assumed to be TI CC2544 (shows same behavior).

    Other peers I used are all nrf52840 (Nordic USB dongle, Makerdiary MDK, Makerdiary MDK USB Dongle) .

    To be honest, everything works as define per specs: If a frame with "no ack" bit set is sent to a PRX with "selective auto ack" there's no ack in reply.

    The problem is, that I have to set the "noack" boolean to true in the nrf_esb_payload_t struct, to get an RF frame with unset "no ack" flag bit transmitted (when using selective ack in TX on nRF5 SDK).

    The code snippet which is responsible for this "flag negation" is part of the initial post (wring version commented out, correct version in line below).

Children
Related