Target NUCLEO WL55JC does not compile

[hallard]

Description of defect

When trying to compile this example for target NUCLEO WL55JC it does fire an error

Compile [  2.2%]: mbed_boot_arm_std.c
Compile [  2.3%]: main.cpp
[Error] lora_radio_helper.h@81,19: no matching constructor for initialization of 'STM32WL_LoRaRadio'
[Warning] main.cpp@180,26: 'call_in' is deprecated: Pass a chrono duration, not an integer millisecond count. For example use `5s` rather than `5000`. [since mbed-os-6.0.0] [-Wdeprecated-declarations]
[Warning] main.cpp@180,26: 'call_in<void (*)()>' is deprecated: Pass a chrono duration, not an integer millisecond count. For example use `5s` rather than `5000`. [since mbed-os-6.0.0] [-Wdeprecated-declarations]
[Warning] main.cpp@224,26: 'call_every' is deprecated: Pass a chrono duration, not an integer millisecond count. For example use `5s` rather than `5000`. [since mbed-os-6.0.0] [-Wdeprecated-declarations]
[Warning] main.cpp@224,26: 'call_every<void (*)()>' is deprecated: Pass a chrono duration, not an integer millisecond count. For example use `5s` rather than `5000`. [since mbed-os-6.0.0] [-Wdeprecated-declarations]
[ERROR] In file included from ./main.cpp:26:
./lora_radio_helper.h:81:19: error: no matching constructor for initialization of 'STM32WL_LoRaRadio'
STM32WL_LoRaRadio radio(MBED_CONF_STM32WL_LORA_DRIVER_RF_SWITCH_CTL1,
^     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./mbed-os/connectivity/drivers/lora/TARGET_STM32WL/STM32WL_LoRaRadio.h:56:7: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 3 were provided
class STM32WL_LoRaRadio : public LoRaRadio {
^
./mbed-os/connectivity/drivers/lora/TARGET_STM32WL/STM32WL_LoRaRadio.h:59:5: note: candidate constructor not viable: requires 0 arguments, but 3 were provided
STM32WL_LoRaRadio();
^
./main.cpp:180:26: warning: 'call_in' is deprecated: Pass a chrono duration, not an integer millisecond count. For example use `5s` rather than `5000`. [since mbed-os-6.0.0] [-Wdeprecated-declarations]
ev_queue.call_in(3000, send_message);
^
./mbed-os/events/include/events/EventQueue.h:926:9: note: 'call_in' has been explicitly marked deprecated here
int call_in(int ms, F f)
^
./main.cpp:180:26: warning: 'call_in<void (*)()>' is deprecated: Pass a chrono duration, not an integer millisecond count. For example use `5s` rather than `5000`. [since mbed-os-6.0.0] [-Wdeprecated-declarations]
ev_queue.call_in(3000, send_message);
^
./mbed-os/events/include/events/EventQueue.h:925:5: note: 'call_in<void (*)()>' has been explicitly marked deprecated here
MBED_DEPRECATED_SINCE("mbed-os-6.0.0", "Pass a chrono duration, not an integer millisecond count. For example use `5s` rather than `5000`.")
^
./mbed-os/platform/include/platform/mbed_toolchain.h:424:37: note: expanded from macro 'MBED_DEPRECATED_SINCE'
#define MBED_DEPRECATED_SINCE(D, M) MBED_DEPRECATED(M " [since " D "]")
^
./mbed-os/platform/include/platform/mbed_toolchain.h:405:43: note: expanded from macro 'MBED_DEPRECATED'
#define MBED_DEPRECATED(M) __attribute__((deprecated(M)))
^
./main.cpp:224:26: warning: 'call_every' is deprecated: Pass a chrono duration, not an integer millisecond count. For example use `5s` rather than `5000`. [since mbed-os-6.0.0] [-Wdeprecated-declarations]
ev_queue.call_every(TX_TIMER, send_message);
^
./mbed-os/events/include/events/EventQueue.h:1083:9: note: 'call_every' has been explicitly marked deprecated here
int call_every(int ms, F f)
^
./main.cpp:224:26: warning: 'call_every<void (*)()>' is deprecated: Pass a chrono duration, not an integer millisecond count. For example use `5s` rather than `5000`. [since mbed-os-6.0.0] [-Wdeprecated-declarations]
ev_queue.call_every(TX_TIMER, send_message);
^
./mbed-os/events/include/events/EventQueue.h:1082:5: note: 'call_every<void (*)()>' has been explicitly marked deprecated here
MBED_DEPRECATED_SINCE("mbed-os-6.0.0", "Pass a chrono duration, not an integer millisecond count. For example use `5s` rather than `5000`.")
^
./mbed-os/platform/include/platform/mbed_toolchain.h:424:37: note: expanded from macro 'MBED_DEPRECATED_SINCE'
#define MBED_DEPRECATED_SINCE(D, M) MBED_DEPRECATED(M " [since " D "]")
^
./mbed-os/platform/include/platform/mbed_toolchain.h:405:43: note: expanded from macro 'MBED_DEPRECATED'
#define MBED_DEPRECATED(M) __attribute__((deprecated(M)))
^
4 warnings and 1 error generated.

Target(s) affected by this defect ?

NUCLEO_WL55JC

Toolchain(s) (name and version) displaying this defect ?

GCC_ARM

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.12.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbeb Studio or mbed-tools V2

How is this defect reproduced ?

import example https://github.com/ARMmbed/mbed-os-example-lorawan/

select target NUCLEO-WL55JC

clean build from IDE or from terminal mbed-tools compile -t GCC_ARM -m NUCLEO_WL55JC --clean

FYI same setup works selecting target DISCO-L072CZ-LRWAN1

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-4128

[elrom]

FWIW, looks like the interface for STM32WL_LoRaRadio changed, but the example wasn't updated accordingly (the only constructor is the default one - yet the example passes 3 params). An updated example would be greatly appreciated!

[elrom]

P.s.
curiously, I get different results with the IDE vs cli tools.
Modifying the instantiation to pass 0 params is sufficient to get the example to compile when using the IDE. However when using the cli tools, it still results in subsequent linker errors, e.g:

/usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/bin/ld: CMakeFiles/mbed-os-example-lorawan.dir/mbed-os/connectivity/drivers/lora/TARGET_STM32WL/STM32WL_LoRaRadio.cpp.obj: in function `STM32WL_LoRaRadio::STM32WL_LoRaRadio()':
/home/elrom/mbed-os-example-lorawan/cmake_build/NUCLEO_WL55JC/develop/GCC_ARM/../../../../mbed-os/connectivity/drivers/lora/TARGET_STM32WL/STM32WL_LoRaRadio.cpp:128: undefined reference to `set_antenna_switch(RBI_Switch_TypeDef)'

[jeromecoutant]

Hi
My fault.. I didn't update example
Please check #233

[hallard]

@jeromecoutant thanks,

My bad, I searched for the 3 symbols for STM32WL could not find them so was thinking it was the issue, not thought
about removed them. But not using them brings me another question because if they are removed this means they are hard coded. Which is fine for Nucleo WL55 that is wired as follow

PC3 -> FE_CTRL3
PC4 -> FE_CTRL1
PC5 -> FE_CTRL2
PB0-> VDD_TCXO

pay attention setting FE_CTRL1 and FE_CTRL2 to low will turn off RF switch (no send, no receive)

But we're using some custom module such as LoRa-E5 from seeed

And the Wiki says that LoRa-E5 module ONLY transmits through RFO_HP and that Receive is done with PA4=1, PB5=0 and Transmit(high output power, SMPS mode) with PA4=0, PB5=1

So in LoRa-E5 module looks like in this case we have:

• PC3 -> FE_CTRL3 not connected
• PA4 -> FE_CTRL1
• PA5 -> FE_CTRL2
• PB0-> VDD_TCXO

So pins are different from NUCLEO

As we also plan to try RAK3172 modules also

I asked to RAK wiring and they kindly and promptly replied (thanks to them), here it is the wiring for RAK3172

• PC3 -> FE_CTRL3 not connected
• PB8 -> FE_CTRL1
• PC13 -> FE_CTRL2
• PB0-> VDD_TCXO

I can try to create new PR to add new boards as mbed new targets but I may need some direction to help on LoRaWAN config side. I already added them as new targets (without LoRaWAN config), it compile and works fine so just need to add them now for LoRaWAN config. As you seems to be the expert on this side, any help will be greatly appreciated.

Charles

[jeromecoutant]

My bad, I searched for the 3 symbols for STM32WL could not find them so was thinking it was the issue, not thought
about removed them. But not using them brings me another question because if they are removed this means they are hard coded. Which is fine for Nucleo WL55 that is wired as follow

In fact, this was exactly goal of ARMmbed/mbed-os#14734
It was hardcoded before, now you can redefine set_antenna_switch weak function.
Don't hesitate to tell us if this is not suitable for you.

I can try to create new PR to add new boards as mbed new targets

Yes, we will be happy to review it!

@ARMmbed/team-st-mcd

[hallard]

@jeromecoutant interesting, in the meantime I found a solution settings these pins as follow in mbed_app.json

        "LORA_E5": {
            "stm32wl-lora-driver.debug_rx": "LED1",
            "stm32wl-lora-driver.debug_tx": "LED2",
            "stm32wl-lora-driver.rf-switch-ctl1": "PA_4",
            "stm32wl-lora-driver.rf-switch-ctl2": "PA_5",
            "stm32wl-lora-driver.rf-switch-ctl3": "NC"
        },

But now I have another issue, mbed just fire a HardFault once the sample flashed.

++ MbedOS Fault Handler ++

FaultType: HardFault

Context:
R   0: 00000000
R   1: 00000000
R   2: 00000000
R   3: 0000000C
R   4: 20001FF4
R   5: 00000000
R   6: 00000000
R   7: 00000000
R   8: 00000000
R   9: 00000000
R  10: 00000000
R  11: 00000000
R  12: 64000000
SP   : 20001FE0
LR   : 0800798F
PC   : 08004154
xPSR : 61000000
PSP  : 20001FC0
MSP  : 2000FFD0
CPUID: 410FC241
HFSR : 40000000
MMFSR: 00000082
BFSR : 00000000
UFSR : 00000000
DFSR : 00000000
AFSR : 00000000
MMFAR: 00000000
Mode : Thread
Priv : Privileged
Stack: PSP

-- MbedOS Fault Handler --


++ MbedOS Error Info ++
Error Status: 0x80FF013D Code: 317 Module: 255
Error Message: Fault exception
Location: 0x8004154
Error Value: 0x200022EC
Current Thread: main Id: 0x20002690 Entry: 0x800F28D StackSize: 0x1000 StackMem: 0x200010B8 SP: 0x20001FE0 
For more info, visit: https://mbed.com/s/error?error=0x80FF013D&tgt=LORA_E5
-- MbedOS Error Info --

I must admit that something is out of my brain because I can run other samples with this custom target board (atecc608, spiflash, blink, ...) without any issue. So my. guess it's related to LoRaWAN and my board definition.

Based on NUCLEO-WL55 which is dual core the LoRa-E5 (and RAK3172) are based on STM32WLE5, and it's single core so may be I missed something in my custom target definition

Anyway, to makes things easier and code availability I forked this example and created both custom target on branch lora-e5 , check here

So now If a board guru have some can check if I missed something un custom targets definition, it will be awesome.

Once fixed, I'll remove the custom target from this sample code (deleting this branch) to put them into main mbed-os, but I need to check everything is working fine before that.

PS : Definition is for this custom board

Thanks

[hallard]

Ok took me some time to figure all this out, everything is fixed with this new PR done on mbed-os that add these 2 new modules.
ARMmbed/mbed-os#14859

[jeromecoutant]

Let's close this issue ?

And on a PR on this example repo to add the new modules ?

[hallard]

yes, no need example, once PR ARMmbed/mbed-os#14859 merged, this example will works with new boards