Associate III

Question

How to on STM32Cube_FW_WL_V1.1.0

Forum|Forum|4 years ago
July 25, 2021
4 replies
2985 views

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

This topic has been closed for replies.

FRest.1Author

Associate III

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.1Author

Associate III

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

IREMI.1

Visitor II

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.1Author

Associate III

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

FRest.1Author

Associate III

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.

IREMI.1

Visitor II

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)

Sign up

Login with SSO

Login to the community

Login with SSO