Sidewalk SubGhz fail/locks SX1262 on v1.16 with RAK4630

Dear Support

We currently use a custom PCB board with RAK4630 (NRF52840 + Semtech SX1262)

We started to try with RAK sample located here

We used the sample rak4631_sid_dut because it's easier with the shell to pass and test sidewalk commands using serial terminal

Of course we applied both RAK patches for this to work

1) The correct the RF Antenna SW by setting up GPIO 5 instead of 7 (see RAK4630 schematics)

GPIO 7 should not be used because RF Control switch RX/TX direction is toggled by DIO2 of semtech and RAK state this in the documentation


2) Fix TCXO Setting in  sidewalk/subsys/config/common/src/app_subGHz_config.c file as follow

	.tcxo = {
		.ctrl = SX126X_TCXO_CTRL_DIO3,
		.voltage = RADIO_SX126X_TCXO_CTRL_3_3V,
		.timeout = 320,

Until there all is working perfectly fine we can use BLE and LoRa so send our packet and peak consumption when sending LoRa packet is correct 

Now we tried to update and move to latest samples from nrf 2.6-rc1 and sidewalk 1.16

We started from fresh workspace and applied again both previous patches from RAK, then we copied the overlay of the rak4631_nrf52840 board from previous RAK sample repository of course

sid_semtech: &spi1 {
    compatible = "nordic,nrf-spim";
    clock-frequency = <DT_FREQ_M(1)>;
    /delete-property/ cs-gpios;

    lora: lora@0 {
        status = "disabled";

        compatible = "gpio-keys";
        semtech_sx1262_cs: cs {
            gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
            label = "semtech_sx1262 CS";
        semtech_sx1262_reset_gpios: reset {
            gpios = <&gpio1 6 GPIO_ACTIVE_LOW>;
            label = "semtech_sx1262 Reset";
        semtech_sx1262_busy_gpios: busy {
            gpios = <&gpio1 14 GPIO_ACTIVE_HIGH>;
            label = "semtech_sx1262 Busy";
        semtech_sx1262_antenna_enable_gpios: antena_enable {
            gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
            label = "semtech_sx1262 Antena Enable";
        semtech_sx1262_dio1_gpios: dio1 {
            gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
            label = "semtech_sx1262 DIO1";

Building sample sid_end_device with overlay "overlay-dut.conf" (to be able to have shell) is fine, flash is fine and we can use dut  with BLE without any issue

But unfortunately as soon as we try to use sub_ghz semtech chip get locks in consumption of 30mA and only way top recover it to power cycle

sid stop and sid deinit does not recover semtech chip.

What is strange is that all is working fine with board nrf52840dk_nrf52840 + semtech SX1262 shield.

As the rak4631 overlay file is the same than in RAK sample that is working fine, we can assume that semtech pin definition of rak4631 overlay are correct and the issue is coming from something going wrong (changed) into SW stack (hard coded pin matching nrf52840dk + semtech and not other board?)

When we tried zephyr class A lorawan sample with rak4631 board it worked like a charm so this confirm that we can exclude any hardware issue since this issue is present only on sidewalk new version v1.6 

Since sidewalk stack is not open source we can't investigate further on our side (we'd loved to) so any sidewalk nrf guru's help would be very appreciated

I'm posting there because issues are disabled on

  • Hi

    As NCS 2.6-rc1 is a release candidate. I would recommend trying the sample with a qualified version if NCS + Sidewalk and see if the issue persist. From what I read I do get the feeling that you tested it with an older version is that correct? 



  • Hi 

    Sure forgot to mention, using v2.5.2 does works also but still using sidewalk v1.14.

    Sidewalk v1.16 is from main branch of and this one build and works only with 2.6.0-rc1 or 2.6.0-rc2 but once compiled and flashed, does lock the semtech SX1262 on rak4631 board (okay on nrf52840dk+semtech shield) 

    And for information, even reseting the board (that should hard reset semtech with dedicated GPIO1 6) does not seems to reset semtech chip because once locked even after reset, consomption is locked about 35mA. The only way to reset semtech chip is to power cycle.

    So that may confirm there is something wrong driving semtech gpio on version 1.16 of sidewalk stack. We can help to fix and test that point before 2.6.0 release, because in current state it will not work.

    BTW looks like there is experimental option here to Build sub-GHz radio driver from sources, does this mean we could soon build Semtech PAL from sources and have accces to them?



  • Thanks for the clarification. I will hopefully know a bit more later today and update you



  • I will split it into multiple parts

    1. In the DTS the SPI speed is set to 1Mhz, it should be 8MHz

    2. There is a potential issue with the RAK repo. Its manifest pulls nrf and sidewalk, but sidewalk is already part of the nrf begind group filter, so there is a risk that sidewalk and nrf that are pulled are not compatible with each other

    3. There has been some changes with the comming NCS 2.6 and in a few days the migration note might be public, but it can be seen here. I would pay attention to the changes between 1.14 and 1.16 during the initialization. previously the application was responsible for initialization semtech, and now the library does it. 

    4. Regarding building from source: This has been added to enable Semtech to distribute their driver for other radio chips, in the current state, enabling this Config will prevent the prebuild semtech driver to be pulled, so you end up with empty dummy driver and missing dependencies. 

    This driver has been written by Amazon, so we can not share it and I can't really comment on potential road maps here on devzone, for that you would need to contact your regional sales manager or maybe Semtech. 

    My general recommendation would be to wait a few days for the next release of NCS so that there is a public migration note, and hopefully there should be no compatibles issues with RAK repo and ours repo.  



  • Runar,


    1) correct, it was 8Mhz but we tried 1MHz just in case (it's just a copy/paste latest when I created the issue) so all others tries was 8MHz

    2) RAK repos is okay on our side, no issues with this one all is working fine and we don't use it anymore we just using the sdk-sidewalk v2.5.1 that is based on sidewalk v1.14 that is working fine also.

    3) Interesting, what do you mean by application was responsible of semtech initialization? would you mind  point me out where it's done in sdk-sidewalk v2.5.1? I just saw GPIO declaration relayed with overlay file but none of "driving them" nor "initialization" of semtech registers

    3. v1.16) But that may be the issue, if now in 1.16 it's done on the library where do we indicate the correct GPIO mapping of semtech chip, should be again on overlay file but are they really taken into account?

    4) Thanks for this follow up.

    Yes for sure we'll wait few days until 2.6.0 NCS release but my guess if nothing is changed on sidewalk library issue will persist.