Firmware for the new STM32L412KB based RS41

[videobuff]

The latest recoverd sonde (from the german Bundeswehr) contains the STM32L412KB chip and is a device with Ultra-low-power with FPU Arm Cortex-M4 MCU 80 MHz with 128 Kbytes of Flash memory. Looks the same (bottom one on the picture)
The current firmware RS41ng is written for the STM32F100. And that is an M3 MCU.
Hence you cannot flash it with the current firmware.

Is there already a process to port the current firmware for the new sondes ?

My knowledge is not enough to port the current firmware so I am keen to find out if someone is already on to it.
If needed i could donate one of the new sondes.

Erik

[kd2eat]

Erik, if you happen to get a few spares of the new model and felt like mailing one to the States, let me know. I was involved in the hardware side of the DFM-17 port, and could take a swipe at this too. I just don't have access to one.

[videobuff]

Michael I will do. Please tell me your address where to ship it to. I’ll use DHL or FEDEX. Erik. PA0ESH Verzonden via Gmail Mobile Op vr 17 mei 2024 om 14:23 schreef Mike Hojnowski ***@***.***>

…

Erik, if you happen to get a few spares of the new model and felt like mailing one to the States, let me know. I was involved in the hardware side of the DFM-17 port, and could take a swipe at this too. I just don't have access to one. — Reply to this email directly, view it on GitHub <#92 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAX44GJFDUJV5SRLRHODRWDZCXZEVAVCNFSM6AAAAABH3CEUROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJXGQ4DENJXGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[kd2eat]

Erik, Thanks so much. I emailed my address to your email account listed in QRZ. Let me know, here, if you don't get it. Thanks! Mike / KD2EAT.

[kd2eat]

I've received the sonde from Erik (thanks!). I've done some preliminary research on the processor. This could be in the "Big Deal" category. The processor is an STM32L41R8T6, A few differences from the existing RS41:

CPU speed: 24 mhz vs 80 mhz
SRAM: 8k vs 40k

The processors for both the classic RS41 and the DFM17 were in the "Medium Value Line" according to the HAL defines in the source code. It's not clear that this processor would be. I also haven't researched whether this processor is even supported by the existing HAL code. That will be the next step. It's likely that we'll either (at best) have a different CMAKEFILE for the new RS41, or at worst, deal with a different HAL library that supports it. We may be forced into the STM32CubeMX libraries if there isn't support in the current library.

[KB8RCO]

FYI - We have recently recovered 2 RS-41SG sondes launched from White Lake Michigan. Both have the STM32L412R8T6 chip. All previous recovered sondes had STM32F100C8 chips.

I tried programming it with the current 'docker' process - no luck!

Looking forward to any updates.

Robert Giuliano
KB8RCO

[Nevvman18]

Also recovered 2 new RS41-SGs (RSM414 PCB) and already wrote some firmware for it (RTTY, Horus Binary, most HW support) and done some reverse engineering of it. I'll probably publish it in a couple of weeks on my GitHub.

[pinkavaj]

Anythink else new except the CPU? (GPS, radio ...)? Any other incompatibilities expected?

[Nevvman18]

No, most of the hardware is still the same. The uC is of course different (but better than the previous one, faster, more memory and IOs). The power circuitry was physically rearranged, but LDOs, boost converter and voltage enabling logic stayed the same, so no big difference. The radio is still a nice Si4032 (maybe 2 changes in the final RF stage but no changes in operation) with the same underscaled 26MHz oscillator shared with GPS. The only major difference is the GPS IC - here it is a uBlox M10050-KB, which (apart from a advertising leaflet with 2 pages) doesn't have a thorough datasheet, though in 5 minutes I've figured out by looking at the resistors on the data lines that it is also connected via UART to the uC and sends standard NMEA sentences (also contains data for other constellations like GLONASS and BeiDou, which makes it one of the most accurate embedded GPS chips I've ever owned). The measuring frontend is also nearly identical, with the same ring oscillator circuit, the same SPST and SPDT switches and other things. The rest like XDATA, military SPI flash and expansion connectors are the same, also with a really similar 'dumb' NFC interface.
Of course many of the connections are differently routed because of the new uC, but I reversed most of them (the PCB is still multilayer), and to my surprise, some of them like reference circuit or frontend switches are wired the same (the same naming of pins on the uC), maybe because manufacturer had a little less work with firmware rebuild? Idk.
That's the short writeup for this new sonde but I think that it is even better for experiments and such things than the older model.

[videobuff]

Here in the Netherlands we have stashed a lot of the new sondes as they stopped using the old ones both in The Netherlands as well as in Germany. (i can collect from three launchsites in NL and GE). Looking forward to Nevvman18's firmware and i have setup two new ones for testing as soon as the firmware comes available. I sent one new sonde to KD2EAT but summer stopped all progress until now.

[Latitut]

Didn't expect such a reaction, doing my best to publish the repo with fw and a write up as soon as possible, tho probably it will be ready to publish in the middle of the september I think.
edit: sorry, wrote from second account for dev purposes

[videobuff]

No problem. We are flying a lot of amateur balloons in Holland (up to 10 in a week and some are recovered, and some are not. So the stock dwindels ......But somewhere september would be wonderfull. Thanks in advance.
Erik

[kd2eat]

Yea, summer ate all my spare time. I mapped a few pins and reviewed things. The question I haven't answered for myself yet is whether the existing HAL libraries in RS41ng will work with the new MCU, or whether we need to swap out the HAL layer. That's where I got before summertime chewed up my spare hours.

[Nevvman18]

I have already done like a half of the work needed to publish the new firmware, so it will be there faster than I thought

[Nevvman18]

https://github.com/Nevvman18/rs41-nfw

This is the new firmware repo, probably everything is done for this initial release.
Done what I could to provide you with this and seems that it went faster than I thought for the first time.
Read the manual carefuly, try the firmware and tell me what do you think about this.

[K4KDR]

Thanks for all the work done to identify these new models and to create code for us to use them!

I see the tech notes and the pictures at the top of this issue, but in summary, what is the most obviously or straight-forward way to identify what model you have in-hand? Thanks!

[Nevvman18]

The method is shown in the hardware description of my project

The easiest way is to open the sonde and look for the PCB model. It is located on the rear lower part of the board, somewhere near the NFC coil (the part with rectangle-like lines). It should start with something like RSM... and if this text ends with number 4 you have the new probably ~2023 revision model.

In my repo there is a detailed guide about basically everything on the new sonde. If the model number isn't there, you can try to compare your board with the photos in there.

To be 100% sure about the firmware compatibility, you can read the microcontroller markings which should be "STM32L412" with something at the end, tho I didn't observe anything newer than this model, so this verification isn't needed.

Best
Franek

[K4KDR]

Outstanding - thanks!!

[KB8RCO]

Personally, I found the light color print on the green board hard to read.
I found it easy to identify because the chip is larger, and the writing is clearer.
Remove the battery holder and even my poor eyesight could read the STM32L412RBT6 (other than the B looks similar to an 8).
So, the 2 sondes I have recovered recently are 'RB', not 'KB'. I just downloaded the datasheet to find differences.

[Nevvman18]

Yeah correct, all new sondes have STM32L412RBT6 as mentioned in my docs. There seems to be an incorrectly typed issue name here. The last characters mean memory, package and IOs config.

[kd2eat]

So, I did a little research tonight. RS41ng appears to be using the "Standard Periperal Library" HAL drivers for the STM32F10x processor. The shortest path to victory would be to get the Standard Peripheral version for the STM32L4 processor on the newer sondes, and modify the code to use one or the other, based on an ifdef for the processor type. Unfortunately, STM doesn't offer the Standard Library for the STM32L4 line.

There IS a STM32Cube version of HAL libraries for both processor types. If RS41ng was based on the Cube HAL library, then it would be a tad easier to port the code and switch between the two different CUBE HAL libraries, since the calls would be virtually identical. Unfortunately, the Standard Peripheral Library calls and CUBE calls are quite different.

It seems like the "best" way to do this would be to port the whole thing over to the CUBE Hal library, and then make the mods necessary to support either the F1 or L4 processors with a few well placed IFDEFs. This is a big undertaking. Bummer.

It's really up to Mikael. I'm willing to help if he decides to switch to the Cube HAL layer, but that's not the kind of change I would just make and throw into a PR.

[kd2eat]

Oh, here's the compabilility graph from http://www.yahboom.net/public/upload/upload-html/1701776660/Introduction%20to%20HAL%20library%20and%20LL%20library.html

The print is pretty small, but the last column is the L4 line of processors.

[kd2eat]

Hmm. Doing a bit more research, maybe there IS a possibly easier migraiton path. The STM32Cube LL (low level) has some "compatible APIs". I'm not clear what all that means. There is some documentation here: https://www.st.com/content/ccc/resource/sales_and_marketing/presentation/product_presentation/37/55/ff/bc/a8/71/4f/c5/stm32_embedded_software_offering.pdf/files/stm32_embedded_software_offering.pdf/jcr:content/translations/en.stm32_embedded_software_offering.pdf

So, they claim "LL API: functionally equivalent functions vs SPL peripheral initialization functions"

I'll download a copy of the LL API libraries and look around a bit.