vl discovery does not work (unable to write flash) #82

Closed
jmondi opened this Issue May 23, 2012 · 14 comments

5 participants

@jmondi

Hello there,
I'm having huge troubles working with STM32VL-Discovery (STM32F100RB Device with 128KByte FLASH, 8KByte RAM).

I'm able to launch st-util (I have installed udev and modprobe rules, device is ignored by usb-storage), but I'm not able to write the flash of the device.
I'm launching st-util with
./st-util -s1 -d /dev/stlinkv1_2 -1 -p 4242

but when connecting with gdb (code sourcery version) I get the following message:
warning: while parsing target memory map (at line 1): Can't convert length="0x8x" to an integer
0x08000ec8 in ?? ()

I'm able, anyway, to issue the load command and gdb seems to flash the target:

(gdb) load bin/out.hex
Loading section .sec1, size 0x4428 lma 0x8000000
Start address 0x8004378, load size 17448
Transfer rate: 80 KB/sec, 5816 bytes/write.

But this is not true. The new firmware gets not loaded and I'm not able to issue breakpoints and watchpoints.
The linker script has been generated with atollic true studio, and the ELF sections are in their correct place (text in flash section, bss and data in RAM etc).
I'm on Ubuntu 12.04, using an update version of stlink from your git repo.

Thank You

(I wasn't able to use st-link neither on ST3210E-EVAL, with an external st-link V1. Things were more or less the same: no breakpoints, no real writing)

@jmondi

I think the warning message is related to this send from gdbserver

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"> 0x400

where the length="0x8x message is reported

@karlp

Tectu from ##stm32 is about to submit a fix for this. In the meantime, edit line 231 of gdbserver/gdb-server.c to say "0x10" instead of "0x8x", and remake...

@Tectu

Issue got fixed, pullrequest sent.

Change the line like karlp said or use my fixed repo untill pull request got comitted :)

@jmondi

I can confirm the warning message disappears, but still program does not get loaded.

gdb ouput: http://pastebin.com/jYYGejy1
st-util output: http://pastebin.com/ZdGcRFwE

Thank you all

@Tectu

This is a not realted issue, in my opinion.

Please try to load the .elf instead of the .hex file

@jmondi

Board is ok, with other gdb servers works perfectly.
With atollic gdb server I had to specify manually to use SWD instead of JTAG. Have I to do the same for stlink?

@Tectu

I updated my comment above.

JTAG and SWD are handled the same, this won't be a problem.

@jmondi

Not working neither with elf nor hex files.

@Tectu

Okay, please make sure that both of your boot pins are 0 and you do load the .elf file.

@jmondi

I'll check the pins status in the next days, I have nothing to make measures with here at home...

@Tectu

when you didn't change anything on the board and you didn't add any external components, then this cannot be an issue.
I'll try it on my own STM32VL board when I am back at home in a few hours.

@leha2001

I have same problem too.
Board STM32 value line discovery.
I detect what load size is bigger than write size, ratio (load size)/(write bytes) = integer number (2,3,4)
Why??

st-util:
leha@work ~/STM32/clock $ ~/STM32/stlink_temp/st-util -1
2012-06-15T15:39:14 INFO src/stlink-common.c: Loading device parameters....
2012-06-15T15:39:14 INFO src/stlink-common.c: Device connected is: F1 Medium-density Value Line device, id 0x10016420
2012-06-15T15:39:14 INFO src/stlink-common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2012-06-15T15:39:14 INFO src/stlink-sg.c: Successfully opened a stlink v1 debugger
Chip ID is 00000420, Core ID is 1ba01477.
KARL - should read back as 0x03, not 60 02 00 00
init watchpoints
Listening at *:4242...

GDB:
(gdb) GNU gdb (GDB) 7.4
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-elf".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
(gdb) target extended-remote :4242
0x08000684 in ?? ()
(gdb) load main.elf
Loading section .text, size 0x4d50 lma 0x8000000
Loading section .rodata, size 0x40 lma 0x8004d50
Loading section .data, size 0x28 lma 0x8004d90
Start address 0x8000685, load size 19896
Transfer rate: 4 KB/sec, 4974 bytes/write.
(gdb) file main.elf
(gdb)
19896/4974=4.0

(gdb) load main.elf
`/home/leha/STM32/clock/main.elf' has changed; re-reading symbols.
Loading section .text, size 0x22e0 lma 0x8000000
Loading section .data, size 0x28 lma 0x80022e0
Start address 0x8000471, load size 8968
Transfer rate: 4 KB/sec, 4484 bytes/write.
(gdb) file main.elf
(gdb)
8968/4484=2.0

(gdb) load main.elf
`/home/leha/STM32/clock/main.elf' has changed; re-reading symbols.
Loading section .text, size 0x2d38 lma 0x8000000
Loading section .rodata, size 0x40 lma 0x8002d38
Loading section .data, size 0x28 lma 0x8002d78
Start address 0x8000635, load size 11680
Transfer rate: 4 KB/sec, 3893 bytes/write.
(gdb) file main.elf
(gdb)
11680/3893=3.0

@karlp

leha, that's completely unrelated to the issue here. The load size is the sum of each section, just that the sections are in hex, and the load size is in decimal. The reason you see different "write sizes" is because the ratio of your sections changes. Your rodata and data sections stay the same, but are very inefficient as far as bytes per transfer. with a smaller .text section, the bytes per write goes down. What problem are you trying to diagnose by doing this maths? it offers no useful information to you.

@karlp

texane! please close this!

@xor-gate xor-gate closed this May 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment