RAK2245 on RPi 4 with arm64 Buildroot

[ksadowski (Kevin Sadowski)]

Issue:
I’m unable to initialize the lora packet forwarder due to issues with the calibration firmware. I receive the following error:

ERROR: Version of calibration firmware not expected, actual:198 expected:2
ERROR: [main] failed to start the concentrator

Setup:
I’m using a Raspberry Pi 4 with a 64 bit Buildroot installation.

Details:
Using the scripts as a guide in packet_forwarder and lora_gateway within the RAK Repo, I’m able to compile for Arm64 without errors, but I run into issues when trying to run. Full log output is available in pastebin just in case there is a small nugget of information there.

In order to compile I added the compiler to the path and added the following to the environment:

export CROSS_COMPILE=aarch64-linux-gnu-
export ARCH=arm64

The config.txt has the following overlays configured, similar to what is added by the scripts:

dtparam=spi=on
dtparam=i2c_arm=on
dtparam=i2c1=on, dtparam=i2c_arm_baudrate=100000
dtoverlay=disable-bt
dtoverlay=spi0-hw-cs
dtoverlay=uart3

Am I missing anything in my configuration that is needed? I verified GPIO 17 is resetting the SX1301 correctly prior to starting the packet forwarder. The SPI port appears to be working correctly. It always receives 198 for the firmware calibration so I don’t think it’s an issue with too fast of a SPI clock. The SPI clock has the same timing, according to my scope, in both buildroot (64bit) mode and in Raspian (32bit) mode.

Thanks for your help!

[nmcc (Nick McCloud)]

I’d suggest a quick hardware functionality test by using the RAK firmware:

https://downloads.rakwireless.com/LoRa/RAK2245-Pi-HAT/Firmware/

Just to make sure that your hardware is 100%. No point debugging custom builds if there’s something else afoot.

[cstratton (Chris)]

Make sure you are driving the reset with the correct polarity, on the RAK systems I believe it is high to reset and low to run, which is the less common choice, more ICs in general being made with active low resets.

Note that on some Linux systems if you try to export a gpio which is already exported, you end up un-exporting it, I make my packet forwarder start scripts do a file-exist tests on the gpio pin directory before they try to export it.

Try running the spi stress and similar tests in the lora hal rather than the packet forwarder.

If nothing else get a cheap USB logic analyzer and see what is actually happening on the bus, make sure to check the reset, too.

[Tony_Smith]

@ksadowski

so I don’t think it’s an issue with too fast of a SPI clock

Check with your scope that the SPI speed is 2MHz or less, the RAK2245 will not work on the standard 8MHz SPI bus. This can’t be controlled by the config.txt file but in a file before the code is compiled.

[Tony_Smith]

This post may provide some detail about connections, reset pins and SPI speed.

RAK2245 96 Board with pi zero

Here are the connections you need between a RAK2245 Stamp Version (use the Edge Connections) or the RAK2245 96 Boards (use the 40 pin socket). You can use the edge connection on the 96 Board version if you like. You can find the layout on the RAK web site - 96 Board Stamp Version https://doc.rakwireless.com/datasheet/rakproducts/pin-definition---rak2245-stamp-edition Raspi RasPi Name RAK2245 RAK2245 RAK Description Physical Edge 9…

[ksadowski (Kevin Sadowski)]

Thanks for the replies. I do appreciate it.

@nmcc - I plugged in my SD card which uses Chirpstack to report to a local server and that worked just fine. It was reporting data from the two sensors I’ve got here. So the hardware appears to be working correctly.

@cstratton

Make sure you are driving the reset with the correct polarity, on the RAK systems I believe it is high to reset and low to run, which is the less common choice, more ICs in general being made with active low resets.

At first I was not using the start.sh script which is included and it wasn’t getting past the version check in loragw_reg.c:lgw_connect. Once I started running the script which toggles the reset pin, I was able to get further. I just hooked it up to the scope and the reset pin (GPIO17) is normally low, then toggles high for ~100ms. This is the only time I see it change state.

@cstratton

Try running the spi stress and similar tests in the lora hal rather than the packet forwarder.

I’ll give these a shot next.

@Tony_Smith

Check with your scope that the SPI speed is 2MHz or less, the RAK2245 will not work on the standard 8MHz SPI bus. This can’t be controlled by the config.txt file but in a file before the code is compiled.

I just checked with the scope. It appears to be running at 800KHz - so much less than the 2MHz maximum. I was kind of surprised it was running that slow myself. Especially since the code is trying to set it for 2MHz.

loragw_spi.native.c:56 - #define SPI_SPEED 2000000

Thanks again for your help. I’ll try some of the other utilities (spi stress, etc) and report back.

[ksadowski (Kevin Sadowski)]

I fired up util_spi_stress and let that run for about 10 minutes without an error. The SPI clock was right at 800 KHz.

For the rest of the utilities, I couldn’t get them to run. Most of them indicated the version of the calibration firmware was not expected. Similar to the error I’m getting with the packet forwarder.

[cstratton (Chris)]

@ksadowski

For the rest of the utilities, I couldn’t get them to run. Most of them indicated the version of the calibration firmware was not expected. Similar to the error I’m getting with the packet forwarder.

Did you reset before running those, too?

Consider building a version with spi operation logging, both on the stock Linux and yours.

Also try to figure out why the SPI clock speed is not being honored. I’d suggest picking 1 MHz but am concerned with the simple fact that you are getting something different from what you ask for.

[ksadowski (Kevin Sadowski)]

@cstratton

Did you reset before running those, too?

Yes, I did reset module before running the utilities. Since most of the utilities utilize the same startup sequence, they all fail at the same point.

Here are two logs for the different configurations. I used the same source code to build lora_pkt_fwd.

Log from 64 bit buildroot: Arm 64 Packet Forwarder - Pastebin.com

Log from Raspian: Raspian Packet Forwarder - Pastebin.com
I stopped it after a bit once it was up and running.

Interesting, even with the software running on Raspian, the SPI clock was at 800 KHz.

I just tried the packet forwarder that was built as part of the installation back in November, and that one is running at 1Mhz. I’m going to diff the source to see what changed. I know the RAK repo has changed since then.

[cstratton (Chris)]

@ksadowski

I know the RAK repo has changed since then.

Oh, I assumed you were using the code direct from Semtech.

Try that, unlike say the mt7628 platforms it doesn’t need any modification for a pi, other than to change the clock speed.

[ksadowski (Kevin Sadowski)]

I just checked the diff, there isn’t anything different except for the change in SPI frequency. I was just trying to keep everything the same.

[ksadowski (Kevin Sadowski)]

Looks like the SPI frequency is based upon the core CPU clock: https://github.com/raspberrypi/linux/issues/3381

If I read this correctly, it is divided down based on the maximum frequency to not exceed the SPI_IOC_WR_MAX_SPEED_HZ and SPI_IOC_RD_MAX_SPEED_HZ settings. Then when the CPU speed adjusts slower due to the selected governor, the SPI clock also adjusts.

I confirmed setting the CPU governor to performance corrects the SPI clock to 2MHz. Setting the governor back to ondemand the SPI clock goes to 800KHz.

[ksadowski (Kevin Sadowski)]

I hooked up a logic analyzer to the SPI bus, and compared the transactions. The issue occurs when the application attempts to download the calibration firmware to the radios. It does a write burst over the SPI bus, then reads it back doing a burst read. The comparison fails, and the application exits with error.

The difference I see on the logic analyzer has to do with the chip select line. I see it setup for the write burst, but then it toggles the chip select line between the setup and when it starts writing the data. I haven’t looked at the SPI protocol for the radio, but I’m assuming when the chip select get de-asserted, it signals the end of the burst write. See the two images below.

I’m currently tracing through the linux driver to see why it toggles the chip select in the middle of the transaction in one version, and not the other.

Raspian Image:

Buildroot 64 bit Image: