Hi, New to RIOT…
I’m trying to get a Seeed Studio E5 module with the integrated SX126x transceiver to work as a starter project. I’ve used an sx127x example from the web from Eugene P and it runs fine on a Feather-M0-Lora board. I’ve replaced the various sx127x with sx126x function equivalents. The code fails every time it reaches the spi_init() with a spi bus error.
Does anyone have any WORKING examples of Lora (not LoraWAN) code for the Lora_E5_Dev board (sx126x) or was it a case of yeah the board is supported but only to blink an LED and Lora was never actually tested?
I should add I have been using these E5 modules with STM32mx and I do have running code, I’m also familiar with the SX127x generally. I think it is the whole “new to Riot” that is getting me 
Cheers,
Ingmar
Hello Ingmar,
to be sure everything work with your setup, could you please try to
flash tests/driver_sx126x? This example test implements a basic app
for sending/receiving LoRa frames with the transceiver. Check
tests/driver_sx126x/README.md for more details.
Cheers, José
On 22/09/23 06:25AM, Ingmar M via RIOT wrote:
Hi, New to RIOT… I’m trying to get a Seeed Studio E5 module with the integrated SX126x transceiver to work as a starter project. I’ve used an sx127x example from the web from Eugene P and it runs fine on a Feather-M0-Lora board. I’ve replaced the various sx127x with sx126x function equivalents. The code fails every time it reaches the spi_init() with a spi bus error. Does anyone have any WORKING examples of Lora (not LoraWAN) code for the Lora_E5_Dev board (sx126x) or was it a case of yeah the board is supported but only to blink an LED and Lora was never actually tested? I should add I have been using these E5 modules with STM32mx and I do have running code, I’m also familiar with the SX127x generally. I think it is the whole “new to Riot” that is getting me
Visit Topic or reply to this email to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, click here.
Hi Jose,
Ahh I knew I should have dug deeper into all the directories!
Thanks, I will give it a try. Thanks for pointing me in the right direction.
Cheers, Ingmar
Hi,
I have compiled and installed the tests/driver_sx126x application with the board set to the lora_e5 device and it runs until it tries to initialise the sx1262. I placed additional puts statements in to allow me to trace the code.
if (netdev->driver->init(netdev) < 0) { puts(“Failed to initialize SX126X device, exiting”); return 1; }
It locks up during the init phase and never gets to the “Failed” message. Given I know my hardware works with my STM32mx app I assume it is still an issue in the sx126x driver.
Hi Ingmar,
could you please enable debug on drivers/sx126x/sx126x.c, compile,
flash and post the output back?:
diff --git a/drivers/sx126x/sx126x.c b/drivers/sx126x/sx126x.c
index 0898708862..d4773471f2 100644
--- a/drivers/sx126x/sx126x.c
+++ b/drivers/sx126x/sx126x.c
@@ -30,7 +30,7 @@
#include "sx126x_params.h"
#include "sx126x_internal.h"
-#define ENABLE_DEBUG 0
+#define ENABLE_DEBUG 1
#include "debug.h"
#ifndef CONFIG_SX126X_PKT_TYPE_DEFAULT
That should indicate immediately what’s going on.
Cheers
On 22/09/23 12:42PM, Ingmar M via RIOT wrote:
Hi,
I have compiled and installed the tests/driver_sx126x application with the board set to the lora_e5 device and it runs until it tries to initialise the sx1262. I placed additional puts statements in to allow me to trace the code.
if (netdev->driver->init(netdev) < 0) { puts(“Failed to initialize SX126X device, exiting”); return 1; }
It locks up during the init phase and never gets to the “Failed” message. Given I know my hardware works with my STM32mx app I assume it is still an issue in the sx126x driver.
Visit Topic or reply to this email to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, click here.
Hello!
I’m a new one too in RIOT and I have the same issue on the STM32WLE5CC with on-chip subghz module sx126x. System halted in sx126x_netdev in string №145 netdev->event_callback(netdev, NETDEV_EVENT_LINK_UP)
Hi,
Sorry about the delay I have been down with Covid (still sick after 2 weeks).
Please see below:
2022-10-14 11:50:20,518 # main(): This is RIOT�ain(): This is RIOT! (Version: 2022.10-devel-1143-gea0a5)
2022-10-14 11:50:20,522 # [sx126x] init: SPI_0 initialized with success
2022-10-14 11:50:20,526 # [sx126x]: sx126x_set_channel 868300000Hz
2022-10-14 11:50:20,529 # [sx126x] init radio: pkt type: 255
2022-10-14 11:50:20,532 # [sx126x] init: chip mode 7
2022-10-14 11:50:20,534 # [sx126x] init: cmd status 7
2022-10-14 11:50:20,534 #
2022-10-14 11:50:20,536 # Context before hardfault:
2022-10-14 11:50:20,538 # r0: 0x20000774
2022-10-14 11:50:20,540 # r1: 0x00000008
2022-10-14 11:50:20,542 # r2: 0x00000002
2022-10-14 11:50:20,543 # r3: 0x00000000
2022-10-14 11:50:20,545 # r12: 0x0000001c
2022-10-14 11:50:20,546 # lr: 0x08002e19
2022-10-14 11:50:20,548 # pc: 0x00000000
2022-10-14 11:50:20,550 # psr: 0x20000000
2022-10-14 11:50:20,550 #
2022-10-14 11:50:20,550 # FSR/FAR:
2022-10-14 11:50:20,552 # CFSR: 0x00020000
2022-10-14 11:50:20,554 # HFSR: 0x40000000
2022-10-14 11:50:20,555 # DFSR: 0x00000008
2022-10-14 11:50:20,557 # AFSR: 0x00000000
2022-10-14 11:50:20,557 # Misc
2022-10-14 11:50:20,559 # EXC_RET: 0xfffffffd
2022-10-14 11:50:20,561 # Active thread: 1 "main"
2022-10-14 11:50:20,565 # Attempting to reconstruct state for debugging...
2022-10-14 11:50:20,566 # In GDB:
2022-10-14 11:50:20,567 # set $pc=0x0
2022-10-14 11:50:20,568 # frame 0
2022-10-14 11:50:20,569 # bt
2022-10-14 11:50:20,569 #
2022-10-14 11:50:20,573 # ISR stack overflowed by at least 16 bytes.
2022-10-14 11:50:20,575 # *** RIOT kernel panic:
2022-10-14 11:50:20,576 # HARD FAULT HANDLER
2022-10-14 11:50:20,576 #
2022-10-14 11:50:20,578 # *** halted.
2022-10-14 11:50:20,578 #
2022-10-14 11:50:20,579 # Inside isr -13
FYI if I increase the ISR_STACKSIZE in cpu/cortexm_common/include/cpu_conf_common.h from (512U) to (768U) the “stack overflows by at least 16 bytes” message goes away but the hard fault remains.
Typically the ISR stack overflow after a hard fault is actually cuased by the hard fault handler: When using newlib, printf() and friends have insane stack requirements, even in the nano flavor. And since printf() is used to print this Context before harfault: ... message, this will surely overflow the ISR stack.
This is not as bad as it sounds: Since the hard fault handler never returns to the threads running before the hard fault, it doesn’t matter that the hard fault handler corrupted memory. And I hope that we switch to picolibc as default lib soonish anyway, which has a much saner stdio implementation.
This leaves you with the hard fault. Typically, this is some invalid memory access. E.g. writing to a NULL pointer, an unaligned memory access on Cortex M0(+), etc. can cause this. Since the hard fault handler was unable to get a sensible program counter (pc: 0x00000000 is not plausible), this message is not really helpful. The best to do now would be to attach GDB (make debug will do just that) and set a break point in the sx126x initialization function. From there, step through the code. First use next to step over function calls to identify which function is the culprit. Then set a breakpoint in that function and start again. Eventually, you will have nailed it down to the exact line that is causing the hard fault. Hopefully this gives the clue to what is wrong.
pc: 0x00000000 is actually quite interesting, it means there is a function pointer that was NULL.
Luckiely there is also lr: 0x08002e19 which will point to the previous function. If you resolve this pointer with arm-none-eabi-addr2line -e bin/lora-e5-dev/*.elf 0x08002e19 and check where e.g. a callback function is called in that vicinity, you might already find the bug.
Hello!
This command returns …/sx162x_netdev.c: 147 (discriminator 6) for my lr addr ( lr: 0x080033f7). In sx162x_netdev.c:147 I have return 0 , but on 146:
netdev->event_callback(netdev, NETDEV_EVENT_LINK_UP);
I think I know what’s going on. I will post the results ASAP.
A LINK_UP event was recently introduced. As a result, the driver will call NETDEV_EVENT_LINK_UP on init.
However, the event_callback function pointer must be set before calling init, otherwise it will try to call a NULL pointer function.
I noticed that tests/driver_sx126x actually sets the event_callback after calling init, which used to be not a problem. But we should change that now.
@Ingmar_M @HoCoK could you please try the following patch?
diff --git a/tests/driver_sx126x/main.c b/tests/driver_sx126x/main.c
index 104905e480..038aa86fff 100644
--- a/tests/driver_sx126x/main.c
+++ b/tests/driver_sx126x/main.c
@@ -325,13 +325,13 @@ int main(void)
netdev->driver = &sx126x_driver;
+ netdev->event_callback = _event_cb;
+
if (netdev->driver->init(netdev) < 0) {
puts("Failed to initialize SX126X device, exiting");
return 1;
}
- netdev->event_callback = _event_cb;
-
_recv_pid = thread_create(stack, sizeof(stack), THREAD_PRIORITY_MAIN - 1,
THREAD_CREATE_STACKTEST, _recv_thread, netdev,
"recv_thread");
Yeah, that’s work! My thanks go to you
BTW there’s already a fix that should get merged very soon: tests: set netdev `event_callback` before calling init by jia200x · Pull Request #18745 · RIOT-OS/RIOT · GitHub
Thanks for all the activity since my last post. I’m still a little slow on the recovery. I’ll try the fix you proposed. Much appreciated. Cheers Ingmar
Yep that did it, thanks again.