UART Bootloader returning wrong Device ID

[TPryn]

Hi

i have a product which is using an stm32f070c6 as a co-processor, next to the main processor running linux.

For field updates of the co-processor we are using boot0 and reset pins to get the stm32f07 into the uart bootloader, and then we load the new hex file using the stm32flash tool.

Initially we had an issue with the stm32f07 devices we had, since they were an older date code, and had an issue in the bootloader code, making UART bootloader unusable.

The devices with date codes newer than 818 has been working for us with no problem.

AND HERE IS MY ISSUE. Now i have gotten a shipment of devices with a datecode of 013 (made week 13, 2020), and they are acting up. The stm32flash tool gets the "Device IP" from the bootloader, and uses that to determine flash addresses and such. Well these 013 chips i have return device id 0x0445 (STM32F042xx), which then fails during the flashing process, since the address ranges are different on the two cpus.

stm32flash -w firmware.hex -v -g 0x0 /dev/ttyS0
stm32flash 0.4
 
http://stm32flash.googlecode.com/
 
Using Parser : Intel HEX
Interface serial_posix: 57600 8E1
Version      : 0x31
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0445 (STM32F042xx)
- RAM        : 6KiB  (6144b reserved by bootloader)
- Flash      : 32KiB (sector size: 4x1024)
- Option RAM : 16b
- System RAM : 13KiB
Write to memory
Erasing memory
Wrote and verified address 0x08008000 (40.50%) Done.
 
Starting execution at address 0x08000000... Failed to read ACK byte
failed.

Flashing with an external debugger (ST link), works fine.

Nothing has changed in the system og the application hex file.

Any ideas, og have anyone experienced this?

[Uwe Bonnes]

Could it be that you have received re-labeled devices? Post a close-up photo of the chip marking. Did you get the devices from a reputable source?

[Tesla DeLorean]

According to the actual Reference Manual, and not some third-party tools, the 0x445 code looks to consistent with a STM32F070x6 Rev A part

https://www.st.com/resource/en/reference_manual/dm00091010-stm32f030x4x6x8xc-and-stm32f070x6xb-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

[TPryn]

I see.

I had been looking for a table of all device IDs, but couldn't find it and then i guess i forgot about it.

Thank you, that explains my issue.

Sadly doesn't fix it though :(

[TPryn]

Turns out, the tool is not wrong.

0x445 is the device id for BOTH STM32F04x and STM32F070x6.

That seems stupid...

[Uwe Bonnes]

If ChipIDs are the same, the same die is used, same flash and RAM and peroipherals etched into silicon. Only testing may be differents and peripherals/flash inhibited during test. RM0091 should get an update!

[TPryn]

As it says in my above answer, the whip was returning the right ID.

In my case it was the same die but a different version of the chip (with less flash).

We stupidly didnt notice before we got a different set of eyes on it.