STM32L Discovery Board - "unknown chip id" loading failed

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

Hi Yu-Shan,

How recently did you get a copy of the stlink software? It would not work
on the new Discovery board (with 32K RAM and 256K flash) until my change a
few weeks ago. The problem was that the software did not understand that
chip id.

However, a couple changes recently have caused problems...I don't know if
Texane pulled that one or not. If you look for a change from burnsfisher
and use that version, it works on both STM32L Discovery and DISCO (the new
one) boards.

Burns

On Fri, Jul 26, 2013 at 5:27 PM, Yu-Shan Hsiao notifications@github.comwrote:

Hi, I'm using STM32L-Discover and I have the same problem of unknown chip
id. Does anyone figure how? Thanks

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/104#issuecomment-21649203
.

[vickihsiao]

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

[vickihsiao]

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]

That is pretty mysterious. But did you say that the st-util you are using
now (and failing at) is the same as the version that worked once? That
sounds like maybe something happened to the hardware. Do you have a
different discovery card to try?

A couple more thoughts: 1) It sounds like you have tried pushing reset.
That has sometimes helped me. I have also sometimes gotten something on
the Discovery quite confused, and I ended up using st-flash to clear memory
so I am not trying to execute some bogus code.

2. You don't have to add a crystal to the discovery board. If you short
   solder bridge SB17, that will run the 8MHz clock output from the ST-Link
   ship already on the discovery to the STM32L. The only difference is that
   you need to set HSEBYP to say that your are getting a clock signal in and
   you don't need the on-chip oscillator. You can #ifdef it based on
   Discovery or your actual product like this:

/* SYSCLK, HCLK, PCLK2 and PCLK1 configuration
---------------------------/
/ Enable HSE /
/

• Note that on the Discovery board, for 32MHz, we assume you have shorted
• SB17. In that case you get a clock signal in, and you have to enable
• HSEBYP (HSE Bypass). That's because you don't need an oscillator...you
• are already getting the clock. On the actual product, we will have a
• crystal, and you need HSEBYP turned off so that that crystal can drive
• the built-in oscillator.
  */
  #ifdef DISCOVERY_BOARD
  RCC->CR |= ((uint32_t)(RCC_CR_HSEON | RCC_CR_HSEBYP));
  #else
  RCC->CR |= (uint32_t)(RCC_CR_HSEON);
  #endif

I hope this helps...

Burns

On Thu, Aug 1, 2013 at 3:07 PM, Yu-Shan Hsiao notifications@github.comwrote:

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

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/104#issuecomment-21961902
.

[vickihsiao]

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]

Very weird that soldering that SB17 caused a failure to load. When I see a
failure to load, it is sometimes due to the code that was there before
running in a loop with interrupts disabled. I know that there is a loop in
the clock code where it tries to change clock types. (You know that reset
always starts out with the low speed onboard clock and you have to switch
it). For example, if it tries to start the HSE clock and fails, I think it
goes into a loop. I wonder if that is related.

But about the ST-link code. You said that you cloned my code. You got it
from my repository, not Texane's? If so, that's good. There have been a
couple other changes in Texane's for other processors and I have not tried
it. A few people did have problems with the very latest change that
someone else made though.

Good luck...

Burns

On Thu, Aug 1, 2013 at 4:28 PM, Yu-Shan Hsiao notifications@github.comwrote:

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

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/104#issuecomment-21967262
.

[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!).