Support for STM32H503 on Nucleo board

[wjklimek1]

Hi everyone,

I am working on support for STM32H503RB on STM32H503 Nucleo board. I used F4 code as a template. I have a working code that can update application on the microcontroller.

I noticed that despite VTOR being set to BOARD_FLASH_APP_START in board_app_jump(), it is restored to default value by SystemInit() in startup code delivered by ST. I have to manually set VTOR to BOARD_FLASH_APP_START on the beginning of my main() in the app. I did not find any workaround for it without modifying code delivered by ST. It may be worth to mention it somewhere in the documentation to save future developers some debugging.

Another thing to keep in mind it that STM32H5 only supports flash quad-word programming due to embedded ECC. That means that data has to be written to flash in chunks of 128 bits (see AN5342). I don't see any potential problems with that but decieded to mention it in case you are aware of any dangers.

As a family id for STM32H5 i used value 0x4e8f1c5d (already merged to uf2 format repository).

For now only basic app update is supported. Self update and bootloader protection probably can be implemented on this MCU but basic functionality meets my need for now.

Tested functions:

• flash_erase()
• flash_write()

Untested functions:

• board_flash_protect_bootloader()
• board_self_update()

Questions:
1) Should I remove original implementations of self update and bootloader protection moved from F4 as they are not likely to work on H5?
2) What VID/PID pair should be used for STM32H5?

Thanks for your amazing work and effort that you put into maintaining this repo!

[hathach]

thank you very much, this is a really great PR. I don'thave h503nucleo to test with, but I do have h563 nucleo. I am pulling your code, and making some changes to h563 for testing. Hopefully we could merge this soon.

[hathach]

shrink bootloader size, since we got just over 15KB + 1KB for CF2 (config), we will need 24KB. Further optimize code + usb is possible to get it down under 15KB, but that would make it difficult to expand later e.g custom board with lcd/neopixel etc. So 24KB for H503 and 32KB for the rest

LINK _build/stm32h503_nucleo/tinyuf2-stm32h503_nucleo.elf
Memory region         Used Size  Region Size  %age Used
             RAM:        9560 B      32764 B     29.18%
           FLASH:         15 KB        23 KB     65.22%
          CONFIG:          0 GB         1 KB      0.00%

[hathach]

per board flash boot & ram size

[hathach]

your previous value is 0x3, I guess you get it down to 2 sectors. If so we can make this as dynamic value basically: (1 << (boot_size/8k)) - 1

[hathach]

Perfect, thank you very much for the PR. I made some changes, but mostly refactor and abstract thing. This is a great PR, I settle with 24KB for H503, and 32KB for the rest due to how the flash protect bit work. Let me know if this work for you, and/or you want to make any further changes, otherwise we could merge this now.

PS: For the self-update, we can do it later on as follow-up PR.

PSS: Sorry for the delay, I got into issue when adding/testing blinky app, which is caused by system_stm32h5xx.c reset the VTOR table --> causing my systick not blinky. Giving me quite a bit of headache thinking the flashing not working.

[wjklimek1]

Thanks for all work that you have done on this PR. I gave TinyUF2 entire 64kB of flash because I thought it is unified across families. I also had this problem with VTOR and I even mentioned it in PR description.

What about VID/PID pair?

I am a bit busy this week but I hope I will test it again on H503 before weekend.

[hathach]

Thanks for all work that you have done on this PR. I gave TinyUF2 entire 64kB of flash because I thought it is unified across families. I also had this problem with VTOR and I even mentioned it in PR description.

Yeah, I overlook that, and thank to your comment, I am able to fix that. I am having issue with flash protect I think. Since for h563 (what I am testing), 1 bit is a group of 4 sectors, 0x03 is 8 sectors and that is tinyuf2 trying to write to protected flash.

What about VID/PID pair?

I will try to get one from Adafruit for as generic vid/pid for H5 and update this PR.

I am a bit busy this week but I hope I will test it again on H503 before weekend.

No problems, we are all busy, let me know if you couldn't test it out. We can merge and fix later.

[hathach]

PS: PID is being allocated internally

[wjklimek1]

Hi,
I checked bootloader and it works for STM32H305. I also flashed blinky app and self update.

I noticed that stm32h5_app.ld does not utilize entire flash memory available for STM32H503 but I assume end user will modify this anyway for their specific project.

The only thing to add is relevant VID/PID pair but I can't access your link. Are you sure it is accessible?

[hathach]

Hi, I checked bootloader and it works for STM32H305. I also flashed blinky app and self update.

Thank you for testing it out, will merge it

I noticed that stm32h5_app.ld does not utilize entire flash memory available for STM32H503 but I assume end user will modify this anyway for their specific project.

Yeah, I skip the flash_size define since most app here is simple, mostly faactory reset, self-update and blinky for testing. User should write their own code/linker.

The only thing to add is relevant VID/PID pair but I can't access your link. Are you sure it is accessible?

my bad, it is an internal repo for pid, a generic pid for H5 family is allocated. Will update PR and merged. Thank you very much for your great work.