Support for STM32H503 on Nucleo board #419
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
Untested functions:
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!