In this PR we address the STM32H7 support being broken in a few different ways, and formalise the support for the H72x and H73x parts.
While trying to use the support for a project that's been going on, we ran into issues first with trying to Flash parts, resulting in this sequence:
stm32h7_flash_cr: patching FLASH_CR from 0x00000034 to 0x00000034
Erasing, ctrl = 00000034 status = 00000005
stm32h7_flash_cr: patching FLASH_CR from 0x00000030 to 0x00000030
stm32h7_flash_busy_wait: error status 00250000
Write failed at 8002790
stm32h7_flash_cr: patching FLASH_CR from 0x00000030 to 0x00000030
stm32h7_flash_busy_wait: error status 00250000
This is caused by the Flash writes not respecting the datasheet's 32 byte blocks point and trying to blast data at the Flash like other ST parts. This does not work on the H7 series.
The Flash map for the H72x/H73x parts was lacking/wrong, which is addressed by the changes in the probe routine. The Flash write parallelism handling was a mess and convoluted, we've simplified it as it's a target-level parameter to the operation of the device. The Flash controller ACR value is also properly set from reset, so as messing with that was also screwing up operation of the controller, this has been dropped and the Flash routines refactored and upgraded to take proper advantage of the current target Flash API. This also fixes blank chip handling when the device has tried executing from empty Flash - this causes a double fault in the Flash controller which was not being handled properly by the Flash operations checking routine.
WDT handling was also borked, along with a memory leak in attach caused by the allocation of the target private structure at that point, and its being overwritten in the target structure without checking if an existing valid pointer is present.
Finally, scanning for the H7 over JTAG was broken due to the differences between SWD and JTAG part identification on ST's parts, necessitating the use of ap->partno for the identity checks.
Detailed description
In this PR we address the STM32H7 support being broken in a few different ways, and formalise the support for the H72x and H73x parts.
While trying to use the support for a project that's been going on, we ran into issues first with trying to Flash parts, resulting in this sequence:
This is caused by the Flash writes not respecting the datasheet's 32 byte blocks point and trying to blast data at the Flash like other ST parts. This does not work on the H7 series.
The Flash map for the H72x/H73x parts was lacking/wrong, which is addressed by the changes in the probe routine. The Flash write parallelism handling was a mess and convoluted, we've simplified it as it's a target-level parameter to the operation of the device. The Flash controller ACR value is also properly set from reset, so as messing with that was also screwing up operation of the controller, this has been dropped and the Flash routines refactored and upgraded to take proper advantage of the current target Flash API. This also fixes blank chip handling when the device has tried executing from empty Flash - this causes a double fault in the Flash controller which was not being handled properly by the Flash operations checking routine.
WDT handling was also borked, along with a memory leak in
attachcaused by the allocation of the target private structure at that point, and its being overwritten in the target structure without checking if an existing valid pointer is present.Finally, scanning for the H7 over JTAG was broken due to the differences between SWD and JTAG part identification on ST's parts, necessitating the use of
ap->partnofor the identity checks.Your checklist for this pull request
Closing issues