-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
STM32L Discovery Board - "unknown chip id" loading failed #104
Comments
I am also getting this error. Might I have damaged my board? And how should the jumpers on the top part be configured? |
Hi Yu-Shan, How recently did you get a copy of the stlink software? It would not work However, a couple changes recently have caused problems...I don't know if Burns On Fri, Jul 26, 2013 at 5:27 PM, Yu-Shan Hsiao notifications@git.luolix.topwrote:
|
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 yushanh@ubuntu:~/Desktop/STM_toolchain/stlink$ st-util Do you have any hint of it? Thanks, Yu-Shan |
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 |
That is pretty mysterious. But did you say that the st-util you are using A couple more thoughts: 1) It sounds like you have tried pushing reset.
/* SYSCLK, HCLK, PCLK2 and PCLK1 configuration
I hope this helps... Burns On Thu, Aug 1, 2013 at 3:07 PM, Yu-Shan Hsiao notifications@git.luolix.topwrote:
|
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 |
Very weird that soldering that SB17 caused a failure to load. When I see a But about the ST-link code. You said that you cloned my code. You got it Good luck... Burns On Thu, Aug 1, 2013 at 4:28 PM, Yu-Shan Hsiao notifications@git.luolix.topwrote:
|
GUYS, 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. |
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
The text was updated successfully, but these errors were encountered: