The recommended strategy is now to copy the BSP from the intropack zip and included in your IDE project via .extSettings 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. However this is not the suggested strategy. 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. the radio part has been removed from the radio_board_if.c/h switch case Version v1.1.0 aligns with STM32 strategy that allows to include in the IDE projects the path to BSP, thanks to the. the led/pushbutton was implemented in the file board_resorces.c/h the radio part was implemented as part of the switch cases in radio_board_if.c/h The examples in the intropack zip file show how to fill /*USER CODE SECTIONS */ to get a working application.Ībout BSP, MX does not support BSP, in v1.0.0 Lora MW provided pseudodriver at application level to replace the BSP. 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. V1.1.0 in this direction: In the LoraWAN application panel there is a choice for three skeletons
MX to provide initialization and user to fill /*USER CODE SECTIONS */. We got feedback asking to be similar to other STM32 models, i.e. In version v1.0.0 MX was indeed generating a full working application but not flexible. I try to give you a reply about v1.0.0 vs v1.1.0 and about BSP Hi, indeed the colleagues working with CubeIDE are on vacation, caspiterina. 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: ) It looks like if the loop (with default 1000 mS) does not take place. The initial try to connect to the TTN application shows that the join seems accepted, but then no more data are sent. It starts and I’ve initial data on debugger console. I’ve sent the new code on the Nucleo board. Then I was able to compile without errors. I’ve imported in my project, from firmware 1.1.0, the BSP driver and added the path on the IDE setting. Now seems that the use of BSP Driver is mandatory (file platform.h row 32). Then I’ve updated STM32CubeIDE to version 1.7.0 and loaded a new firmware version 1.1.0.
To fix ideas on the job done, I’ve made a Youtube video (). 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.