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

[Charly86]

Dear Support

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

We started to try with RAK sample located here

https://github.com/RAKWireless/RAK4630-Amazon-Sidewalk-Example

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

github.com/.../sdk-sidewalk

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";
    };
};

/{
    semtech_sx1262_gpios{
        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  github.com/.../sdk-sidewalk

[runsiv]

Hi again

Just a quick update. NCS 2.6 is out now, and as they have changed the model for samples I will try to get back to you tomorrow when i have had the time to go through the changes

Regards

Runar

[Charly86]

Hi Runar,

saw that,  just made a fresh test, 

looks like no more semtech locks issues for rak4631_nrf52840, we can see transmit peaks, but subghz is not working

can't have the LoRa / FSK link to get up, I also tried with init 4 same issue.

After some time we clearly see 10mA consumption guessing it's going to listen mode then throw some errors 

here is the overlay of the RAK board I'm using

/*
 * SPDX-License-Identifier: Apache-2.0
 */

/ {
    chosen {
        zephyr,console = &uart1;
        zephyr,shell-uart = &uart1;
    };
};

&gpio1 {
    sense-edge-mask = <0xffff3b9f>;
};

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

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

/{
    semtech_sx1262_gpios{
        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";
        };
    };
};

this apart, and RAK TCXO patch nothing changed, compiled out of the box with

west build -p -b rak4631_nrf52840 ./sidewalk/samples/sid_end_device -- -DCONF_FILE=prj_no_dfu.conf -DEXTRA_CONF_FILE=overlay-dut.conf

Charles 

[kartben]

Would also he incredibly useful for Nordic to give access to whichever branch/flavour of github.com/.../SWSD006 is being pulled as a pre-compiled library in the Sidewalk SDK so that one can build it from source and potentially debug it / enable traces in it. Doesn't seem to be something available upstream as it fails to link properly when being pulled in as a module + `CONFIG_SIDEWALK_PAL_RADIO_SOURCE=y`

[Charly86]

Runar,

just to let you know that our board RAK4630 works perfectly with Zephyr LoRaWAN class a sample. The issue is there since sidewalk SDK 1.16. @kartben request would help to debug and fix this issue but since code is not public we can't do better on our side.

I can't believe that Sidewalk is not working with RAK4630 for almost one year and still not fixed.

[runsiv]

Thank you for your patience. 

I forwarded the comments yesterday and waiting to hear back from the engineer looking at the RAK board. The debug experience with Sidewalk is not as good as I would like. Licensing and closed source code makes it more difficult then what it should be to investigate issues. 

Regards

Runar

[runsiv]

I have a question from the team. 
Are you able to connect to Sidewalk over BLE or FSK on the RAK board? 

Charly86 said:

Our board works fine with LoRaWAN sample

Was this running with Zephyr?

Regards

Runar

[Charly86]

Runar,

Yep sidewalk works fine in BLE, not LoRa, not FSK (makes sense), I have other boards on desktop with Sidewalk V1.14 that are working fine (so not an infrastructure issue)

and yes lorawan sample from zephyr, sample named class a works fine also

[runsiv]

Thanks for the clarification.  
Regarding the CONFIG_SIDEWALK_PAL_RADIO_SOURCE. Can you try the attached path. Its to be applied in sidewalk repo using git am. It's basically copied sources from semtech repo with cmakes. With this change you can simply build semtech radio pal setting CONFIG_SIDEWALK_PAL_RADIO_SOURCE=y
0001-subsys-add-semtech-pal-sources.patchRegards

Runar

[runsiv]

Hi, So the Sidewalk team has it working now. They also had to change some timing config for the subghz radio. Its not the final solution but you can test this

https://github.com/nrfconnect/sdk-sidewalk/compare/main...ktaborowski:sdk-sidewalk:rak4631dk_nrf52840

Regards

Runar

[Charly86]

Hi Runar,

thanks for this follow up, I've made according changes and seems to work far better (need to check in time). As the branch you mention looks like in between official NCS 2.9.0 SDK and Sidewalk V1.17 SDK here the changes I made on our side

on overlay file (rak4631_nrf52840.overlay) we did not change anything because we already done it on our side and it was matching yours.

on app_subGHz_config.c we changed TCXO voltage to 1.8V and time out according to

		.voltage = RADIO_SX126X_TCXO_CTRL_1_8V,
		// 2 ms to 30.25 us ticks
		.timeout = (2000000 + 30250 / 2) / 30250,

state_timings was already correct in current sidewalk SDK so in our code (500us) we did not change anything on this one

	.state_timings = {
		.sleep_to_full_power_us = 500,
		.full_power_to_sleep_us = 0,
		.rx_to_tx_us = 0,
		.tx_to_rx_us = 0,
		.tcxo_delay_us = 500
	},

Then the deal looks like in sub_ghz_link_config we added retries and set sar_dcr to 100 looks like it's this one that did the trick. Strange thing that .sar_dcr is not in the commit you mention but was not in cirrent Sidewalk SDK so that is why I also needed to add it (took some time to understand)   

.metrics_msg_retries = 3,
.sar_dcr = 100,

Let me know if any changes are needed. BTW also tested setting back TCXO to 3.3V and still works, makes sense since our board is 3.6V powered. 

[runsiv]

I was in a meeting where this was brought up earlier today. the R&D engineer is waiting for some input from Amazon to adjust some parameters for the subghz config. 
regards
Runar