Getting chip ID using DFU bootloader

[kinovicf]

Posted on August 21, 2012 at 21:33

Hello.

I have a question about getting chip ID (like 0x0411=STM32F2xx) using buil-in DFU bootloader (USB). There is command get ID in USART protocol, but I don't find equivalent command in DFU protocol. I found only information about flash organization in interface descriptor. Is is possible to read chip ID using DFU bootloader? Thanks. #chip-id-dfu-bootloader

[stforum.tormod9]

Posted on August 25, 2012 at 13:09

I don't think there is an equivalent command in the DFU (DfuSe) protocol, at least not that I have seen documented.

From looking at https://github.com/texane/stlink/blob/master/src/stlink-common.c#L396 maybe you can try reading out the 2 bytes fro

m 0xE0042000 over DFU? On my STM32F103 it just reads zeroes, but

it might work on F2xx. Otherwise you  can read out the USART boot loader code over DFU and analyze where it finds the chip ID... Tormod

[kinovicf]

Posted on August 27, 2012 at 16:11

Thanks Tormod.

I wasn't succesfull reading chip id from location 0xE0042000 through DFU bootloader. I always get status error errTarget and zero or nonsence data (similary for reading of RAM locations). I got error errVendor when read protection was enabled. Does anybody have similar experiences? I tried to read above location through ST-LINK and I got 0x20016411, where 0x411 matches STM32F2xx. It works for st-link even when read protection is enabled (it is way how st-link do it). I think that analyzing USART bootloader will not be helpfull, because bootloader do it from its code and I will not be possible to do it through DFU bootloader. I don't understand why are such differences in built-in bootloader protocols. nelup

[stforum.tormod9]

Posted on August 27, 2012 at 21:41

OK, I guess the bootloader checks the addresses and refuses to read out from RAM and ROM then. ST's IAP versions don't, and I had thought they were pretty close to the ROM implementations.

Yeah, my suggestion to study the USART code was for figuring out from which location it reads the chip ID, but that is likely from 0xE0042000 then and you cannot read it out anyway apparently. ST's DfuSe USB bootloader seems like a strange mix of their USART loader and the official DFU protocol. Too far from DFU to be interoperable yet enough to cripple any attempt at USART compatibility. For possible DFU_UPLOAD requests (to get information from the bootloader), they reserved wValue=0 for the GET command and wValue=1 for unknown/future use. Has anyone tried the latter on these beasts? Does GET return anything else than the 4 bytes described in AN3156?