Unknown chip id 0!

[bryanmonti]

• Programmer/board type: e.g Stlink/v1, Stlink/v2, Stlink/v2-onboard
• Programmer firmware version: e.g STSW-LINK007 2.27.15 -> Unknown
• Operating system: e.g Linux, Mac OS X, Windows (with specific version) -> macOS 10.11.6
• Stlink tools version and/or git commit hash: e.g v1.1.0/git-c722056 -> v1.3.1
• Stlink commandline tool name: e.g st-info, st-flash, st-util-> st-flash
• Target chip (and optional board): e.g STM32F402VG (STM32Fxxx Discovery) -> STM32F405
  -- This is a custom board, possible there is a design error but would like to confirm here first.

Output:

st-flash --reset write main.bin 0x08000000
st-flash 1.3.1
2017-07-18T16:56:28 INFO src/common.c: Loading device parameters....
2017-07-18T16:56:28 WARN src/common.c: unknown chip id! 0

Expected/description:
Expecting the device to have to program loaded into flash. This is a custom board, as mentioned above. It is possible there is a design error. I am not too familiar with the way the STM32F4XX series works and may not have the knowledge to diagnose the issue myself. If there are resources beyond which I have found, I will gladly read up on them.

[xor-gate]

Make sure you have hooked up the SWDIO/SWCLK and the Reset correctly. The reset should also have an pullup resistor. Have a look at Nucleo or Discovery board reference designs.

[bryanmonti]

They are consistent with the Discovery board, from what I can see on the schematics. What value resistor should be on the pullup?

It is now returning a value of: st-flash --reset write main.bin 0x08000000
st-flash 1.3.1
2017-07-19T11:14:36 INFO src/common.c: Loading device parameters....
2017-07-19T11:14:36 WARN src/common.c: unknown chip id! 0xa05f0000

[xor-gate]

You should read the datasheet, normal 10k is enough also with a capacitor to ground for preventing glitches.

[bryanmonti]

Yes, it is setup as such. I based most of it of the discovery board. Still returning unknown chip ID 0.

Is there any other information I can provide that will aide in debugging this?

[xor-gate]

I have no idea why there is something wrong with your board, your chip is supported and chipid zero is mostly a hardware problem.

[jcw]

FWIW, I've seen this error on F103 boards with DIO and CLK reversed. Swapping the wires solved it.

[TediumRemedy]

I am having the same problem on my BluePill STM32F103 (http://wiki.stm32duino.com/index.php?title=Blue_Pill) and OS X 10.12.6
Normally it's programming fine, but occasionally I am getting:

st-flash 1.3.0
2017-09-13T14:56:22 INFO: Loading device parameters....
2017-09-13T14:56:22 WARN: unknown chip id! 0

and once I get this message, any further attempt to flash the mcu using st-util/st-flash end up with this error.

I usually "reset" this problem by connecting to a Windows PC and using the STM's STLink Utility (which can't connect to my MCU after being flashed using Texane st-link, unless I press the reset button during connection - something gets corrupted in the flash of the MCU with the st-util) from STLink Utility (just opening/closing with STLink Utility is enough to fix the problem!). Then it works fine, but it would really be nice if the st-util application had a similar functionality. Sometimes I am able to overcome this problem by holding RESET button and flashing my firmware with st-util, but in most cases this "method" isn't working.

So, it looks like st-util occasionally damages something in the flash, which can be recovered by simply connecting to the target in STLink Utility while holding the RESET button (too bad this official tool is only available for Windows though).

(Could it be because the flash memory of the controller is worn out? though I doubt it...)

[jcw]

Holding reset has the effect of not starting your code, which might be disabling JTAG/SWD or messing with those I/O pins in some other way. As I understand it, JTAG & SWD will continue to work while the µC is in reset. Another approach might be to set BOOT1 to "1", cause the reset to enter the ROM boot loader - maybe then you can access your Blue Pill again?

[TediumRemedy]

@jcw
Oddly enough, sometimes connecting BOOT1 to VCC works in this situation, sometimes it doesn't. The problem is all of this is not consistent, so I thought that attempting to replicate the STLink utility from ST Microelectronics for Unix might be helpful - since this utility has proved to be the most reliable solution. Looks like it is doing something that st-util doesn't.

I am not doing anything in my code apart from setting this in Cube:

and this

[amok]

@TediumRemedy maybe this is the case of https://community.st.com/thread/15556

[el2ro]

I was also having "unknown chip id 0" issue using ST-LINK/V2 ISOL on custom board having STM32F04xx. I tested this with cheaper ST-LINK/V2 programmer and it is working fine. No other changes to setup. Does someone have any ideas why does not the ISOL version work?

[xor-gate]

@el2ro in theory ISOL should not be different from the normal official STMicroelectronics stlinkv2/stlinkv2-1

[Nightwalker-87]

@bryanmonti @jcw @TediumRemedy @el2ro: What is the current state of this for each of you? Is this hardware- or software-related?

[Nightwalker-87]

@Ant-ON: As I read from the code, Unknown chip id 0! is always displayed if no connection could be established to the target or if the chip-ID is readable, but not listed in chipid.h. Is there any way to distinguish both cases to address this issue? I could imagine a conceptual proceeding like:

1. The chip-ID register was readable --> print the output --> content does not match anything listed in chipid.h --> display message mcu detected, but of unknown type
2. The chip-ID register was not readable --> check if there is anything connected, that provides any other information about a connected MCU --> YES: display message mcu detected, but unreadable
3. The chip-ID register was not readable --> check if there is anything connected, that provides any other information about a connected MCU --> NO: display message no target connected, check physical connection

Is there any possibility to implement the above scenario? I think this would indeed allow to distinguish use cases properly.

[Ant-ON]

@Nightwalker-87 In version 1.7+, it is displayed as zero if the address of chip id reading is unknown (possible only for new series of MCU, which are not yet). I'll fix this so that everything stops at the message:

stlink/src/common.c

Line 1543 in 71d1dab

ELOG("Could not find chip id!\n");

[Nightwalker-87]

ping @Ant-ON

[Ant-ON]

@Nightwalker-87 I think this issue can be closed. Already added a message about connection failure and inability to identify the chip (see stlink_chip_id)

[Nightwalker-87]

Intermediate summary for possible reasons:

• HW related issue, if DIO and CLK lanes are reversed: Unknown chip id 0! #620 (comment)
• connected chip is not yet supported by the toolset: Unknown chip id 0! #620 (comment) This is obviously not a bug and intended behaviour.
• issue due to temporary overvoltage powering: STM32L Discovery Board - "unknown chip id" loading failed #104
• enabled write protection on the chip: STM32F4 Discovery Unknown Chip ID! 0 - Due to Read Out Protection level 1 #422, STM32F103R8: Problems flashing device - unknown core / chip id! 0 #468

[Nightwalker-87]

Finally closed by #1120.