How to on STM32Cube_FW_WL_V1.1.0

[FRest.1]

Hello,

I’m working with NUCLEO-WL55JC1. I’ve done some tests with STM32CubeIDE ver 1.6.1 firmware 1.0.0 (STM32Cube_FW_WL_V1.0.0) and, after some difficulty, it’s working as aspected. To fix ideas on the job done, I’ve made a Youtube video (https://youtu.be/40wuXKoA44Y).

Then I’ve updated STM32CubeIDE to version 1.7.0 and loaded a new firmware version 1.1.0. Of course, something is changed.

Now seems that the use of BSP Driver is mandatory (file platform.h row 32). I’ve imported in my project, from firmware 1.1.0, the BSP driver and added the path on the IDE setting.

Then I was able to compile without errors. I’ve sent the new code on the Nucleo board. It starts and I’ve initial data on debugger console. The initial try to connect to the TTN application shows that the join seems accepted, but then no more data are sent. It looks like if the loop (with default 1000 mS) does not take place. At the moment I have no idea how to proceed (again, I'll have to spend a very long time e to fix the problem :confounded_face: :) )

Can I have some help,

Thanks, Fabrizio

[FRest.1]

Ok, something I've found.

Creating a project from the .ioc file (that on the STM32Cube_FW_WL_V1.1.0.zip file), the lora_app.c file is not complete (different to the respect o the one on the zip file) and the SendTxData function is empty. 

The same happens if I create a project from the example from STM32CubeIDE.

So, how to load a working example?

Fabrizio

[FRest.1]

Accipicchia, devono essere tutti in ferie, non c'è un cane che ti da un adritta. :(

[IREMI.1]

Hi, indeed the colleagues working with CubeIDE are on vacation, caspiterina.

I try to give you a reply about v1.0.0 vs v1.1.0 and about BSP

In version v1.0.0 MX was indeed generating a full working application but not flexible.

We got feedback asking to be similar to other STM32 models, i.e. MX to provide initialization and user to fill /*USER CODE SECTIONS */.

V1.1.0 in this direction: In the LoraWAN application panel there is a choice for three skeletons

 - "user defined" skeleton

 - "end node" skeleton

 - "AT_Slave" skeleton

which means that in all cases MX generate the bones (with different level) and the user shall complete the /*USER CODE SECTIONS */ with its own code to get a working application.

The examples in the intropack zip file show how to fill /*USER CODE SECTIONS */ to get a working application.

About BSP, MX does not support BSP, in v1.0.0 Lora MW provided pseudodriver at application level to replace the BSP.

 - the radio part was implemented as part of the switch cases in radio_board_if.c/h

 - the led/pushbutton was implemented in the file board_resorces.c/h 

Version v1.1.0 aligns with STM32 strategy that allows to include in the IDE projects the path to BSP, thanks to the .extSettings

 - the radio part has been removed from the radio_board_if.c/h switch case

 - the board_resorces.c/h is not generated by default unless user select "Board Resorces" in the panel and it configures the pins on the platforms-etting panel.

However this is not the suggested strategy. board_resorces.c/h have been keep rather for custom board or to add led and PB not originally present in the BSP of the nucleo (e.g. when adding shields).

The recommended strategy is now to copy the BSP from the intropack zip and included in your IDE project via .extSettings

If for backward compatibility reason you necessarily need to keep previous model, you can use board resources for led/pb as said earlier, and about the radio pins handling (), we could tell you privately how to generate the code in the radio_board_if.c/h switch similarly to v1.0.0.

[FRest.1]

Hello IREMI.1, your response reflects what I've found.

The firmware version 1.1 seems working. I've copied BSP drivers from the downloaded zip into the Drivers folder of my project and then registered it on paths and symbols.

After that, I was able to compile without problems. 

For a complete working example, also I've copied the file lora_app.c from the downloaded zip file: the generated one is just a skeleton.

Now the example is working as in the previous version.

I'm trying to expand the project with my own sensors. I had found some problems with firmware version 1.0 (I need a timer with uS resolution), now I'm trying to replicate this change on the new version.

I need to better interact with the program structure, sequencer, timer, and so on. The documentation is no so easy as I'm able to understand. :face_with_steam_from_nose:

Thank you for your help,

Fabrizio

[IREMI.1]

Hi FRest,

typically STM32 example use systick as time base.

This is not the case for the RF applications because they exploit LowPower (systick does not work in STOP mode).

Furthermore the RF application use the utilities TimeServer which allow to handle "sw timers" in parallel (based on RTC HW).

For your sensors, you have two possibilities

 - reuse the timeServer (if resolution allows it)

 - use a different time source for example LPTIM, and set it at your resolution (us)

[CDenk.1]

Dear @IREMI.1​ ,

the "intropack zip" is the STM32Cube_FW_WL_V1.1.0 file we download?

I found your note very helpful for understanding v1.1.0! I am looking for a reproducible way to generate code for a custom board (only 1 led and 1 button), would you recommend to select "Add LEDs/PB via Platform Settings" and just define one LED and one button there in this case?

Thanks for any help!

[FRest.1]

Until now I've only worked with the LoRaWAN end node.

 If you generate the code from the .ioc file using firmware 1.0 the application is working.

With firmware 1.1, the behavior is different. The generated code isn't complete.

1) You need a BSP driver. Expand the STM32cubewl zip file, look for the BSD drivers folder, import them on the LoRaWAN end node project and add the path ( Project property -> C/C++ general -> Paths & symbols).

2) Complete the Lora-app.c file with what is needed. The easiest way is coping it from the firmware zip file.

Rebuild the project. This is what I've done.

F.

[FRest.1]

I've worked with this file.

[IREMI.1]

Hi CDenk,

first you select the two pins concerned in the pin out pannel.

Then you have two choices: 

 - the classical one is to write your own code in the user code sections to endle the pins

 - second one is a service we provided, available selecting 

  "board resources = add led/pb via platfor mettings"

  This service allows you to chose at max 3 LED and 3 PB (you need just 1+1)

  a "pseudo BSP" file called board_resorces.c/h will be generated 

  with some API that allows you to handle easily your led and PB 

  (Init function, toggle function, etc).

If this second service is confusing we could remove it for next release ... let us know your feedback. tnx