Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

STM32L Discovery Board - "unknown chip id" loading failed #104

Open
s3th opened this Issue · 8 comments

5 participants

@s3th

Hey,

I can't load new code into my FLASH, by reading the stlink tool's output I assume that some parts of the mem (which hold the Chip ID and KARL information) were overwritten. Even st-flash failed. How can I fix that? (reconnecting the USB cable didn't work of course ;) )

st-util gives me the following output:
2012-08-04T09:08:18 INFO src/stlink-usb.c: -- exit_dfu_mode
2012-08-04T09:08:18 INFO src/stlink-common.c: Loading device parameters....
2012-08-04T09:08:18 WARN src/stlink-common.c: unknown chip id! 0
Chip ID is 00000000, Core ID is 2ba01477.
KARL - should read back as 0x03, not 60 02 00 00
init watchpoints
Listening at *:4242...

arm-none-eabi-gdb:
GNU gdb (Sourcery G++ Lite 2010q1-188) 7.0.50.20100218-cvs
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-eabi".
For bug reporting instructions, please see:
https://support.codesourcery.com/GNUToolchain/.
(gdb) target extended-remote :4242
Remote debugging using :4242
0x00000000 in ?? ()
(gdb) load foo.elf
Loading section .isr_vector, size 0x10c lma 0x8000000
Load failed
(gdb)

when executing load foo.elf st-util gives me following output:
(...)
GDB connected.
recv: qSupported:multiprocess+
query: Supported;multiprocess+
send: PacketSize=3fff;qXfer:memory-map:read+
recv: !
send: OK
recv: Hg0
send:
recv: ?
send: S05
recv: Hc-1
send:
recv: qC
send:
recv: qAttached
query: Attached;
send:
recv: g
send: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
recv: qXfer:memory-map:read::0,fff
query: Xfer;memory-map:read::0,fff
Xfer: type:memory-map;op:read;annex:;addr:0;length:4095
send: m<?xml version="1.0"?><!DOCTYPE memory-map PUBLIC "+//IDN gnu.org//DTD GDB Memory Map V1.0//EN" "http://sourceware.org/gdb/gdb-memory-map.dtd"> 0x0
recv: qXfer:memory-map:read::26d,d92
query: Xfer;memory-map:read::26d,d92
Xfer: type:memory-map;op:read;annex:;addr:621;length:3474
send: l
recv: m0,4
send: 14000000

and st-flash:
2012-08-04T09:21:21 INFO src/stlink-common.c: Loading device parameters....
2012-08-04T09:21:21 WARN src/stlink-common.c: unknown chip id! 0xe0042000
Mass erasing

Regards and thanks in advance,

s3th

@deanchester

I am also getting this error. Might I have damaged my board? And how should the jumpers on the top part be configured?

@burnsfisher
@yushanh

Hi Burns,

I already have the up-to-date version. I wonder if this is related to my recent change on my hardware? Will that affect anything?

I soldered an oscillator (8MHz), two capacitors and a resistor on pad X30 of STM32L-Discovery for high speed external clock, so I could enable the USB CDC function. I was able to download the code a couple times and demonstrate the USB function even after this change, but then I could not download it now. It gave me this message:

yushanh@ubuntu:~/Desktop/STM_toolchain/stlink$ st-flash write build/ch.bin 0x080000
2013-08-01T12:03:17 INFO src/stlink-common.c: Loading device parameters....
2013-08-01T12:03:17 WARN src/stlink-common.c: unknown chip id! 0xe0042000
stlink_sram_flash() == -1

yushanh@ubuntu:~/Desktop/STM_toolchain/stlink$ st-util
2013-08-01T12:05:00 INFO src/stlink-common.c: Loading device parameters....
2013-08-01T12:05:00 WARN src/stlink-common.c: unknown chip id! 0xe0042000
Chip ID is 00000000, Core ID is 2ba01477.
KARL - should read back as 0x03, not 60 02 00 00
init watchpoints
Listening at *:4242...

Do you have any hint of it? Thanks,

Yu-Shan

@yushanh

By the way, when I st-flash the code with my reset button pressed, it can recognize the proper device id but still fail to load the code.

yushanh@ubuntu:~/Desktop/STM_toolchain/stlink$ st-flash write build/ch.bin 0x08000000
2013-08-01T12:11:19 INFO src/stlink-common.c: Loading device parameters....
2013-08-01T12:11:19 INFO src/stlink-common.c: Device connected is: L1 Medium-Plus-density device, id 0x10006427
2013-08-01T12:11:19 INFO src/stlink-common.c: SRAM size: 0x8000 bytes (32 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 256 bytes
open(build/ch.bin) == -1
2013-08-01T12:11:19 ERROR src/stlink-common.c: map_file() == -1
stlink_fwrite_flash() == -1

@burnsfisher
@yushanh

Hi Burns,

Yes they are the same version. I clone your code last week so it should be the newest version and I never change it.

I knew about the HSE_BYPASS and tried to solder the SB17 before as well. However, the same error happened when st-flash. After I removed the SB17 short, my code can be loaded again. And this time, the same thing happened for pad X30 with HSE_ON enabled.

I tested on your stlink tool chain and the MDK-ARM Keil IDE, both could not load the code while SB17 is short (HSE_BYPASS) or X30 is soldered (HSE_ON).

It is pretty weird if we change the hardware design for our application, we can't load the code anymore. :(

Yu-Shan

@burnsfisher
@rewolff

GUYS,
I had the same problem last week. This window was still open due to trying to find a solution.....

Turns out I had been powering the STM32 with 5V. When I reduced the voltage to 3.3V as required, I could communicate with the chip again.
Two things: 1) The chip survived. 2) The chip even worked when over-volted! (the existing application flashing a led just worked!).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.