0
\$\begingroup\$

I have 10 nrf24l01 modules, 5 from the german web shop, 5 from the local finnish offline store. I'm using them in pair, one module sends exactly one byte to another one module with period of ~100ms. I have ack enabled on both sides, CRC enabled on both sides and tried to enable/disable dynamic payload. I also did tried changing channels.

So, on the sender side everything works perfect - TX_DS is set on successful transmission and MAX_RT is set, when receiver is off or not listening.

On the receiver side everything also looks perfect - IRQ line goes low on receive event, RX_DR is set on receive, status register contains correct number of a pipeline with data (pipe 1), RX_EMPTY in fifo_status is (0). With dynamic payload size R_RX_PL_WID returns correct size of payload (1 byte). When i issue R_RX_PAYLOAD command, RX_EMPTY in fifo_status goes to one and status register goes to 0b0xxx111x, thus i'm quite sure, that i'm sending proper read command.

The problem is that R_RX_PAYLOAD always returns same value 0x46, which is not the value i send, obviously. Even more, if i will try to read without actually receiving the data, it still will be 0x46. If i try to read more data, then in buffer - still 0x46. I did checks with logic analyzer - on wire payload is correct on the transmitter side and on wire payload is incorrect on the receiver side, so it is not an issue with firmware writing/reading to a wrong location.

I would suspect broken chip, but it tried 6 chips out of 10, 3 by one supplier and another 3 came from another supplier. I doubt that i can have 6 chips from different batches with exactly same problem. What i can be missing and why it returns same weird value as payload?

PS STM32F1, libopencm3, homebrew nrf code

\$\endgroup\$
2
  • 1
    \$\begingroup\$ You should probably try running (or at least reading through) someone else's example code for the radio. It is extraordinarily unlikely that the chips you have are broken in this way - varied RF performance would be unsurprising, but not the kind of thing you are describing. Note that debugging questions on SE sites are required to include key code to reproduce the problem. \$\endgroup\$
    – Chris Stratton
    Commented Sep 10, 2019 at 13:25
  • 1
    \$\begingroup\$ Seconded, it is almost certainly a mistake in your code (which you should post). This chipset is incredibly popular and has good support for STM32 microcontrollers, so the most efficient way to trace this back is to get it working with existing code first. I personally have used this codebase: github.com/LonelyWolf/stm32/tree/master/nrf24l01 \$\endgroup\$
    – Ocanath
    Commented Sep 10, 2019 at 14:59

1 Answer 1

Reset to default
1
\$\begingroup\$

It was a timing issue. CSN high time wasn't long enough, due to my mistake, and nrf reacted incorrectly because of that.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.