Unknown chip id 0!

[bryanmonti]

• [x] Programmer/board type: e.g Stlink/v1, Stlink/v2, Stlink/v2-onboard
• [x] Programmer firmware version: e.g STSW-LINK007 2.27.15 -> Unknown
• [x] Operating system: e.g Linux, Mac OS X, Windows (with specific version) -> macOS 10.11.6
• [x] Stlink tools version and/or git commit hash: e.g v1.1.0/git-c722056 -> v1.3.1
• [x] Stlink commandline tool name: e.g st-info, st-flash, st-util-> st-flash
• [x] 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?

[jcw]

I have not run into this recently (but then again, I use a mix of openocd and stlink for uploading to various boards). I can confirm that chipid 0 will definitely show up when some µCs are in stop/standby mode, e.g. for STM32L031:

$ st-info --probe
Found 1 stlink programmers
 serial: 303637374646353334393531373735303837323134333434
openocd: "\x30\x36\x37\x37\x46\x46\x35\x33\x34\x39\x35\x31\x37\x37\x35\x30\x38\x37\x32\x31\x34\x33\x34\x34"
  flash: 0 (pagesize: 0)
   sram: 0
 chipid: 0x0000
  descr: unknown device

I can't make this go away by holding the µC in reset, but I can upload to it with openocd with reset pressed, and then released once the upload hangs - at that point the upload finishes, and verifies ok.

PS. This particular example through an ST-Link 2.1, cut off from a Nucleo board (latest s/w rev).

[Nightwalker-87]

@jcw: What version of the stlink-tools did you use? I'd like to find out why this happens and if this error has already been addressed somewhere...

[jcw]

I'm using stlink 1.6.0, installed via homebrew on macOS.

[Nightwalker-87]

@jcw: Any changes with recent Release v1.6.1 ?

[PavelMeld]

Have same issue with onboard STLINK on STM32VLDISCOVERY discovery board:

mpv@mpv-ubuntu:bin$ ./st-info --probe
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_GET_VERSION
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_GET_CURRENT_MODE
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_GET_CURRENT_MODE
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_ENTER
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_RESETSYS
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_READCOREID
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
Found 1 stlink programmers
  version:    V1
  serial:     303030303030303030303031
  hla-serial: "\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x31"
  flash:      0 (pagesize: 0)
  sram:       0
  chipid:     0x0000
  descr:      unknown device

[Nightwalker-87]

@PavelMeld You use different programmer hardware (STLINK-v1) and are looking at a different issue related to libusb. Please refer to #1045 instead. Also you did not report any software version... :-(

[Nightwalker-87]

Can we have some recent feedback on this to show in which situations the warning WARN: unknown chip id! 0 occurs? This ticket appears to be an evergreen and it is about time and also our intention to solve it.

[jcw]

I don't have an example at hand anymore. I use PlatformIO with a variety of boards, but that's all OpenOCD, as far as I can tell. I will report as a new issue if this pops up again, and can then go into more detail, so that we can get to the bottom of this.

[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: https://github.com/stlink-org/stlink/blob/71d1dab62062c44443cd9367ff23bd707a978c55/src/common.c#L1543

[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:

• [x] HW related issue, if DIO and CLK lanes are reversed: https://github.com/stlink-org/stlink/issues/620#issuecomment-328946678
• [x] connected chip is not yet supported by the toolset: https://github.com/stlink-org/stlink/issues/620#issuecomment-841030622 This is obviously not a bug and intended behaviour.
• [x] issue due to temporary overvoltage powering: #104
• [x] enabled write protection on the chip: #422, #468

[Nightwalker-87]

Finally closed by #1120.