Panic when running on JC1 variant

[barafael]

I have tried running this on JC1 nucleo variant. With unchanged code, the client outputs:

75.541355 ERROR server did not respond to time sync request in Duration { secs: 0, nanos: 100000000 }
└─ client::locked_radio @ client/src/main.rs:138

repeatedly.

When changing RF_FREQ to RfFreq::F868, then running first

> cargo run -p server -- --probe 002E001E3756501620303658 10.7s  Fr 19 Nov 2021 14:38:54 CET and then running:

> cargo run -p client -- --probe 0027000E3756501520303658                                                    12.5s  Fr 19 Nov 2021 14:38:38 CET
   Compiling client v0.1.0 (/home/rafaelbachmann/stm32wl-lightswitch-demo/client)
    Finished dev [optimized + debuginfo] target(s) in 0.38s
     Running `probe-run --chip STM32WLE5JCIx target/thumbv7em-none-eabi/debug/client --probe 0027000E3756501520303658`
(HOST) INFO  flashing program (29.49 KiB)
(HOST) INFO  success!
────────────────────────────────────────────────────────────────────────────────
2.513276 ERROR panicked at 'rfbusys timeout pwr.sr2=0x1F7 pwr.subghzspicr=0x8000 pwr.cr1=0x300'
└─ stm32wlxx_hal::subghz::{impl#2}::poll_not_busy @ /home/rafaelbachmann/.cargo/registry/src/github.com-1ecc6299db9ec823/stm32wlxx-hal-0.2.0/src/fmt.rs:102
2.513356 ERROR panicked at 'explicit panic', /home/rafaelbachmann/.cargo/registry/src/github.com-1ecc6299db9ec823/defmt-0.3.0/src/lib.rs:367:5
└─ panic_probe::print_defmt::print @ /home/rafaelbachmann/.cargo/registry/src/github.com-1ecc6299db9ec823/panic-probe-0.3.0/src/lib.rs:91
────────────────────────────────────────────────────────────────────────────────
stack backtrace:
   0: HardFaultTrampoline
      <exception entry>
   1: _ZN3lib6inline5__udf17h4878bf20408765ceE
        at ./asm/inline.rs:172:5
   2: __udf
        at ./asm/lib.rs:49:17
   3: _ZN8cortex_m3asm3udf17h0e8cf67a3a3a157eE
        at /home/rafaelbachmann/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-0.7.3/src/asm.rs:43:5
   4: rust_begin_unwind
        at /home/rafaelbachmann/.cargo/registry/src/github.com-1ecc6299db9ec823/panic-probe-0.3.0/src/lib.rs:72:9
   5: _ZN4core9panicking9panic_fmt17h8fa5fa67ee0bfd00E
        at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/core/src/panicking.rs:101:14
   6: _ZN4core9panicking5panic17h49a2e66b50147765E
        at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/core/src/panicking.rs:50:5
   7: __defmt_default_panic
        at /home/rafaelbachmann/.cargo/registry/src/github.com-1ecc6299db9ec823/defmt-0.3.0/src/lib.rs:367:5
   8: _ZN5defmt6export5panic17h6da030e8b550b24eE
        at /home/rafaelbachmann/.cargo/registry/src/github.com-1ecc6299db9ec823/defmt-0.3.0/src/export/mod.rs:125:14
   9: _ZN13stm32wlxx_hal6subghz25SubGhz$LT$MISO$C$MOSI$GT$13poll_not_busy17hecf3cc4ac736e36fE
        at /home/rafaelbachmann/.cargo/registry/src/github.com-1ecc6299db9ec823/stm32wlxx-hal-0.2.0/src/subghz/mod.rs:382:17
  10: _ZN91_$LT$$LP$T1$C$T2$C$T3$C$T4$C$T5$C$T6$C$T7$RP$$u20$as$u20$rtic_core..prelude..TupleExt07$GT$4lock28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$17hc55426aa9efb3f70E
        at /home/rafaelbachmann/.cargo/registry/src/github.com-1ecc6299db9ec823/rtic-core-0.3.1/src/lib.rs:121:30
  11: _ZN91_$LT$$LP$T1$C$T2$C$T3$C$T4$C$T5$C$T6$C$T7$RP$$u20$as$u20$rtic_core..prelude..TupleExt07$GT$4lock28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$17h8fa59716f4c9fa77E
        at /home/rafaelbachmann/.cargo/registry/src/github.com-1ecc6299db9ec823/rtic-core-0.3.1/src/lib.rs:124:47
  12: _ZN8cortex_m8register7basepri5write17h0e186d39d6814eccE
        at /home/rafaelbachmann/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-0.7.3/src/register/basepri.rs:22:9
  13: _ZN4rtic6export3run17h7b30cd2a141873d1E
        at /home/rafaelbachmann/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-rtic-0.6.0-rc.4/src/export.rs:34:18
  14: RADIO_IRQ_BUSY
        at client/src/main.rs:155:1
      <exception entry>
  15: __wfi
        at ./asm/lib.rs:50:14
  16: main
        at client/src/main.rs:155:1
  17: Reset
  (HOST) WARN  call stack was corrupted; unwinding could not be completed
  (HOST) ERROR the program panicked

[newAM]

That definitely shouldn't be occurring. I don't have time today, I will take a look tomorrow.

[newAM]

I reproduced this on the JC2.

This is occurring on the calls to set_sleep in the client. Now as for why... that is a good question.

https://github.com/newAM/stm32wl-lightswitch-demo/blob/8d7349317442c2504bac267d5b51477fe8649cac/client/src/main.rs#L88 https://github.com/newAM/stm32wl-lightswitch-demo/blob/8d7349317442c2504bac267d5b51477fe8649cac/client/src/main.rs#L131

I suspect polling for busy to clear may be invalid when entering sleep mode, and that this was always a problem, and was only exposed when the code around it changed the timing. More investigation needed.

[newAM]

That is definitely the case - busy idles high while the radio is in sleep mode.

[newAM]

I fixed this in the HAL and made a 0.2.1 release, this should be fixed now. Please let me know if you have any other problems!

Thanks for the bug report!

[barafael]

Thanks for fixing it so quickly! I'll check it out soon :)

[barafael]

works nicely :)