• State Not Answered
  • Replies 3 replies
  • Subscribers 69 subscribers
  • Views 164 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 331304
Options

kicking up a bug on an older nrf24 board.

ulao

I have a product that has a bug and I'm forced to go thru some older code. This was the nrf24 plus chip. The code still runs fine, and most of the function I created do all the requires steps but in an effort to narrow down problem I just can not really recall how this thing works.

if needed I can include the details in the function but I know this stiff works so trying to keep it a bit sort,. Here is some example code

enable();
sendCommand(0x60);
returnPayloadSize = sendCommand(0x00);//get payload size.
disable();   

checkSum=0;
enable();
sendCommand(0x61);//read data
memset(returnNrf2Payload, 0,returnPayloadSize);
for (unsigned char d = 0; d < returnPayloadSize; d++)     
{
            returnNrf2Payload[d]=sendCommand(0x00);
            if (d < (returnPayloadSize-1) ) checkSum ^= returnNrf2Payload[d]; //all but last.
}
disable();

that code work fine, I get my size and data comes in. Strangely my data is all zeros but that is not my main confusion.

If  do this

enable();
sendCommand(0x60);
var1 = sendCommand(0x00);
disable();
enable();
sendCommand(0x61);    
var2 = sendCommand(0x00);    
disable();

var 1 and 2 are the same as they were before, but according to the data sheet  "Payload is deleted from
FIFO after it is read" /so that can not be? I thought there was a buffer for multiple rx in but I also tried to flush and clear the rx flag, still the data persists.

Parents
  • 0

    Hello,

    I do remember there are some important description of handling and note in the product spec that it's important you follow. I copy it here so you may check if you indeed follow them:

    The RX_DR IRQ is asserted by a new packet arrival event. The procedure for handling this interrupt should be:
    1) read payload through SPI,
    2) clear RX_DR IRQ,
    3) read FIFO_STATUS to check if there are more payloads available in RX FIFO,
    4) if there are more data in RX FIFO, repeat from step 1).

    Note: Always check if the packet width reported is 32 bytes or shorter when using the R_RX_PL_WID command. If its width is longer than 32 bytes then the packet contains errors and must be discarded. Discard the packet by using the Flush_RX command.

    The above apply to packets both ways, including ACK packets. I wrote the above before I saw you comment on TX FULL bit is set on the PRX (), but here are my comment to your observation about TX FULL bit:

    If you have TX FULL occur on the PRX, then it should be possible to call FLUSH_TX command on the PRX to clear the TX fifo. 

    Kenneth

Reply
  • 0

    Hello,

    I do remember there are some important description of handling and note in the product spec that it's important you follow. I copy it here so you may check if you indeed follow them:

    The RX_DR IRQ is asserted by a new packet arrival event. The procedure for handling this interrupt should be:
    1) read payload through SPI,
    2) clear RX_DR IRQ,
    3) read FIFO_STATUS to check if there are more payloads available in RX FIFO,
    4) if there are more data in RX FIFO, repeat from step 1).

    Note: Always check if the packet width reported is 32 bytes or shorter when using the R_RX_PL_WID command. If its width is longer than 32 bytes then the packet contains errors and must be discarded. Discard the packet by using the Flush_RX command.

    The above apply to packets both ways, including ACK packets. I wrote the above before I saw you comment on TX FULL bit is set on the PRX (), but here are my comment to your observation about TX FULL bit:

    If you have TX FULL occur on the PRX, then it should be possible to call FLUSH_TX command on the PRX to clear the TX fifo. 

    Kenneth

Children
Related