Add reversible flashing r9*

[TilCreator]

I tried myself on flashing a r9m tx module with just a opentx remote, or rather like elrs is doing.

What I found out:

• fkr files are bin files with a header that can be used for flashing an app (not bootloader), this works with the original and the elrs bootloader. The files have a 16byte header that is detected by opentx and the app in binary. (This pr adds a modified version of the elrs script)
• elrs files are bin files without a header that also can be used for flashing an app, this only works with the elrs bootloader.
• The elrs bootloader is flashed by using an app that overrides the bootloader on first startup.
• I don't know what exactly is different between the two bootloaders (appart from the elrs files), but one is opensource https://github.com/ExpressLRS/ExpressLRS/tree/master/src/bootloader/src so that one should probably be prefered.

It sadly doesn't just work to convert the mlrs hex file to a bin file and then to a frk or elrs file, I guess because the mlrs hex file also includes a bootloader (and maybe other offsets are wrong). I think the preferred way is to use the eLRS bootloader and provide elrs files that only include the app. I have no clue on how the use the stm32cubemx software, so it would be nice if someone could help me with building an app only bin file.

[olliw42]

@TilCreator hey first off, very cool you are looking at this! I must admit I'm not sure I can quite follow what you are saying, but I can comment on this:

I guess because the mlrs hex file also includes a bootloader (and maybe other offsets are wrong).

it does not include any bootloader nor moves the vector tables nor does any offsets etc. That's good for flashing if there is no extra bootloader flashed (i.e. only the system bootloader is available). If a bootloader is flashed, then the mLRS code needs to be modified in few ways. Since this isn't been done, it cannot be started from a diffreent flash location. I.e.: alslo the mLRS code needs to be modified, only converting it from one format to another won't make it work. Not sure that's helpful.

[TilCreator]

I knew it would be very naive of me to just convert the files, your comment is helpful indeed. I'm sadly still stuck, because I'm not familiar with the build system of this project (I also was unable to get the IDE running easily). From looking at the elrs build files the vector table offset is 0x4000.

All build flags: build flags: ['-D PLATFORM_STM32=1', '-Wl,-Map,"\'${BUILD_DIR}/firmware.map\'"', '-O2', '-I ${PROJECTSRC_DIR}/hal', '-D __FILE__=\'""\'', '-Wno-builtin-macro-redefined', '-DRADIO_SX127X=1', '-DTARGET_TX=1 -Wall -Iinclude', '-include target/Frsky_TX_R9M_LITE.h', '-flto', '-D HSE_VALUE=12000000U', '-DVECT_TAB_OFFSET=0x4000U', '-DRegulatory_Domain_EU_868', '-DLOCK_ON_FIRST_CONNECTION', '-DUART_INVERTED', '-DAUTO_WIFI_ON_INTERVAL=60', '-DLATEST_COMMIT=56,97,97,49,98,48', '-DLATEST_VERSION=51,46,48,46,48', '-DTARGET_NAME=FRSKY_TX_R9M_LITE']

[olliw42]

I also was unable to get the IDE running easily

sad to hear this. Someone in the rcgroups therad just recently said it went smooth for him, so I was hoping this has become suffciently easy, but apparemtly not. May I ask what is causing you troubles?

I agree that STM32CubeIde is not the best tool for such a project ... but it's all I could handle at the point in time. But maybe we at least can make it ok via documentation.

vector table offset is 0x4000.

yeah, saw this too, that vect table is at 0x4000 ... which is somewhat shocking, given that this is 16K, and flash is only 64k ... huge bootloader

with CubeIDE, it seems one has to set it by hand in here: https://github.com/olliw42/mLRS/blob/main/mLRS/tx-R9M-f103c8/Core/Src/system_stm32f1xx.c#L99-L114. But I think one also will have to adapt the linker script, probably here https://github.com/olliw42/mLRS/blob/main/mLRS/tx-R9M-f103c8/STM32F103C8TX_FLASH.ld#L49. Not sure if there is a more convenient way to do that.

[TilCreator]

My troubles are rather minor, it's not in the nixpkgs repo (I'm on NixOS) and just personal dislike of the proprietary software, it having an installer and requiring contact information to get it... So in short I just don't accept the user agreement of the software.

[olliw42]

I just don't accept the user agreement of the software.

very understandably, I remember I too had initially mixed feelings about this registration attitude

[TilCreator]

thx for understanding, I hope I can still help with the project.

[olliw42]

@TilCreator so, I thought let's just modify the linker script to leave room of 16K ... and it fails !!! The code for R9M is already larger than 48K and doesn't then fit anymore !!! arghhh

1. I didn't realize we are already that close on the F103's LOL
2. It would be a hard time to work out ways which cuts code down to below 48K ... this elrs bootloader idea won't ever work?

[TilCreator]

I don't know if there is a way of flashing something that is bigger than the remaining space with the boot loader and even if that is possible that would overwrite the boot loader, so all functionality of the boot loader would need to be implemented. So I guess best we can do is implementing some way to update the firmware without using a programmer, but without the elrs boot loader?

[TilCreator]

Also I will flash my tx and rx modules in a few days.

[olliw42]

So I guess best we can do is implementing some way to update the firmware without using a programmer, but without the elrs boot loader?

technically this is possible using the system bootloader on uart1. It is exposed as the serial port on the R9M. So, one would need a "frsky inverter" and then could do the native STM32 system bootloader upload procedure.

That's actually the grander plan for mLRS for flashing, to use the system bootloader. The uart used for the com/cli is supposed to be a system bootloader capable uart. Then it is possible to add code which allows to send a command through thr com/cli which programatically starts the system bootloader (this is to avoid having to fool with BOOT0), and to then use a flasher to flash. I use that concept in the STorM32 gimbal controller project, and it works great. What it would need however to make it easy for the user is a sort of gui or app ... However, someone would have to develop (and maintain) that gui/app. For as long as this is not happening (if it ever happens), I guess we are stuck to SWD.

[olliw42]

Also I will flash my tx and rx modules in a few days.

great. looking forward to hear how it goes for you. you may then want to join the rcgroups thread or discord channel :)

[TilCreator]

Would it be possible to use the frk or elrs flashing mechanism to flash a small app that starts the system bootloader in flashing mode and allow flashing over the uart that way? Also do you know by any chance what pins of the stm32 are used for the uart? I don't have an inverter and would rather just solder to the stm32 or some other component near it. (I'm aware of the 3.3v logic level)

[olliw42]

Would it be possible to use the frk or elrs flashing mechanism to flash a small app that starts the system bootloader in flashing mode and allow flashing over the uart that way?

technically, yes I am not convinced it's easier and it would work just once, i.e., how are you going to flash if you want to flash a new version?

Also do you know by any chance what pins of the stm32 are used for the uart? I don't have an inverter and would rather just solder to the stm32 or some other component near it. (I'm aware of the 3.3v logic level)

from the hal file one finds UARTB_USE_UART1, so uart1 from the f103cb datsheet (in the docs folder) one finds uart1 = Pa9,Pa10 = pins 30,31

I couldn't find easy to solder to points, sadly, so delicate soldering on small pins