ST released a new evaluation board for the development, prototyping or evaluation of the CMWX1ZZABZ-091 LoRa module and/or the Teseo-LIV3F GNSS module.
The software target the Loriot IoT network and machineQ and with the help of the forum I would like to adapt the software so it can connect to The Things Network and as a streched goal get it to run Mbed OS 5 so it can support FUOTA.
The software can be downloaded here: https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32-ode-function-pack-sw/fp-atr-lora1.html
I have tried to connect to TTN with the Nucleo + Sensor shields HW but I just get a join but no data.
Processing command: ?devicejoinparameters
DevEui(FromMcuId) = 32 37 32 38 47 37 76 08
Active keys:
DevEui = 32 37 32 38 47 37 76 08
JoinEui = 01 01 01 01 01 01 01 01
AppKey = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
NwkKey = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The application is using a JoinEui. When I see the device set-up page in Applications there is a DevAddr for the OTAA.
Are there two different methods of OTAA ?
I think its neccessary for OTAA lorawan 1.1 (TTN stack V3)
1.1-LoRaWAN_1.1_Specification.pdf (2.2 MB)
I will first start to read the TTN stack V3 manuals then 
I found this, I don’t know if it will help though. At least it talks about ttn and app integration.
I really like the design of this board, but it’s a little steep in price. If they officially make it work with mbed, I may get one. Lots of flash, but weak on the RAM it seems. (20k). Claims to be really low power.
Hi Karl,
the STEVAL-STRKT01 page @st website is now updated with documentation and new fw has been released in the FP-ATR-LORA1 page. Refer to the “command list” table in the user manual(s) and send the appropriate commands to set your own LoRa keys. The quick start guide (link) could be helpful too. About the data format in the sent packet, have a look at the FP-ATR-LORA1 user manual (link) 3.5.2 paragraph
That looks very useful, thanks !
I don’t have access to the node this weekend but I will give it a try next Monday.
Is the same firmware usable on the Nucleo + Sensor boards stack as well ?
Yes, of course, the FP-ATR-LORA1 contains the two projects for the STEVAL-STRKT01 integrated solution and for B-L072Z-LRWAN1 + X nucleos modular solution. You will find two separate project folders with the same application.
Then I test it this afternoon!
I have tried it, but using Keil it runs in to this error during compilation: .\mlm32l07x01\NUCLEO_CUBE_LORA.axf: Error: L6218E: Undefined symbol BSP_PowerGNSS (referred from usb_user.o).
.\mlm32l07x01\NUCLEO_CUBE_LORA.axf: Error: L6218E: Undefined symbol BSP_PowerSensors (referred from usb_user.o).
The readme shows that the project for the B-L072Z-LRWAN1 is out-dated. Will try again tomorrrow the the IoT Tracker.
Hi @effesud
The project for the tracker compiled OK and I reprogrammed the board. The console of TTN recieves a join but the device never gets the join accepted back it seems.
Now it works !
Charging the battery right now and will take it for a drive from Amsterdam to Nijmegen today.
I have received the STEVAL-STRKT01 this week and I must say that the first user experience is terrible. Following all the guides to program the OTAA joinEUI and AppKey via de serial interface does not work with the code that is running in the device as delivered.
?devicejoinparam is working fine and shows the device EUI and the standard joinEUI 01-01-01-01-01-01-01-01 - I can also see that the device is trying to join on the lorawan network. However, to complete the join, I need to change the keys.
However the command: !joineui-0202020202020202 just does not change the pre-programmed joinEUI. It just does not want to overwrite the pre-programmed settings. The same is for the appKey. It looks like the code has some serious flaws and this is not documented.
Are there people with the same experience?
I entered all the keys in the source code. Maybe the updated project (2.0.0) works better ?
It also helps if you configure local echo in the serial terminal.
I am using echo mode as indicated in the manual.
Also, the project files for WB4STM32 in combination with STEVAL-STRKT01 give all kinds of errors while compiling and there seems a mixup with the project for B-L072Z-LRWAN1
I am waiting for support from ST now. Will report an update here.
I used the free version of Keil in this case. All STM32 M0’s are included in that version without code size limit.
I confirm that the commands to set the keys via USB are available only in the latest fw version 2.0.1.
There a “Binary” folder with the precompiled .bin files if you don’t want to recompile the code
I have tried to compile with the free version of Keil, however it stopped with the 32kbytes code limit. Could you please tell me what exact download of Keil you did use and what settings you have used to get this working?
That is good to know, so I know it is not me getting old 
Now I have to wait for the NUCLEO-F401RE I have ordered, otherwise I can not get the .bin file on the STEVAL-STRKT01. I hope this process goes smooth, since the instructions are also a bit vague
UPDATE: I have received the NUCLEO-F401RE, and I am trying hard to flash the .bin that is provided in the software package. However, the STM ST Link Utility continually disconnects the device, so flashing is not possible at all. I am doing exactly what is indicated in the manual, but this product just seems to be pushed into the market to early. Untill now, I have not gotten any feedback from ST.
To use ST-Link on Nucleo board, you need to remove 2 jumpers closed to SWD interface to swap the interface from processor connection to external board connection. I have upgraded the firmware on the board (1.1) to latest version (2.0) to use AS923 band in Thailand. Please note that there are some limitations for not burning a new firmware:
Even the software seem to be better (less confusing about GNSS connection), but I still can not get any GNSS data from the board even it is outdoor for nearly 2 hours. Other values seem to be ok except accelerometer reading seem to be wrong for redundant values in X- and Z-axis.