Today is the year of 2024. STM32CubeProgrammer fails to report correct flash size of STM32F767ZG

[arro239]

expected: tools report 1Mb flash
actual result: tools report 2Mb

 note wrong in bottom-right corner

  12:06:56 : STM32CubeProgrammer API v2.17.0 | Windows-64Bits 
  12:07:04 : UR connection mode is defined with the HWrst reset mode
  12:07:05 : USB speed   : Full Speed (12MBit/s)
  12:07:05 : Manuf. ID   : STMicroelectronics
  12:07:05 : Product ID  : STM32  BOOTLOADER
  12:07:05 : SN          : 20663077464B
  12:07:05 : DFU protocol: 1.1
  12:07:05 : Board       : --
  12:07:05 : Device ID   : 0x0451
  12:07:05 : UPLOADING OPTION BYTES DATA ...
  12:07:05 :   Bank          : 0x00
  12:07:05 :   Address       : 0x1fff0000
  12:07:05 :   Size          : 44 Bytes

 

[TDK]

I don't think DFU queries the chip at all to determine this, hence the "default". Does it show correctly with an SWD interface?
Is this breaking anything?

[STOne-32]

Hi @arro239 ,

Try to read STM32F75xxx and STM32F74xxx advanced Arm®-based 32-bit MCUs - Reference manual   The Flash register size @1FF0 F442 .

USB DFU protocol inside STM32 boo-loader can not read that address so the Cube Programmer is guessing it using the superset device flash size.

Hope it helps.

STOne-32

[arro239]

If you guys _knowingly_ guess please consider making this more obvious. For instance please consider stating "Unknown" or "1/2mb" or something along these lines.

I am really concerned by the official guessing. See my other posting regarding way more critical defects hopefully it's not the same guessing in those other cases.

[STOne-32]

Hi @arro239 ,

We appreciate this feedback, but please let us know if you are able to connect via SWD instead of Bootloader DFU or not possible to do by your hardware. This is to understand if the Register size is showing 2MBytes or 1Mbytes, we have seen that in the past and can be a quality issue . So we wanted to be sure before escalating to our CubeProgrammer developpers on how to enhance that in future.   Thanks again for the valuable feedback.

Cheers,

STOne-32.

[arro239]

SWD shows 1MB as expected. Hopefully this would help remove the confusion which is caused by DFU guessing instead of officially stating inability to identify. Again, see my other defect reports I wonder if those are also a consequence of guessing instead of requesting additional user input.

[arro239]

PS: note how "Bootloader Version" shows "--" while using DFU, should same "--" be reported as flash size while in DFU for this chip?

[STOne-32]

Hi @arro239 ,

Very clear and thank you.  we will process that with other threads and back to you the soonest. we logged that in our internal tracking system using this #187869.

Cheers,

STOne-32.

[Tesla DeLorean]

All the Die have 2MB fabbed, they test half and store that number in the 0x1FF0F442 location. This doubles the through-put of the tested, and allows from price stratification via different SKU

The STM32 Cube Programmer reads that via the SWD/JTAG interface, the DFU boot loader in ROM, doesn't change the reported memory size descriptors sent via USB.

[STOne-32]

Dear @Tesla DeLorean ,

Indeed “ the DFU boot loader in ROM, doesn't change the reported memory size descriptors sent via USB”,

Bootloader is not reporting the right descriptors reflecting the current memory size and configuration and so we are in such situation where the CubeProgrammer is only guessing that or any other Software GUI by the way . It should be reported in our AN2606 as USB DFU known limitation on this case . Thanks for the understanding.

Cheers,

ST1