This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Download Problem with STM32F765IGT.

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,

Parents
  • 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.

Reply
  • 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.

Children