Note: I have not yet tested the change, so please wait for hitting the green button

Murdock results

✔️ PASSED

f16ceb3 drivers/sx126x: always report back that netdev is LoRa

Artifacts

• Documentation preview

The driver should still work when the hardware is present

USEMODULE+="shield_sx1262" BOARD=adafruit-metro-m4-express DEVELHELP=1 make flash term PORT=/dev/ttyACM1

2025-11-06 12:59:31,521 # ifconfig
2025-11-06 12:59:31,523 # Iface  4  HWaddr: AA:AA:AA:AA  Frequency: 868300000Hz  RSSI: -128  BW: 125kHz  SF: 7  CR: 4/5  Link: down 
2025-11-06 12:59:31,524 #            State: STANDBY  Demod margin.: 0  Num gateways.: 0 
2025-11-06 12:59:31,524 #           OTAA  
2025-11-06 12:59:31,524 #           Link type: wireless

Yes.

The driver should fail gracefully when the radio is not connected, instead of running into a blown assertion

Also yes, when I dont have the shield connected.

But also that is the bahavior for me on master. Did you get the assert trigger?
Or is the change required in case another SPI device was connected?

But also that is the bahavior for me on master. Did you get the assert trigger?

Yes, in the DFT Communication board when no Antenna Board is connected. There seems to be something slightly pulling up the CIPO (aka MISO) line. You should be able to reproduce by adding 100 K resistor between VCC and CIPO.

The assert is quite late in the boot: The init worked just fine without the LoRa chip connected, but GNRC than triggered an assertion because the netdev type was reported as unknown, which was not explicitly handled in a switch () over the device type and the default: just had an assert(0);.

Ok, when it fixes it in the com board. CI no longer accepts the commits from the "Commit suggestion" button.

Let's not hit merge just yet. I was too busy with the other project to confirm it does fix the issue just yet.

I can confirm that the device presence test now works. The issue is also not specific to one instance of the DFT communication board, but happens reliable on two instances. So I'd say it is an issue we might see on other hardware as well.

Oh, shit. It appears that the LoRa chips on the antenna boards default to GFSK and not to LoRa after reset :/

With this test it now works reliably for me. Better would be if there would be some vendor ID or device ID in the register map that we could read out and check. But I couldn't find something like that in the data sheet.

Better would be if there would be some vendor ID or device ID

I have been looking for this before. Because I could not find it, the current state was good enough for me since it worked on the board I tested.

If the default was GFSK, why did it show up for me on the adafruit board which has the same LoRa chip?

typedef enum sx126x_pkt_types_e
{
    SX126X_PKT_TYPE_GFSK    = 0x00,
    SX126X_PKT_TYPE_LORA    = 0x01,
    SX126X_PKT_TYPE_BPSK    = 0x02,
    SX126X_PKT_TYPE_LR_FHSS = 0x03,
} sx126x_pkt_type_t;

Anyway ... anything > SX126X_PKT_TYPE_LR_FHSS is invalid so it is fine.

Anyway ... anything > SX126X_PKT_TYPE_LR_FHSS is invalid so it is fine.

OK, then let's go with that. It did work reliably for me on two different systems.