Hello I have serious problem with the download of my application in a STM32F765IGT. We need absolutely a full erase of the chip to be able to program it. This is not an acceptable way to do for us since the 4 first sectors has saved data in it.
I saw in the FLASH folder of the package different flash algorithm especially some related to dual bank microcontroller. My STM32F765IGT is 1 Mb but still support dual bank if we want. I am guessing it is where the problem relies.
Anyone were able to do a erase sector only on those microcontroller version?
Regards,
Hello Clive,
I have routed down the problem and the STM32F765IGT has 1Mb flash size AND support dual-bank feature. Keil uVision5 5.21 doesn't program correctly the option bytes for a F7 1Mb and dual bank feature. The bit nDualBoot and nDualBank are always set to '0' which is enabling both functionality and my sector 5 address is set to 0x0802000 instead of 0x0804000.
The erasesector(5) erases wrong sector and it program on the good sector which brings plenty on mismatch values on verify, totally normal...
For some reason they are using the same flash algorithm has other F7 not supporting dual-bank.
My workaround is to use an old STM32F4Discovery for his ST-Link with ST-Link Utility application to set correctly the option bytes. Afterward, I can use my U-Link Pro to flash my application and debug without any problem.
I still have to try to program the option bytes in my application like you said but it should work since the version 2.8 of the STM32F7 package handle the 2 new bits in option bytes.
I have sent case support to keil to see if they can provide me with a new FLM file which support it. I would modify it but the file isn't in ascii so I prefer not to try it.
Do you know how I can tell uVision5 to use a specific FLM file? I know I can add a flash programming algorithm through Target driver setup but the 2Mb dual-bank flash algorithm are not showing up..
Thank you!
Historically Keil has provided source code for the flashing algorithms. And then indexes them out of the ARM\Flash directory. Not sure if there is a trick to re-index them.
I suspect the dual bank 512K+512K is a bit of a hack, as the primary die is for 1024K+1024K.
Like I said, become familiar with the programming and erasure of the flash from your own application space and apply that know-how to the current versions. The flash algorithms are just ARM code compiled to load/run in the SRAM of the target micro, and mitigate access to the flash and/or options bytes. You'd edit the source and rebuild, not patch the binary files. The methodology allows for you to use custom memory chips on custom boards, without involving Keil in the development.
If Keil doesn't fix it via a support ticket you'll have to DIY.
I didn't know that. So what you tell me is that I should find somewhere in the pack folders the flash source for each type of CPU? Then I could patch it there, rebuild , rename it to xxx.FLM and use this one?
Great thank you I will look into it.
Keaven
Clive could you help me out to find the project for the programming algorithm? I do not find it in my Keil_v5 folders.
Thank you
I answered myself. I put the link I have found to help creating a new algorithm here for others who get in the same problem
www.keil.com/.../ulink2_su_newalgorithms.htm