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

STM32F1 load fail #182

Closed
dimitraPat opened this Issue Oct 4, 2013 · 14 comments

Comments

Projects
None yet
8 participants
@dimitraPat

dimitraPat commented Oct 4, 2013

Hi!
I've found this utility for flashing the STM32 mcu and I think it's very cool.

However, I've been trying to flash the STM32F1 and while at the beginning seems to load correctly, when it reaches add 0x08080000 the flash loader fails.

Does the utility support F1? Do I have to change anything in order to work correctly?

Thanks!

@qneverless

This comment has been minimized.

Show comment
Hide comment
@qneverless

qneverless Oct 5, 2013

Does your mcu have more than 512kB of memory?

qneverless commented Oct 5, 2013

Does your mcu have more than 512kB of memory?

@dimitraPat

This comment has been minimized.

Show comment
Hide comment
@dimitraPat

dimitraPat Oct 7, 2013

Yes, the mcu is with dual flash banks. The second bank must be defined somehow.

dimitraPat commented Oct 7, 2013

Yes, the mcu is with dual flash banks. The second bank must be defined somehow.

@jsarenik

This comment has been minimized.

Show comment
Hide comment
@jsarenik

jsarenik Oct 9, 2013

I have the same problem on current version of stlink (a13e75a) with STM32VL-DISCOVERY and STM32F105 (both over STLINKv1).

When I try to 'load' via arm-none-eabi-gdb, I get following on the st-util terminal:
ERROR src/stlink-common.c: flash loader run error
ERROR src/stlink-common.c: run_flash_loader(0x8000000) failed! == -1

and on the GDB terminal I get 'Error finishing flash operation'.

When I use st-flash, it works with the latest version, using
st-flash write out.bin 0x08000000

I have tried to compile older stlink (as I remember it worked back then),
29d03e9 and 'load' via GDB works
with that version. Sorry I cannot bisect at the moment but in case I do,
will let you know which commit breaks it.

Thanks and good luck!

jsarenik commented Oct 9, 2013

I have the same problem on current version of stlink (a13e75a) with STM32VL-DISCOVERY and STM32F105 (both over STLINKv1).

When I try to 'load' via arm-none-eabi-gdb, I get following on the st-util terminal:
ERROR src/stlink-common.c: flash loader run error
ERROR src/stlink-common.c: run_flash_loader(0x8000000) failed! == -1

and on the GDB terminal I get 'Error finishing flash operation'.

When I use st-flash, it works with the latest version, using
st-flash write out.bin 0x08000000

I have tried to compile older stlink (as I remember it worked back then),
29d03e9 and 'load' via GDB works
with that version. Sorry I cannot bisect at the moment but in case I do,
will let you know which commit breaks it.

Thanks and good luck!

@jsarenik

This comment has been minimized.

Show comment
Hide comment
@jsarenik

jsarenik Oct 15, 2013

My problem is fixed by using "-1" flag for st-util. Tested with latest commit.

jsarenik commented Oct 15, 2013

My problem is fixed by using "-1" flag for st-util. Tested with latest commit.

@armdeveloper

This comment has been minimized.

Show comment
Hide comment
@armdeveloper

armdeveloper Mar 11, 2014

Hi ...I am facing similar problem. While trying to open STLINK, here is what happens:
...
...

"vivek@ubuntu:~/st/stlink$./st-util -1
2014-03-11T23:29:49 INFO src/stlink-sg.c: Current mode unusable, trying to get back to a useful state...
2014-03-11T23:29:49 WARN src/stlink-sg.c: received tag 0 but expected 3
2014-03-11T23:29:49 INFO src/stlink-common.c: Loading device parameters....
2014-03-11T23:29:49 WARN src/stlink-common.c: unknown chip id! 0xe0042000
2014-03-11T23:29:49 INFO src/stlink-sg.c: Successfully opened a stlink v1 debugger
Chip ID is 00000000, Core ID is 00000000.
Listening at *:4242...
./st-util -1
2014-03-11T23:29:49 INFO src/stlink-sg.c: Current mode unusable, trying to get back to a useful state...
2014-03-11T23:29:49 WARN src/stlink-sg.c: received tag 0 but expected 3
2014-03-11T23:29:49 INFO src/stlink-common.c: Loading device parameters....
2014-03-11T23:29:49 WARN src/stlink-common.c: unknown chip id! 0xe0042000
2014-03-11T23:29:49 INFO src/stlink-sg.c: Successfully opened a stlink v1 debugger
Chip ID is 00000000, Core ID is 00000000.
Listening at *:4242... "

...
...
...

Similarly while trying to load the binary here is the output

...
...

"vivek@ubuntu:~/st/STM32-Template$ arm-none-eabi-gdb
GNU gdb (Sourcery CodeBench Lite 2012.09-63) 7.4.50.20120716-cvs
Copyright (C) 2012 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) tar ext :4242
Remote debugging using :4242
0x00000000 in ?? ()
(gdb) load BlinkingLight.elf
Loading section .text, size 0x17b8 lma 0x8000000
Load failed
"
One more thing....once I run gdb.....here is the response that I get at STLINK window:
...
...
"KARL - should read back as 0x03, not 60 02 00 00
GDB connected.
"
..
..

......Have hit a roadblock. Any help would be appreciated.

armdeveloper commented Mar 11, 2014

Hi ...I am facing similar problem. While trying to open STLINK, here is what happens:
...
...

"vivek@ubuntu:~/st/stlink$./st-util -1
2014-03-11T23:29:49 INFO src/stlink-sg.c: Current mode unusable, trying to get back to a useful state...
2014-03-11T23:29:49 WARN src/stlink-sg.c: received tag 0 but expected 3
2014-03-11T23:29:49 INFO src/stlink-common.c: Loading device parameters....
2014-03-11T23:29:49 WARN src/stlink-common.c: unknown chip id! 0xe0042000
2014-03-11T23:29:49 INFO src/stlink-sg.c: Successfully opened a stlink v1 debugger
Chip ID is 00000000, Core ID is 00000000.
Listening at *:4242...
./st-util -1
2014-03-11T23:29:49 INFO src/stlink-sg.c: Current mode unusable, trying to get back to a useful state...
2014-03-11T23:29:49 WARN src/stlink-sg.c: received tag 0 but expected 3
2014-03-11T23:29:49 INFO src/stlink-common.c: Loading device parameters....
2014-03-11T23:29:49 WARN src/stlink-common.c: unknown chip id! 0xe0042000
2014-03-11T23:29:49 INFO src/stlink-sg.c: Successfully opened a stlink v1 debugger
Chip ID is 00000000, Core ID is 00000000.
Listening at *:4242... "

...
...
...

Similarly while trying to load the binary here is the output

...
...

"vivek@ubuntu:~/st/STM32-Template$ arm-none-eabi-gdb
GNU gdb (Sourcery CodeBench Lite 2012.09-63) 7.4.50.20120716-cvs
Copyright (C) 2012 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) tar ext :4242
Remote debugging using :4242
0x00000000 in ?? ()
(gdb) load BlinkingLight.elf
Loading section .text, size 0x17b8 lma 0x8000000
Load failed
"
One more thing....once I run gdb.....here is the response that I get at STLINK window:
...
...
"KARL - should read back as 0x03, not 60 02 00 00
GDB connected.
"
..
..

......Have hit a roadblock. Any help would be appreciated.

@AmazingPants

This comment has been minimized.

Show comment
Hide comment
@AmazingPants

AmazingPants Apr 28, 2014

@jsarenik please can you explain in detail what did you do?

AmazingPants commented Apr 28, 2014

@jsarenik please can you explain in detail what did you do?

@jsarenik

This comment has been minimized.

Show comment
Hide comment
@jsarenik

jsarenik Apr 28, 2014

There is not much to explain. I just run "st-util -1" whenever I would run "st-util"... does that make sense?

jsarenik commented Apr 28, 2014

There is not much to explain. I just run "st-util -1" whenever I would run "st-util"... does that make sense?

@idubrov

This comment has been minimized.

Show comment
Hide comment
@idubrov

idubrov May 23, 2014

Somehow adding "-v" fixes similar problem to me. I.e, "st-util" fails whenether I try to load image & debug from Eclipse, "st-util -v" works. Bizarre.

idubrov commented May 23, 2014

Somehow adding "-v" fixes similar problem to me. I.e, "st-util" fails whenether I try to load image & debug from Eclipse, "st-util -v" works. Bizarre.

@xor-gate

This comment has been minimized.

Show comment
Hide comment
@xor-gate

xor-gate May 17, 2016

Collaborator

Feel free to open a new issue when the problem still remains with v1.2.0 or master. Thanks all for your contributions.

Collaborator

xor-gate commented May 17, 2016

Feel free to open a new issue when the problem still remains with v1.2.0 or master. Thanks all for your contributions.

@xor-gate xor-gate closed this May 17, 2016

@jonbinney

This comment has been minimized.

Show comment
Hide comment
@jonbinney

jonbinney Jun 19, 2016

-v fixed the problem for me as well... very strange....

jonbinney commented Jun 19, 2016

-v fixed the problem for me as well... very strange....

@jsarenik

This comment has been minimized.

Show comment
Hide comment
@jsarenik

jsarenik Jun 20, 2016

Yes, I remember that behavior. With -v it worked, without it needed -1 to work. I no longer have the HW to try v1.2.0.

jsarenik commented Jun 20, 2016

Yes, I remember that behavior. With -v it worked, without it needed -1 to work. I no longer have the HW to try v1.2.0.

@xor-gate

This comment has been minimized.

Show comment
Hide comment
@xor-gate

xor-gate Jun 20, 2016

Collaborator

@jonbinney do you still need -v with v1.2.0 ?

Collaborator

xor-gate commented Jun 20, 2016

@jonbinney do you still need -v with v1.2.0 ?

@jonbinney

This comment has been minimized.

Show comment
Hide comment
@jonbinney

jonbinney Jun 20, 2016

I did have this problem yesterday with the current git master version (hash 3f7d0f9df3b1b551ac317b9d3a185c48f19c0c97 )

But today (after a reboot) I can't reproduce the problem at all. It works with or without -v. I tried it 5 times and didn't have any problems.

jonbinney commented Jun 20, 2016

I did have this problem yesterday with the current git master version (hash 3f7d0f9df3b1b551ac317b9d3a185c48f19c0c97 )

But today (after a reboot) I can't reproduce the problem at all. It works with or without -v. I tried it 5 times and didn't have any problems.

@xor-gate

This comment has been minimized.

Show comment
Hide comment
@xor-gate

xor-gate Jun 20, 2016

Collaborator

Probably when adding -v printf output takes CPU time and "sleeps" te original code. This seems a timing issue, I have seen an issue with a broken usb cables resulted in super weird behaviour. Probably you could also inspect dmesg | tail when running under linux.

Collaborator

xor-gate commented Jun 20, 2016

Probably when adding -v printf output takes CPU time and "sleeps" te original code. This seems a timing issue, I have seen an issue with a broken usb cables resulted in super weird behaviour. Probably you could also inspect dmesg | tail when running under linux.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment