STM32H750 Rev V program error Keil ARMCC (Rev Y works)
Hi, I have about half year experience now with STM32H750 hardware, and all working very nice now. Up to now I always had used Revsion Y chips.
Now on the last order we got Revision V chips (LQFP100 housing, chip marking line 1: "STM32H750", line 2: "VBT6 V", line 3: "VB454 VQ", line 4: "PHL 7B 944"). ... with this chip I cannot connect any more with Keil ArmCC (I must admit older 32bit Version of Keil ARMCC V5...).
ST-Link with the new Rev V works ok: After connect it shows "Device: STM32H7xx, Device ID: 0x450, Revision ID: Rev Y, Flash size 2MBytes".
(2MBytes is wrong, it really should say here 128kB).
If I connect the new "Rev V" STM32H750 device, then for Revision ID, ST-LINK gives the message "Unknown" (it should say "Rev V" here I assume).
I tried already ST-Link Firmware update, this seems to work nicely (I use some older "STM32F401 Discovery board" for ST-LINK Hardware connection.
Can somebody give me a hint how to update ST-LINK such, that "Rev V" will show correctly after connect? (I hope that then also Keil will connect correctly).
In ST-LINK with Rev Y Connect and "Program&Verify" works nicely, just "Erase chip" does NOT work (-> Error "Error occurred during flash mass erase).
I assume that this might be due to wrong "Flash size" info of 2Mbytes in ST-LINK.
...
PS: Possibly Rev V really somehow needs some different programming algorithm compared to Rev Y?
When I start debugger in Keil ARMCC with my standard setting "Erase sectors + Program + Verify", then Erasing + Programming first seems to work "as normal", but there appear "Verify errors" for the ranges 0x80000040...0x8000007F, and 0x800000A0...0x800000DF, and so on. In these ranges Keil gives the message, that Chip shows "ff", so it did NOT program. If I open STLINK and connect, I really see the same in the memory image of STLINK: On this start range of the program, there should come the interrupt table I think. 8-16 of such 32-bit Adress values seem to be programmed correctly, and then the next 8-16 adress values are still at 0xFFFFFFFF ... so NOT programmed at all... .
