zhgzhg / LoRaPacketForwarder

LoRa single channel packet forwarder based on the Semtech UDP protocol v2

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

SPI Fail on OrangePi Zero 2

loratrak opened this issue · comments

Hi,

I'm using a OrangePi Zero2 board and wiringPi already installed, with gpio readall command working. See bellow

image

But when I tried to start, you can see this error bellow:

image

In config.json I tried to set SPI channel to 1 but SPI don't open.

image

I think is everything is ok with my SPI, I tested with gpio write

image

image

Thanks in advance with you have any idea of the issue.

Hi @loratrak , error 65534 indicates the SPI communication is not happening. Can you double check your hardware setup, especially the MISO, MOSI, and CS pins. If you have them wrongly connected to the OrangePi Zero 2 pins this error usually arises.

Edit: Btw spidev1.1 looks the correct choice. You can also check for connected in reverse MISO and MOSI pins.

Hi @zhgzhg,
I doubled checked hw pins, and are correct. I tried reversed MISO & MOSI pins and didn't work. I'm using these pins to MISO, MOSI and CS.

image

I have a RPB1 with the same lora hat, and I have to change the channel to 1 and it worked. But in OrangePi the channel 1 didn't work and I don't know why.

Thanks

Can you try https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#loopback-test just to see if your SPI channels work. If they do perhaps there could be some issue with the wiringPi library not properly supporting the Zero 2 board.

It's working with loopback tests, on /dev/spidev1.1

image

Thanks, I think I understand what's happening - the packet forwarder is attempting to open the incorrect SPI device, because of spidev*.* naming differences for OrangePi Zero 2. This is because it's relying on wiringPi's default naming convention for SPI devices.

I'll make the config.json file to support specifying both channel and port i.e. "spidev<channelNumber>.<portNumer>" which if I am right should resolve the issue.

Until then as a temporary workaround can you please try creating symlinks to your existing devices:

ln -s /dev/spidev1.0 /dev/spidev1.1

the above will create a "virtual" spi port "0" redirecting to the real port "1".

I ran this "ln -s /dev/spidev1.1 /dev/spidev1.0" and it's working right now

image

image

Thanks a lot!!!