DIO5_0=-1 with XL1278-SMT causes 100% CPU usage

[matburnham]

I ended up with a batch of XL1278-SMT modules so figured I'd try and protoboard a LoRa gateway.

After a bit of faffing with pin numbers, it all seems to work initially, but then it seems to hang (no interactive keystrokes work except Ctrl-C; 100% CPU usage). My additional debug info shows it's correctly reading the SX1278 module version, etc. It seems to go wrong when it starts trying to receive.

 $ sudo gdb
GNU gdb (Raspbian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) attach 680
Attaching to process 680
[New LWP 685]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
0x0002530c in startReceiving ()
(gdb) info threads
  Id   Target Id                             Frame
* 1    Thread 0x75f15520 (LWP 680) "gateway" 0x0002530c in startReceiving ()
  2    Thread 0x75f14230 (LWP 685) "gateway" __GI___poll (timeout=-1, nfds=1,
    fds=0x75f13c10) at ../sysdeps/unix/sysv/linux/poll.c:29
(gdb) bt
#0  0x0002530c in startReceiving ()
#1  0x0002780c in setupRFM98 ()
#2  0x00012320 in main ()
(gdb) thread 2
[Switching to thread 2 (Thread 0x75f14230 (LWP 685))]
#0  __GI___poll (timeout=-1, nfds=1, fds=0x75f13c10)
    at ../sysdeps/unix/sysv/linux/poll.c:29
29      ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
(gdb) bt
#0  __GI___poll (timeout=-1, nfds=1, fds=0x75f13c10)
    at ../sysdeps/unix/sysv/linux/poll.c:29
#1  __GI___poll (fds=0x75f13c10, nfds=1, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:26
#2  0x76e62690 in waitForInterrupt () from /lib/libwiringPi.so
#3  0x76e62730 in interruptHandler () from /lib/libwiringPi.so
#4  0x76d40494 in start_thread (arg=0x75f14230) at pthread_create.c:486
#5  0x76cc3578 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

I'm not great gdb user, but I think it's stuck waiting for an interrupt. I can manually short DIO0 to ground to get it out of this state, but that doesn't really fix the problem.

Has anyone else tried to use a XL1278-SMT module rather than the RFM98 or DRF1278F, etc.? It's got an XS1278 on board, so it should 'just work'. DIO5 is an edge connector rather than through-hole so there's no chance of using that without a breakout.

It's quite possibly my wiring given I'm dead-bugging 0.05" pitch, but the fact I'm able to read at least the version register gives me hope.

gateway.txt:

tracker=[removed]
Latitude=[removed]
Longitude=[removed]
Antenna=A tiny bit of wire

##### Config Options #####
EnableHabitat=Y
EnableSSDV=Y
JPGFolder=ssdv
LogTelemetry=Y
LogPackets=Y
CallingTimeout=60
ServerPort=6004
#SMSFolder=./
EnableDev=N

#NetworkLED=22
#InternetLED=23
#ActivityLED_0=21
#ActivityLED_1=29

##### Config CE0 #####
frequency_0=433.650
mode_0=5
AFC_0=Y
#bandwidth_0=125K
#implicit_0=0
#coding_0=5
#sf_0=8
#lowopt_0=0
#power_0=255
DIO0_0=3
DIO5_0=-1

[matburnham]

Tonight I lashed up the only DRF1278F I've got on a breadboard, and was finding the same issues initially, but once I lashed up DIO5 and added it to the config it sprang into life:

Remove the DIO5 connection and set DIO5_0=-1 and it all hangs up again.

Digging about, I note 7d50159 removed the check some while ago. Hmmm. Does that also mean DIO5_0=-1 it not supported any more? If so, it could do with the README.md reflecting that; and possibly a warning in the code if it's set to that! If not, where do I look next? What exactly do DIO0 and DIO5 do and what are they used for?

I guess my best bet is to get DIO5 wired up, but that's not very viable dead-bug style with the odd edge-connection on the DRF1278F.

[daveake]

I did mention this before: DIO0 is "packet received" DIO5 is "mode changed" There is currently no provision in the gateway to ignore DIO5 (I was thinking of PITS which does). If you don't have DIO5 then you need to comment out the code that uses it, and uncomment the following delay line, all in gateway.c: while ( digitalRead( Config.LoRaDevices[Channel].DIO5 ) == 0 ) { } // delay(1); Then recompile/link with make Dave

…

On Mon, 22 Feb 2021 at 21:42, Mat Burnham ***@***.***> wrote: [image: image] <https://user-images.githubusercontent.com/1058493/108773715-ad4bdf00-7556-11eb-88a7-87f3a5f6aa4f.png> Tonight I lashed up the only DRF1278F I've got on a breadboard, and was finding the same issues initially, but once I lashed up DIO5 and added it to the config it sprang into life: [image: image] <https://user-images.githubusercontent.com/1058493/108772501-fa2eb600-7554-11eb-9b68-a4f0928ef01a.png> Remove the DIO5 connection and set DIO5_0=-1 and it all hangs up again. Digging about, I note 7d50159 <7d50159> removed the check some while ago. Hmmm. Does that also mean DIO5_0=-1 it not supported any more? If so, it could do with the README.md reflecting that; and possibly a warning in the code if it's set to that! If not, where do I look next? What exactly do DIO0 and DIO5 do and what are they used for? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIGQ5ABNYLD2L6YOXBXPLDTALFV3ANCNFSM4X7JEODA> .

[PiInTheSky]

Please update to V1.8.42 which disables use of DIO5 if set to -1 Dave On Mon, 22 Feb 2021 at 21:56, David Akerman <[email protected]> wrote:

…

I did mention this before: DIO0 is "packet received" DIO5 is "mode changed" There is currently no provision in the gateway to ignore DIO5 (I was thinking of PITS which does). If you don't have DIO5 then you need to comment out the code that uses it, and uncomment the following delay line, all in gateway.c: while ( digitalRead( Config.LoRaDevices[Channel].DIO5 ) == 0 ) { } // delay(1); Then recompile/link with make Dave On Mon, 22 Feb 2021 at 21:42, Mat Burnham ***@***.***> wrote: > [image: image] > < https://user-images.githubusercontent.com/1058493/108773715-ad4bdf00-7556-11eb-88a7-87f3a5f6aa4f.png > > > Tonight I lashed up the only DRF1278F I've got on a breadboard, and was > finding the same issues initially, but once I lashed up DIO5 and added it > to the config it sprang into life: > > [image: image] > < https://user-images.githubusercontent.com/1058493/108772501-fa2eb600-7554-11eb-9b68-a4f0928ef01a.png > > > Remove the DIO5 connection and set DIO5_0=-1 and it all hangs up again. > > Digging about, I note 7d50159 > < 7d50159 > > removed the check some while ago. Hmmm. Does that also mean DIO5_0=-1 it > not supported any more? If so, it could do with the README.md reflecting > that; and possibly a warning in the code if it's set to that! If not, where > do I look next? What exactly do DIO0 and DIO5 do and what are they used for? > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > < #65 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AAIGQ5ABNYLD2L6YOXBXPLDTALFV3ANCNFSM4X7JEODA > > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4ERK44FHWZEZ6MQWJHV23TALHI3ANCNFSM4X7JEODA> .

[matburnham]

Excellent. Thanks @daveake. That threw me off a little. Once I've got a breakout able to get DIO5 from the XL1278-SMT I'll add DIO5 back in, but in the meantime that'll enable me to have something to receive my tracker on.

[daveake]

I wouldn't bother; a 1ms delay is irrelevant.

…

On Tue, 23 Feb 2021 at 22:42, Mat Burnham ***@***.***> wrote: Excellent. Thanks @daveake <https://github.com/daveake>. That threw me off a little. Once I've got a breakout able to get DIO5 from the XL1278-SMT I'll add DIO5 back in, but in the meantime that'll enable me to have something to receive my tracker on. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIGQ5DZVID2KEXVDOTBR5LTAQVPDANCNFSM4X7JEODA> .