kicking up a bug on an older nrf24 board.

RE: kicking up a bug on an older nrf24 board.

ulao — Thu, 08 Aug 2024 21:21:49 GMT

alright I think I got it sorted out, thx for the help.

RE: kicking up a bug on an older nrf24 board.

Kenneth — Thu, 08 Aug 2024 08:45:21 GMT

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

RE: kicking up a bug on an older nrf24 board.

ulao — Thu, 08 Aug 2024 02:30:54 GMT

just noticed something strange . On my receiver I see a TX_FULL flag.

the way it works

sender sends a command (i.e 1) then a 0xFF to pick up the burst

receiver is always watching for command and sets the ACK data when it gets a command.

so I noticed on my receiver there is a TX_FULL bit on. Every time I read the command that comes in, I always do a write to 0x20 and a flash. So I'm not sure how it could be full?