2024-07-31 08:16 AM
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
2024-07-31 09:43 AM
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?
2024-07-31 10:31 AM
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
2024-07-31 10:41 AM
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.
2024-07-31 11:16 AM
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.
2024-07-31 11:25 AM
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.
2024-07-31 11:26 AM
PS: note how "Bootloader Version" shows "--" while using DFU, should same "--" be reported as flash size while in DFU for this chip?
2024-07-31 11:33 AM
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.
2024-07-31 01:22 PM - edited 2024-07-31 01:36 PM
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.
2024-07-31 01:29 PM
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