RAK3172 Low-Level Development patches ST firmware release

[danak6jq]

I see the instructions for RAK3172 low-level development start with the STM32WL example code, then copy a handful of files to patch the resulting project.

This means that every time you run Cube to reconfigure peripherals or the LoRa application, the files need to be patched again, because Cube over-writes them.

Also, this means that the project can not be cloned into a new project using Cube

I did the same thing for the RAK3172-E that I did for the Seeed LoRa-E5 Mini; I created a new STM32CubeIDE project from scratch, configuring it the same as the example code, added BSP file support for the RAK3172 (including real battery level and a bit for the RAK5005 power switch) and then merged in the example code changes in lora_app.c.

This means the project can be re-generated as desired (with the warning that one needs to modify one line of code in lora_app.c to use LocalGetBatteryLevel, this is over-written by Cube), and that new projects can be created as desired using the 'new project from existing IOC' feature.

This is still the LoRaWAN End Node Client example from ST with a few changes for my own hardware, but represents a good starting point for application development when cloned.

Initial testing has proven good so far; I invite the experts at RAK to review my BSP file changes, and I also ask you to consider referencing the still-new repo in your documentation for low-level development.

Repo:

https://github.com/danak6jq/RAK3172

[carlrakwireless]

Hi,

Thank you for your awesome contribution. I'll review/check it out and update our Low Level Development guide as necessary 👍🏽

[carlrakwireless]

Hi @danak6jq ,

I initially can't run your code because it was built on CubeIDE v1.8.0. I just updated mine directly from the IDE without reinstalling then all is ok 👍🏽

Then I got issue on Release build configuration since the BSP directory is not included in the Path. I have to I've added it manually so now I can compile it with no errors. I am not sure why I there is no uplink from my device. Already tested in 2 RAK3172. I am pretty sure on the EUI and KEYS. LoRaWAN version of the network server is 1.0.3. I only change CLASS C to CLASS A and nothing else. Do I forget something? You have some sensors in your code but I am not really sure what are those. Any insights you might have is greatly appreciated. Thanks again on your great work 🙂

[danak6jq]

I should do a README about the BSP path. Which region are you testing with? For US915, I didn't select hybrid, so the first Join attempt is missed if the gateway is configured to sub-band 2. 6 seconds later there's a retry and it joins sub-band 2. For other than US915, I don't think there's a sub-band issue, fewer than 8 channels.

Also - I found issues with the default compiler optimization of -O0; go into project settings -> GCC Optimization and select -Og or -O3.

Have you tried plugging a USB cable in to watch the log messages? Paste them here if you can.

[danak6jq]

There should be no issue with changing to Class A

[danak6jq]

Also, when you're attempting to join, have a look at the live LoRaWAN frames on the gateway if you can, see if there's an unaswered Join Request

[carlrakwireless]

I will uninstall the old 1.7.0 STM32CubeIDE version to test it again with freshly installed STM32CubeIDE v1.8.0. It is really suspicious that I don't see any serial logs and any packets received by the Gateway. Thank you for the reply and I'll update you for any progress.

[danak6jq]

Do you have an ST-Link? How are you programming the MCU - with the embedded bootloader or ST-Link?

[carlrakwireless]

Yes I have STLink. I can do it via debug. But on my initial test, I am using a USB-UART via STM32CubeProgrammer since not all users have STLink and using the UART Bootloader is more accessible to most users.

[danak6jq]

Why don't you try programming with ST-Link since that's what I've been using, and I'll try the serial bootloader (USB-Serial + CubeProgrammer)

[carlrakwireless]

Hi @danak6jq ,

Uploading it via STLINK V2 worked :)

[danak6jq]

@carlrakwireless not surprisingly, uploading via the serial bootloader over the USB port (jumpering BOOT0 manually), results in a non-responsive MCU. I'm going to make a simple LED flasher program and try uploading that, or maybe verify/download the flash programmed with ST-Link using the bootloader (it should match)

[danak6jq]

@carlrakwireless I programmed the 3172 with the ST-Link (though it's not this exact repo, it's one derived from it) using ST-Link, and it works correctly (joins, etc.).

Then I filled the 256kB flash with 0xff, verified that (there's a bit of flash at the end that's protected apparently). OK! Then I opened the ELF binary, programmed that, and get a verification failure at 0x8014000 (81920 bytes; the binary extends to 0x801441f - so the last 1,055 bytes are truncated/not programmed. This is starting to look like an issue with STM32CubeProgrammer (or possibly some kind of operator error, though I can't see what)

When attempting to program the larger Debug/RAK3172.elf binary, it's truncated at 0x1E000 length. Same thing when I try to flash RAK3172.bin.

The smaller image was truncated at 0x14000, the larger image at 0x1e000, in both cases, an integer multiple of 4k. I wonder if the programmer code is incorrectly rounding-down (or not rouding-up) the number of 4k blocks to be written.

Because I have ST-Link connected to the same device, I disconnected via USART and connected via ST-Link - and successfully program.

I do not believe there is an (obvious) error in this repo; possibly I need to look at link-loader options to round up the binary to a 4k multiple size as a work-around for STM32CubeProgrammer 2.9.0 ?

[danak6jq]

This appears to be an STM32CubeProgrammer issue.

I've updated the repo with a change to default to -Og optimize for debug; I saw some issues with -O0. Also added AS923 and deleted an extra blank line in sys_app.c

I suggest pulling the repo again to get the optimization change.

[danak6jq]

I've commented at the ST Community forum asking about issues with STM32CubeProgrammer and UART programming, this really seems to be an issue with either STM32CubeProgrammer or the STM32WLE5 embedded bootloader (will check the errata)

[danak6jq]

@carlrakwireless I experimented a bit this evening with UART / bootloader, and found that, after a failed download attempt (programming) where the last sector of the binary is not programmed, using "erase sector" to just erase the last sector, or possibly the last sector and the one before and after, would allow the next programming attempt to succeed. I think this might be an instance of erratum 2.2.2 "Overwriting with all zeros a Flash memory location previously programmed with all ones fails" - but I am not sure why the sector erase would address that.

Anyway, I think you can successfully program with UART/CubeProgrammer if you try this.

[danak6jq]

@carlrakwireless just to summarize - and I think this might apply to any firmware programmed using the UART/embedded bootloader - there's a verify error after attempting the download in CubeProgrammer, it occurs on a sector boundary. Using CubeProgrammer to erase just that sector, or possibly that sector and the ones before/after it, allow the next program/verify to succeed.

I have no reason to believe it is specific to this repo.

[carlrakwireless]

I agree on your assessment @danak6jq . ST might patch the STM32CubeProg and should be able fix the issue. I also got this situation before on with STM32CubeProgrammer on RAK3172. But on that one, I using in Mbed OS. STLinkV2 works but not the UART Bootloader.

On another topic, our RUI (RAKwireless Unified Interface) V3 firmware compatible to RAK3172 is expected to be released soon. This will give us more flexibility in creating custom firmware for RAK3172. It was designed to have higher level abstractions accessible via APIs. I am really excited on this once because it is easier to use (Arduino compatible) and can benefit many RAK3172 users.

[danak6jq]

@carlrakwireless Thanks for looking into this.

I had a look at RUI on RAK811 some time ago, was impressed. I am, however, deeply concerned about issues I've encountered in the RAK-maintain LoRaWAN stack on the RAK4630. Any idea if the RAK3172 version of RUI uses the ST-supplied firmware for the LoRaWAN stack?

Of course, I also appreciate the flexibility that I can relatively easily swap another STM32WLE5 module with minor firmware changes depending on market conditions - and I expect RUI wouldn't have that flexibility.

[TolbyT]

@danak6jq @carlrakwireless May I check which part of the code should I edit if I need to interface to my external sensor?

And do I need to make any changes to the .ioc peripherals if I need to connect via UART to my external sensor?