Potential Addressing Bug for RPI4

[dylviz]

From my understanding, this library doesn't yet officially support RPI4, but I've heard of a few people being able to make it work so I'm currently going down that path. It's hard to say whether this is bug or not, but I've been digging through the code for past several evenings and can't seem to find why this would be happening.

I'm trying to communicate from Arduino to RPi4, but it's unsuccessful. Arduino->Arduino communication is working, but the problems comes in when one of the Arduinos is replaced with the RPI4.

The RPi is running Ubuntu 20.04.2 LTS.
Both use the "gettingStarted" example code and default addresses of "1Node" and "2Node":

uint8_t addresses[2][6] = {"1Node", "2Node"};

Using printPrettyDetails, I can see the following behavior.
On the Arduino, the pipes open at the expected addresses:

SPI Frequency		= 10 Mhz
Channel			= 76 (~ 2476 MHz)
RF Data Rate		= 1 MBPS
RF Power Amplifier	= PA_MIN
RF Low Noise Amplifier	= Enabled
CRC Length		= 16 bits
Address Length		= 5 bytes
Static Payload Length	= 32 bytes
Auto Retry Delay	= 1500 microseconds
Auto Retry Attempts	= 15 maximum
Packets lost on
    current channel	= 0
Retry attempts made for
    last transmission	= 0
Multicast		= Disabled
Custom ACK Payload	= Disabled
Dynamic Payloads	= Disabled
Auto Acknowledgment	= Enabled
Primary Mode		= TX
TX address		= 0x65646f4e31
pipe 0 ( open ) bound	= 0x65646f4e31
pipe 1 ( open ) bound	= 0x65646f4e32
pipe 2 (closed) bound	= 0xc3
pipe 3 (closed) bound	= 0xc4
pipe 4 (closed) bound	= 0xc5
pipe 5 (closed) bound	= 0xc6

However, on the RPI4 it looks like something went wrong in the memory management:

================ SPI Configuration ================
CSN Pin                 = /dev/spidev0.0
CE Pin                  = Custom GPIO22
SPI Frequency           = 10 Mhz
================ NRF Configuration ================
Channel                 = 76 (~ 2476 MHz)
RF Data Rate            = 1 MBPS
RF Power Amplifier      = PA_MAX
RF Low Noise Amplifier  = Enabled
CRC Length              = 16 bits
Address Length          = 5 bytes
Static Payload Length   = 32 bytes
Auto Retry Delay        = 1500 microseconds
Auto Retry Attempts     = 15 maximum
Packets lost on
    current channel     = 0
Retry attempts made for
    last transmission   = 0
Multicast               = Disabled
Custom ACK Payload      = Disabled
Dynamic Payloads        = Disabled
Auto Acknowledgment     = Enabled
Primary Mode            = TX
TX address              = 0x65646f4e32
pipe 0 ( open ) bound   = 0x75746f4e32
pipe 1 ( open ) bound   = 0x75747f4f39
pipe 2 (closed) bound   = 0xc3
pipe 3 (closed) bound   = 0xc4
pipe 4 (closed) bound   = 0xc5
pipe 5 (closed) bound   = 0xc6

Obviously, the pipe 0 and pipe 1 address aren't what was specified (though TX address is correct). I expect pipe 0 to have the value of "0x65646f4e32" and pipe 1 to have the value of "0x65646f4e31".

My first thought was dangling pointer or perhaps some unexpected register/buff size but nothing stands out to me in the code.

On the RPI, the RF24 install was configured as follows:

./configure --driver=RPi --cxx_compiler=g++ --c_compiler=gcc --cpu-flags=-pthread

I've mostly been searching in and around the read and write register functions:

void RF24::write_register(...)
void RF24::read_register(...)

I'm hoping someone may have some insight as to where this issue may stem from that I can dig into or perhaps even an idea of how to fix.

Thanks

[2bndy5]

The lib works fine on the RPi4 if using Raspberry Pi OS (aka Raspbian)

The RPi is running Ubuntu 20.04.2 LTS.
...
On the RPI, the RF24 install was configured as follows:

./configure --driver=RPi --cxx_compiler=g++ --c_compiler=gcc --cpu-flags=-pthread

We are aware of the compiler issue on the RPi4 under Ubuntu using the handcrafted configure script (that was originally only intended for armhf toolchain). #772 has an alternative fix for that using CMake. This was brought to our attention in #642 @dylviz Are you running this lib under Ubuntu 64bit or 32bit?

However, I have also experienced some weird issues running RF24 lib when compiled with 64bit compiler; see #642 (comment) as an example of my problematic output.

the pipe 0 and pipe 1 address aren't what was specified (though TX address is correct)

this is news to me. I've been able to run several examples without having problems with the addresses being incorrectly set. Or maybe I wasn't paying attention enough to that since all my payloads were exchanged (albeit somehow corrupted).

[2bndy5]

@dylviz I'm curious. Have you tried building the library with the SPIDEV driver option

./configure --driver=SPIDEV --cxx_compiler=g++ --c_compiler=gcc --cpu-flags=-pthread

When I last tried the RPi driver (which uses the BCM2835 library) on my RPi4 under Ubuntu 64bit, the examples didn't get past the radio.begin() call.

[2bndy5]

switched to using the python wrapper on RPi4 in ubuntu 64bit (built with RPi driver), and I get the same problem I observed when building with the SPIDEV driver. But now I'm able to inspect the payload before it is "unpacked" from a byterray form:

brendan@rpi4-ubuntu64:~/RF24/examples_linux$ sudo python3 acknowledgement_payloads.py
[sudo] password for brendan:
acknowledgement_payloads.py
Which radio is this? Enter '0' or '1'. Defaults to '0'
*** Enter 'R' for receiver role.
*** Enter 'T' for transmitter role.
*** Enter 'Q' to quit example.
r
received: bytearray(b'lw~~\x7f0\x00\x00\x00\x00\x00\x00')
Received 12 bytes on pipe 1: lw~~00 Sent: World 0
received: bytearray(b'lv~~\x7f0\x00\x00\x00\x00\x00\x00')
Received 12 bytes on pipe 1: lv~~00 Sent: World 1
received: bytearray(b'lv~~\x7f0\x00\x00\x00\x00\x00\x00')
Received 12 bytes on pipe 1: lv~~00 Sent: World 1
received: bytearray(b'lw~~\x7f0\x00\x00\x00\x00\x00\x00')
Received 12 bytes on pipe 1: lw~~00 Sent: World 1
received: bytearray(b'lw~~\x7f0\x00\x00\x00\x00\x00\x00')
Received 12 bytes on pipe 1: lw~~00 Sent: World 1
Nothing received in 6 seconds. Leaving RX role

Still I can't reproduce the address problem.

Success!

I lowered the SPI speed in the example I was running

radio = RF24(22, 0, 4000000)

and I got the correct payloads transmitted

acknowledgement_payloads.py
Which radio is this? Enter '0' or '1'. Defaults to '0'
*** Enter 'R' for receiver role.
*** Enter 'T' for transmitter role.
*** Enter 'Q' to quit example.
r
received: bytearray(b'Hello \x00\n')
Received 8 bytes on pipe 1: Hello 10 Sent: World 0
received: bytearray(b'Hello \x00\x0b')
Received 8 bytes on pipe 1: Hello 11 Sent: World 11
received: bytearray(b'Hello \x00\x0c')
Received 8 bytes on pipe 1: Hello 12 Sent: World 12
received: bytearray(b'Hello \x00\r')
Received 8 bytes on pipe 1: Hello 13 Sent: World 13
received: bytearray(b'Hello \x00\x0e')
Received 8 bytes on pipe 5: Hello 14 Sent: World 14
Nothing received in 6 seconds. Leaving RX role
*** Enter 'R' for receiver role.
*** Enter 'T' for transmitter role.
*** Enter 'Q' to quit example.
t
Transmission successful! Time to transmit: 88 us. Sent: Hello 15 Received an empty ACK packet
Transmission successful! Time to transmit: 95 us. Sent: Hello 15 response: bytearray(b'World \x00\x0f')
Received 8 on pipe 0: World 15
Transmission successful! Time to transmit: 88 us. Sent: Hello 16 response: bytearray(b'World \x00\x10')
Received 8 on pipe 0: World 16
Transmission successful! Time to transmit: 85 us. Sent: Hello 17 response: bytearray(b'World \x00\x10')
Received 8 on pipe 0: World 16
Transmission successful! Time to transmit: 102 us. Sent: Hello 17 response: bytearray(b'World \x00\x11')
Received 8 on pipe 0: World 17
Transmission successful! Time to transmit: 103 us. Sent: Hello 18 response: bytearray(b'World \x00\x12')
Received 8 on pipe 0: World 18

NOTICE: the transmission time is still faster than my trials on the RPi2 (with default SPI speed 10MHz)

[dylviz]

@dylviz I'm curious. Have you tried building the library with the SPIDEV driver option

./configure --driver=SPIDEV --cxx_compiler=g++ --c_compiler=gcc --cpu-flags=-pthread

When I last tried the RPi driver (which uses the BCM2835 library) on my RPi4 under Ubuntu 64bit, the examples didn't get past the radio.begin() call.

Hi @2bndy5, Sorry for slow reply, just got off work. I'm running 64-bit Ubuntu and just used the default 64 bit compiler. If I configure for SPIDEV, I get the following output:

sudo ./gettingstarted
./gettingstarted: symbol lookup error: ./gettingstarted: undefined symbol: bcm2835_delay

This made me question whether the broadcom chip is being configured properly. I just noticed in ./configure, the following chips seems to be supported:

--soc=[BCM2835|BCM2836|AM33XX|A10|A13|A20|H3]

However, from the Rpi4 datasheet, here
it uses the the BCM2711

I don't want to go down a rabbit hole with the BCM2711 thing, but perhaps with your insight, you can tell me if this could be a plausible location for the error before I start digging.
I'll also look into your comment about using CMAKE

[2bndy5]

the handcrafted configure script (that was originally only intended for armhf toolchain).

yeah the current build system generates a deprecated (via variable name) symlink called librf24-bcm.so (should be located in /usr/local/lib)... maybe its looking for that; IDK. The BCM2835 lib is compatible with the chips used on the RPi4, but the RF24 lib's traditional Makefile & configure solutions haven't been properly updated in a long time...

I'll also look into your comment about using CMAKE

YES! the CMake implementation was especially written for your situation. I recommend you checkout the rp2xxx branch and follow the doc'd instructions. I don't have a problem using CMake with the SPIDEV driver. And you don't have to worry about the "unrecognized" compiler options problem with CMake.

perhaps with your insight, you can tell me if this could be a plausible location for the error before I start digging.

I'm more inclined to think the SPI speed is too high by default for a 64 bit OS.

[dylviz]

@2bndy5 The CMake install on the rp2xxx branch works beautifully! Thank you for pointed that out. This would've driven me crazy haha. I used SPIDEV and I don't notice any corruption at the default 10MHz (for 4 byte payload) that you pointed out. I'll keep my eye on that though as I move to a more complex test setup.