[Beta] Jump to system memory boot from user application

[fpistm]

This PR add support of automatically jump to system memory bootloader.

Currently, this is trigger only thanks a Serial over USB (USB CDC have to be enabled). By setting the port at 1200 speed this request the restart by setting a magic number (0x515B) in a backup register then require a system reset. Then when restart, this value is checked and jump is performed if match to go in bootloader mode.

STM32 Cube programmer scripts is currently under update. See https://github.com/stm32duino/Arduino_Tools/pull/44

Tested under Linux:

• F3:
  • BlackPill F303CC
• F4:
  • Black F407VE
  • Nucleo F401RE
• L4:
  • SensorTile Box (L4)
• WB:
  • P-Nucleo WB55RG --> Reset in BL mode OK, programming start properly but failed. `Cube Programmer issue, not related to this PR.

Under Windows manually set speed at 1200 works as expected. Script under update.

Fixes #706

[stas2z]

Woohoo, it realy works) but i failed resetting it by 1200 baud and added simple mapple style reset (if "leaf" trigger recieved) so now it resets and uploads flawlessly using mapple's upload-reset and cubeprog in dfu mode after :) p.s. tested it with F401

[fpistm]

@stas2z It should be fine to find why it is not reset setting 1200. Did you try manually without upload scripts?

[stas2z]

@stas2z It should be fine to find why it is not reset setting 1200. Did you try manually without upload scripts?

yes, ive tried to connect with arduino terminal using 1200 baudrate and also with putty, ive uploaded a simple echo fw to it and it works as expected at 1200 without reset

[fpistm]

I've just tested with a Nucleo-F401RE and a USB shield and this work fine... You set the USB CDC port at 1200 not an HardwareSerial port ?

[stas2z]

I've just tested with a Nucleo-F401RE and a USB shield and this work fine... You set the USB CDC port at 1200 not an HardwareSerial port ?

yes, sure im using connection to ttyACM0 as my device appeared in dmesg (blackpill F401CC)

[fpistm]

Could you try with (several time if needed): stty -F /dev/ttyACM0 1200

[stas2z]

stty -F /dev/ttyACM0 1200

No, its not working for my board

Also i found a problem i got when i tried to implement it by myself, it just reboots without entering a bootloader if any gpio pin initialized, just make pinMode for builtin led and it will stop loading boot.

resolved it by adding following code before remapping and jump to boot

    HAL_RCC_DeInit();
SysTick->CTRL = 0;
SysTick->LOAD = 0;
SysTick->VAL = 0;
__HAL_RCC_SYSCLK_CONFIG(RCC_SYSCLKSOURCE_HSE);
__HAL_RCC_SYSCFG_CLK_ENABLE();

[fpistm]

In fact I used the backup register to ensure having original config and no feature configured. I'm surprise to see HSE in your code as it should be HSI.

[stas2z]

In fact I used the backup register to ensure having original config and no feature configured. I'm surprise to see HSE in your code as it should be HSI.

Ok, it's my fault, HSI is also works and seems like will be better.

But it's not important, cuz SysTick reg values reset do the magic. Reiniting RCC i found by googling, but in my case it can be skipped.

Also ive tried reset by 1200 baud my another F4 board (black F407VE), and still no luck (maple reset works flawlessly), probably problem on my side, will try to find what i did wrong while i appleid this pull request to my local repo copy

[fpistm]

Ok. In fact I've made the minimum to work. Resetting systick an RCC could be added, I guess. Maybe also HAL_DeInit as it is init for backup access.

[stas2z]

Ok. In fact I've made the minimum to work. Resetting systick an RCC could be added, I guess. Maybe also HAL_DeInit as it is init for backup access.

Anyway, it works already, for me at least :) reset procedure is not so important, also usb is not only way to use it, cuz im going silently update slave devices built with chips with only serial dfu supported, so bootloader reboot requests can be implemented as hwserial commands or gpio pins.

[fpistm]

Right, this is not only for USB.

[stas2z]

its weird, but 1200 baud reset working under windows for me, without rebuilding but for linux it's not, even with sudo (any terminal app works fine, but 1200 baudrate reset not)

[fpistm]

which Linux OS do you used?

[stas2z]

which Linux OS do you used?

mint 19.2 (ubuntu 18.04 based)

[fpistm]

Ok, I'v tested on 14.04 and 16.04 anyway this should be the same or a usb driver issue as the speed is not relevant for this kind of device

[stas2z]

Ok, I'v tested on 14.04 and 16.04 anyway this should be the same or a usb driver issue as the speed is not relevant for this kind of device

Seems like it was a usb driver glitch, ive rebooted back to linux and everything works as it should, sorry for this inconvinience

[fpistm]

OK so now it is fine on Windows and Linux ?

[stas2z]

@fpistm yep, both

[stas2z]

Good news, Ive successfully rebooted stm32f051c8t6 to bootloader mode using this PR. Will check stm32f030c8t6 a bit later.

[ladyada]

i 'tested' this with windows by manually opening the port at 1200 which did in fact kick into the DFU bootloader! then i uploaded. so we need an update to the tool, like linux has, and it should work. @fpistm im not great at bat files but i could try making the change

[fpistm]

OK thanks @ladyada for the feedback. I will update it on monday.

[stas2z]

@fpistm I found very funny and strange issue, testing bl reboot I own two identical boards, one with f051 and one with f030, both c8t6 F051 works fine with test fw, boots to bl and fw flashing via serial F030 just reboots. I found both chips share the same 0x440 id (detected by cubeprog) Ive tried to upload f051 fw to f030 and it works like a charm, inits, gpio, serial and boot to bl ofcourse. But if i change compile option to -DSTM32F030x8 it break the bl boot (clocks are inited the same, using cubemx init code, also ive tried other f030 variants and different configs with hsi and hse, no change, building it as f030 breaks bl boot)

upd: i found an issue, thanks to gdb ENABLE_BACKUP_SUPPORT is disabled for f030 and enabled for f051 so getBackupRegister returns 0 for 030 its funny, but seems like at least mine f030 have that registers, but cmsis doesn't allow me to use it

ive made simple changes to cmsis header to make it work probably if someone will find this post by googling it'll be helpful to post changes here https://pastebin.com/raw/DDKq2jdX

[fpistm]

Maybe I've made an error in the backup.h definition. I will check that

[stas2z]

Maybe I've made an error in the backup.h definition. I will check that

No, everything is right, cmsis f030x8 header doesnt contains rtc bkp defs at all

[fpistm]

Refering to reference manual f030c8 does not have backup register, so cmsis are well defined. This PR is a beta, it is a first implementation. This can be extend to series which does not support bkp registers and also some series which are different like F7 and H7.

[stas2z]

@fpistm yep, but it actually have it 😁 seems like 051 and 030 are the same inside, at least that i have, will check if tim2 is working for 030 (cuz it "doesnt have" it according to ref manual too)

upd: yep, TIM2 is working for f030c8t6 using binary compiled for f051c8t6

[matthijskooijman]

i 'tested' this with windows by manually opening the port at 1200 which did in fact kick into the DFU bootloader! then i uploaded. so we need an update to the tool, like linux has, and it should work.

Is this even needed? I think the Arduino IDE has this 1200bps reset built in and can be triggered from boards.txt. e.g. https://github.com/arduino/ArduinoCore-avr/blob/c8d6aef6d9331af1ec8dea6f78b4e43174cdb55d/boards.txt#L298

Or is there a reason this cannot be used?

Additionally, I noticed that the DFU specification also specifies an USB descriptor for devices that can switch into DFU mode, as well as a standardized request for a device to actually switch into DFU mode. It also seems that dfu-util supports this command for switching into DFU mode (at least it allows specifying an USB id for the device in runtime mode, so I assume it then allows switching into DFU mode).

Did you consider using this command instead of (or in addition to) the 1200baud reset? It seems like a more standard way to approach this?

[fpistm]

Is this even needed? I think the Arduino IDE has this 1200bps reset built in and can be triggered from boards.txt. e.g. https://github.com/arduino/ArduinoCore-avr/blob/c8d6aef6d9331af1ec8dea6f78b4e43174cdb55d/boards.txt#L298

Or is there a reason this cannot be used?

Don't know this and seems not documented. Any input are welcome. This is a Beta PR which require some more enhancement and test.

Additionally, I noticed that the DFU specification also specifies an USB descriptor for devices that can switch into DFU mode, as well as a standardized request for a device to actually switch into DFU mode. It also seems that dfu-util supports this command for switching into DFU mode (at least it allows specifying an USB id for the device in runtime mode, so I assume it then allows switching into DFU mode).

Did you consider using this command instead of (or in addition to) the 1200baud reset? It seems like a more standard way to approach this?

Same here any input are welcome 😉

[ladyada]

the use-1200-touch is a good idea for the second point, i think there are not many usb endpoints available - the current method should be reliable and saves USB work :)