The stlink from stlink-org

stm32f4 discovery board - cannot step

Hi,
I have a stm32f4 discovery board and I have builded IO_Toggle example.
I have started st-util with default port(4242), I have started in another terminal arm-none-eabi-gdb. I have used following commands, in gdb:
(gdb) target extended-remote localhost:4242
Remote debugging using localhost:4242
warning: Can not parse XML memory map; XML support was disabled at compile time
0x0800788c in ?? ()
(gdb) load IO_Toggle.elf
Loading section .isr_vector, size 0x188 lma 0x8000000
Loading section .text, size 0xd88 lma 0x8000188
Loading section .data, size 0x24 lma 0x8000f10
Start address 0x8000ec9, load size 3892
Transfer rate: 19 KB/sec, 1297 bytes/write.
(gdb) symbol-file IO_Toggle.elf
Reading symbols from /home/andrei/sat/bin/IO_Toggle.elf...done.
(gdb) b main
Breakpoint 1 at 0x800018c: file main.c, line 58.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program:

And gdb doesn't stop into main function. After pressing CTRL+C I get this:
^C0x0800029e in Delay (nCount=0) at main.c:111
111 }
(gdb)
If I want to step over the next line, and press n, I am keep getting this:
111 }
(gdb) n
111 }
(gdb) n
111 }
nCount has value 0, but the loop is still executing.
If I press c, the program continues and the leds are blinking on the board.
Do you know hou can I use breakpoints? I mention that I have disabled optimizations (with -O0). I have a linux Ubuntu machine.

Regards,
Andrei

[fix/patch] STM32F1VL - cannot load code to sram

Hi,

i tried to use the gdbserver with a STM32F1 Value Line board with stlink v1 on macos. I could not download code to sram but could connect to the device and read registers for example. When I issued the load command in gdb, gdb responded with load failed.

I figured out that the reason is a missing memory map setting which resultes in zero length memory sizes.

Please find attached a patch to fix the problem. Affected is only gdbserver.c.

Regards

Friedrich

Unclear what nbproject files are for.

What are the files in nbproject for?

Are they to support NetBeans using st-util as a gdbserver, or are they so that the code for stlink can be developed with NetBeans,. both?

If you give me some direction, I could try to write a document for you.

PKG_CHECK_MODULES USB unexpected token

I installed this a month ago on OSX and it went fine, I had to reinstall osx and now I am running into problems.

./configure: line 4781: syntax error near unexpected token USB,' ./configure: line 4781:PKG_CHECK_MODULES(USB, libusb-1.0 >= 1.0.0,,'

I already installed libusb:

$ pkg-config --libs libusb
-L/usr/local/lib -lusb

$ pkg-config --libs libusb-1.0
-L/usr/local/lib -lusb-1.0

if I comment out the line 4781 from configure which causes the problem then it creates the make file but the makefile doesn't Include or link correctly.

I can compile it by adding -lusb-1.0 to the gcc command (also added -I/usr/local/include/libusb to the makefile)

gcc -g -O2 -o st-util gdbserver/st_util-gdb-remote.o gdbserver/st_util-gdb-server.o mingw/st_util-mingw.o libstlink.a -lusb-1.0

Any ideas why I don't have this USB token?
What should it be?

STM32F4 memory map is wrong.

The 192k of RAM in the STM32F4 is not contiguous. There are actually three different banks, two of which share one memory range, and a third bank of CCM which is at a different address range. The memory map for the STM32F4 should begin:

  "  <memory type=\"rom\" start=\"0x00000000\" length=\"0x100000\"/>"       // code = sram, bootrom or flash; flash is bigger
  "  <memory type=\"ram\" start=\"0x10000000\" length=\"0x10000\"/>"        // ccmram
  "  <memory type=\"ram\" start=\"0x20000000\" length=\"0x20000\"/>"        // sram

[reset] st-flash does not work when CPU is in sleep mode

In general, the st-flash utility has been working fairly well for me. Thank you for your excellent work, guys. I believe the issues I've had, except for the one I am creating this ticket for, have open tickets already.

The problem I'm having is that I'm planing on creating an interrupt driven design. So I have written an experimental program that sets up an interrupt (connected to the user button) and then puts the CPU to sleep by running the __WFI() function. When I flash a program that runs that function, subsequent flashing with st-flash does not work. To get back in touch with the chip, I have to boot into Windows and use the STM-32 ST-LINK Utility from ST to erase the flash. A clue to what is wrong is that the STM-32 ST-LINK Utility does not work either, unless "Connect under Reset" is enabled in Settings.

After flashing the program that runs the __WFI() function, any attempt to flash causes the following error:

dahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ make write
../../flash/flash write lcd.bin 0x08000000
2012-02-09T23:25:54 INFO src/stlink-common.c: Loading device parameters....
2012-02-09T23:25:54 WARN src/stlink-common.c: unknown chip id! 0
stlink_sram_flash() == -1
make: *** [write] Error 255

Any attempt to erase causes (note how the program displays a different chip id):

make: *** [write] Error 255
dahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ ../../flash/flash erase
2012-02-09T23:28:01 INFO src/stlink-common.c: Loading device parameters....
2012-02-09T23:28:01 WARN src/stlink-common.c: unknown chip id! 0xe0042000
Mass erasing

If I hold the Reset button while flashing:

ahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ ../../flash/flash erase
2012-02-09T23:28:28 INFO src/stlink-common.c: Loading device parameters....
2012-02-09T23:28:28 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
2012-02-09T23:28:28 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0 bytes (0 KiB) in pages of 256 bytes

Even after I erase the flash in Windows, I get the following. This is fixed by pushing the Reset button on the card:

dahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ make write
../../flash/flash write lcd.bin 0x08000000
2012-02-10T14:13:21 INFO src/stlink-common.c: Loading device parameters....
2012-02-10T14:13:21 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
2012-02-10T14:13:21 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 256 bytes
2012-02-10T14:13:21 INFO src/stlink-common.c: Attempting to write 7332 (0x1ca4) bytes to stm32 address: 134217728 (0x8000000)
2012-02-10T14:13:21 WARN src/stlink-common.c: pecr.pelock not clear (0x7)
2012-02-10T14:13:21 WARN src/stlink-common.c: Failed to erase_flash_page(0x8000000) == -1
stlink_fwrite_flash() == -1
make: *** [write] Error 255

Unable to run out of RAM after trying to flash

Probably I'm doing something bone-headed, but: I was able to get the blink example running out of flash with both blue and green LEDs flashing. Then I got adventurous and tried blink_flash. The blue and green LEDs never lit up for that, and I think I did that wrong. But having done that, I now can't get the green and blue LEDs to flash when I try to run out of RAM. This is with a 32VL Discovery board, and my host is Ubuntu 10.04. I don't know if it matters but I had an old "arm-elf" toolchain around already so I didn't use "arm-none-eabi". Would that mess things up?

Compile fails on Mac OS 10.6 x86_64

I'm getting this link error when building stlink on mac os 10.6:

ld: in ../libstlink.a, archive has no table of contents for architecture x86_64

Any ideas? I have a reasonably recent XCode installed that is known to build for x86_64 just fine.

Thanks
-Lawrence

Issues when use stlink with recent gdb

Hi,

Based on the recent gdb trunk, I cross built a gdb for target arm-none-eabi. When use this gdb with stlink for STM32F4 discovery board, I ran into some problems when check the target registers in gdb. The first one is there is no xpsr register and the second one is there are legacy FPA registers displayed even my board is based on M4 processor.

After some investigations, I found the issues are because there are some mismatches between gdb and stlink. One is that the stlink can't reply host gdb a target.xml file to introduce the target registers layout. Another is that the g packet reply of stlink only contains registers r0~r15, the xpsr isn't included.

In my opinion, the stlink is a pretty helpful tool when work with ST boards. So can the stlink maintainers please address those mismatches? The possible solutions are:

Enhance the stlink to return standard xml file to host gdb.
Extend the g packet reply to include xpsr registers.

Best regards,
Terry

PS. Investigation on gdb trunk:
When the gdb server doesn't reply target.xml, the host gdb will guess target register information form the length of g packet reply. Currently the three kinds of length are supported: the size of (r0~~r15 + xpsr), the size of (r0~~r15 + f0~~f7 + fps + xpsr) and the size of (r0~~r15 + xpsr + d0~~d15 + fpscr). If none of them are matched, the default arm architecture register layout will be used, which is r0~~r15 + cpsr + f0~f7 + fps.

stm32f102c8t6 doesn't flash

Hello!

I tried STM32L-DISCOVERY based ST-LINK v2 to flash STM32F102C8T6. It worked perfectly on Windows with Atolic GDB server. So I'm sure schematic is OK. I experimented using "./gdbserver/st-util" and "./flash/st-flash" to write and read flash. It looks like it can read flash data but neither write nor erase operations could be done. I tried the following combinations.

"st-util" with "arm-none-eabi-gdb" combination: "load ./target.elf" and "load ./target.hex" process starts but never ends. According to ST-LINK's LED blinks I may know some interaction takes place. But it takes forever.

"st-flash" utility recognizes chip, it's memory and flash size. But neither "write" nor "erase" commands ever finish. I tried "read" command and it's managed to get some file from flash.

It looks like none of write operations (gdb's load, st-flash's write or erase) have any impact on flash content as far as my test firmware is still inside after all experiments.

By the way, both tools (st-flash and st-util) flash well STM32L-DISCOVERY's built-in STM32L microcontroller.

I hope this information helps.

The stlink doesn't retrieve and return FPU registers for STM32F407.

Hi there,

Thanks for your great work. I can debug my STM32F407 Discovery board through stlink. Everything work fine except that I can't display the FPU registers like s0,s1..s31 in GDB. My board does own a hardware FPU. I read the stlink code and find there is a struct called reg which defines a member r[16]. So it seems to me that the stlink doesn't retrieve FPU registers at all.

If I want to read all the registers including core registers and FPU registers, what should I do? Do you guys have any plan to support FPU registers? Thanks very much.

Best regards,
Terry

unknown chip id! 0xe0042000

Hello!
May be it is not an issue of st-link, but if I use

AFIO->MAPR |= AFIO_MAPR_SWJ_CFG_JTAGDISABLE; /*!<((uint32_t)0x02000000) JTAG-DP Disabled and SW-DP Enabled */

then,next time after power down/up board, st-link do not recognise chip.

./st-util -1
2012-02-25T16:00:42 INFO src/stlink-common.c: Loading device parameters....
2012-02-25T16:00:42 WARN src/stlink-common.c: unknown chip id! 0xe0042000
2012-02-25T16:00:42 INFO src/stlink-sg.c: Successfully opened a stlink v1 debugger
Chip ID is 00000000, Core ID is 00000000.
KARL - should read back as 0x03, not 60 02 00 00
init watchpoints
Listening at *:4242...

I use following code to allowing debug,

int main(void) {

chThdSleepMilliseconds(3000);//allow debug for 3 sec run st-link at this time
AFIO->MAPR |= AFIO_MAPR_SWJ_CFG_JTAGDISABLE;/*!< JTAG-DP Disabled and SW-DP Enabled */
......

./st-util -1
2012-02-25T16:01:11 INFO src/stlink-common.c: Loading device parameters....
2012-02-25T16:01:11 INFO src/stlink-common.c: Device connected is: F1 High-density device, id 0x10016414
2012-02-25T16:01:11 INFO src/stlink-common.c: SRAM size: 0x10000 bytes (64 KiB), Flash: 0x80000 bytes (512 KiB) in pages of 2048 bytes
2012-02-25T16:01:11 INFO src/stlink-sg.c: Successfully opened a stlink v1 debugger
Chip ID is 00000414, Core ID is 1ba01477.
KARL - should read back as 0x03, not 60 02 00 00

my setup:
ubuntu 11.04 x86_64
st-link from git (24.02.2012)
STM32VLDISCOVERY -> SW-DP (only SWDIO, SWCLK, GND)->STM32F103VET6
chibios 2.3.3

hopefully this information save some time for somebody.
(I use internal loader to recovery my board)

Also "unknown chip id " error could perhaps because program hangs before stlink was running.
probably this information should be in readme file.

p.s. sorry for my English.

STM32F4 Blink, can't single step, breakpoints dont seem to work

With -O2, "next" commands dont seem to line up with the source code. I can step a few times, than it just takes off running. I guess that can be expected due to optimization. If I build with -O0, the server doesnt hit any breakpoints I set, and just keeps reporting "the target is running" (forever). I suspect the breakpoints are being set to an address that never gets hit. I'm running the blink.elf from ram, the discovery demo is in flash. Maybe I'm doing something wrong?

USB Issues after bad code write

Hi, just yesterday I had flashed some PWM code relating to the PD12-15 pins, and for some reason after that the board would not be recognized by the computer, both on Windows and Linux. If I held down the reset button the computer successfully recognizes the chip and I can upload code to it. Unfortunately the code doesn't do anything once uploaded and the behavior is the same. It registers as an unknown device in Windows.

Now someone on the forums mentioned that if pull the BOOT0 pin up to the supply that it can reupload the code. So it seems to work, but it doesn't now code get's maybe 90% uploaded but always results in error. I have also erased the chip using ST-Link utility. So the problem with detection is not gone away the only way to upload code

This is an example of the error I get:

[TheLegace@localhost discovery_demo]$ flash write STM32F4-Discovery_Demo.bin 0x8000000
2012-01-23T20:47:23 WARN src/stlink-usb.c: Couldn't find any ST-Link/V2 devices[TheLegace@localhost discovery_demo]$ flash write STM32F4-Discovery_Demo.bin 0x8000000
2012-01-23T20:47:24 INFO src/stlink-usb.c: -- exit_dfu_mode
2012-01-23T20:47:24 INFO src/stlink-common.c: Loading device parameters....
2012-01-23T20:47:24 INFO src/stlink-common.c: Device connected is: F4 device, id 0x413
2012-01-23T20:47:24 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
2012-01-23T20:47:24 INFO src/stlink-common.c: Attempting to write 31620 (0x7b84) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000
Flash page at addr: 0x08000000 erasedEraseFlash - Sector:0x1 Size:0x4000
Flash page at addr: 0x08004000 erased
2012-01-23T20:47:25 INFO src/stlink-common.c: Finished erasing 2 pages of 16384 (0x4000) bytes
Writing 4kB chunk 1 out of 7
Writing 4kB chunk 2 out of 7
Writing 4kB chunk 3 out of 7
Writing 4kB chunk 4 out of 7
Writing 4kB chunk 5 out of 7
Writing 4kB chunk 6 out of 7
Writing 4kB chunk 7 out of 7
Writing 4kB chunk 8 out of 7
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_only

I am going to see if the windows flasher works properly or not.
Thanks.

Incorrect description

As the utility now supports much more chips than the original STM32VLDISCOVERY, the one-line description at the top of repository page is incorrect. Maybe it should be replaced with "Programmer for STM32 over ST-Link SWD" or something like that (grammar may be incorrect).

fixes for ST USB host library

Hi!

I'm writing bluetooth usb driver based upon ST USB host library and btstack (http://code.google.com/p/btstack). I've fixed a couple of bugs in ST USB host library (after which my driver became operational).

I want to submit these bug fixes somewhere but I'm not very sure where to. I see this project includes ST code and has refs to ST devteam, so I figured you may now better. Sorry if I'm abusing your issue tracker.

st-flash and STM32F0

I'm trying to use st-flash to flash the STM32F0 discovery. Here's what happens:

tom@Z77A-GD65:~/projects/rc/src/syncf0$ st-flash write build/ch.bin 0x08000000
2012-06-07T17:19:46 INFO src/stlink-common.c: Loading device parameters....
2012-06-07T17:19:46 INFO src/stlink-common.c: Device connected is: F0 device, id 0x20006440
2012-06-07T17:19:46 INFO src/stlink-common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2012-06-07T17:19:46 INFO src/stlink-common.c: Attempting to write 28488 (0x6f48) bytes to stm32 address: 134217728 (0x8000000)
2012-06-07T17:19:46 WARN src/stlink-common.c: unknown coreid: bb11477
2012-06-07T17:19:46 WARN src/stlink-common.c: Failed to erase_flash_page(0x8000000) == -1
stlink_fwrite_flash() == -1

vl discovery does not work (unable to write flash)

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)

Blink flash not working on F4

It seems like running from flash doesnt work on the F4. Preliminary debug shows its hanging in the startup code. Maybe this is because the other discovery boards are M3 and the F4 is M4? Maybe I've done something wrong? Once I get the gdbserver working with F4 flashing I will investigate further.

Inconsistent runtime on st-flash

Below is the output from running st-flash two times with a 10 second wait between the first and the second run, and nothing having changed. The first run gave errors, wrote full pages, ran in a little over 4 minutes and ended with stating that the flashing was verified and successful (I didn't check). The second run gave no errors, flashed half pages, ran in 1 minute and also ended with a successful verification of the flashed data.

I'm wondering...

What is the l1_run_flash_loader error I got on the first run?
Why did the first run decide to flash full pages, and the second to flash half pages?
Why is flashing full pages 4 times as slow as flashing half pages?

Thank you,

Roger

dahl@ubuntu:/Desktop/7$ st-flash write test 0x8000000
2012-03-13T21:23:29 INFO src/stlink-common.c: Loading device parameters....
2012-03-13T21:23:29 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
2012-03-13T21:23:29 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 256 bytes
2012-03-13T21:23:29 INFO src/stlink-common.c: Attempting to write 122880 (0x1e000) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x0801df00 erased
2012-03-13T21:23:50 INFO src/stlink-common.c: Finished erasing 480 pages of 256 (0x100) bytes
2012-03-13T21:23:50 INFO src/stlink-common.c: Starting Half page flash write for STM32L core id
2012-03-13T21:23:50 INFO src/stlink-common.c: Successfully loaded flash loader in sram
run error
2012-03-13T21:23:54 WARN src/stlink-common.c: l1_run_flash_loader(0x8000000) failed! == -1
2012-03-13T21:23:54 WARN src/stlink-common.c:
write_half_pages failed == -1
479/480 pages written
2012-03-13T21:28:01 INFO src/stlink-common.c: Starting verification of write complete
2012-03-13T21:28:04 INFO src/stlink-common.c: Flash written and verified! jolly good!
dahl@ubuntu:/Desktop/7$ st-flash write test 0x8000000
2012-03-13T21:28:13 INFO src/stlink-common.c: Loading device parameters....
2012-03-13T21:28:13 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
2012-03-13T21:28:13 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 256 bytes
2012-03-13T21:28:13 INFO src/stlink-common.c: Attempting to write 122880 (0x1e000) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x0801df00 erased
2012-03-13T21:28:34 INFO src/stlink-common.c: Finished erasing 480 pages of 256 (0x100) bytes
2012-03-13T21:28:34 INFO src/stlink-common.c: Starting Half page flash write for STM32L core id
2012-03-13T21:28:34 INFO src/stlink-common.c: Successfully loaded flash loader in sram
959/960 halfpages written
2012-03-13T21:29:10 INFO src/stlink-common.c: Starting verification of write complete
2012-03-13T21:29:14 INFO src/stlink-common.c: Flash written and verified! jolly good!

Reset CPU after burning new Flash

Using the flash utility (e.g. with "flash write prog.bin 0x08000000"), the operation works fine, but afterwards the CPU either keeps running old code or completely locks up (maybe it just keeps running in the new Flash contents from the old program counter value?). A system reset should be issued after flashing so the new code starts running properly.

For whatever reason, pushing the RESET button on the board doesn't help: the CPU stays locked up. Power cycling the board is the only way to get it going. This is with an F4 board.

stm32vl - Program not starting. Flashing seems correct.

Using gdbserver or st-flash example blink program is successfully loaded:

2012-05-03T20:11:31 INFO src/stlink-common.c: Starting Flash write for VL core id
2012-05-03T20:11:31 INFO src/stlink-common.c: Successfully loaded flash loader in sram

2012-05-03T20:11:31 INFO src/stlink-common.c: Starting verification of write complete
2012-05-03T20:11:31 INFO src/stlink-common.c: Flash written and verified! jolly good!

However run command of gdb just hangs on Starting program:

(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/hadrian/devel/engineer/stexample/blink.elf

COM LED on stm32vl is constantly blinking and nothing else happens.
Using st-flash program is loaded, but after clicking reset button nothing happens either.

It's the same for running from SRAM.

Invocation of st-util:

$ st-util -1
2012-05-03T20:17:50 INFO src/stlink-common.c: Loading device parameters....
2012-05-03T20:17:50 INFO src/stlink-common.c: Device connected is: F1 Medium-density Value Line device, id 0x10016420
2012-05-03T20:17:50 INFO src/stlink-common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2012-05-03T20:17:50 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 connected.

I'm on gentoo.

32l_lcd example, GCC ICE, attribute((naked))

The 32l_lcd example is currently not working. This is noted in the code, which skips the GPIO configuration that would make it possible to use the LCD.

The following line occurs in the code: // fixme: GPIO_Init raises a bug in some gcc toolchains

And indeed, if the GPIO_Init lines are uncommented, attempting to compile gives an internal compiler error (ICE) in GCC:

main.c: In function 'main':
main.c:164:12: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6927
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make: *** [main.o] Error 1

I have done some searching online and have found that, though this is an ICE in GCC, it is not really a problem with GCC. It is triggered by invalid use of the attribute((naked)) keyword. The fix that GCC implementors are considering would simply change this from an ICE to a compile error. The basic issue appears to be that attribute((naked)) is intended for pure assembly functions, and not for the way it is used in the definition of main() in the 32l_lcd example. Because attribute((naked)) causes the compiler to not set up a stack frame for the function, almost any C code would have the potential of triggering the ICE.

So, I did a test, and removed attribute((naked)) from the definition of main(). This "fixed" the ICE issue, but I was unable to start the resulting ELF file on the Discovery board.

Why is attribute((naked)) needed on main(), and how can the project be repaired so that the attribute is not needed?

Thank you,

Roger Dahl

Unable to compile STM32F4 discovery_demo on Linux

When trying to compile STM32F4 discovery_demo on Ubuntu, the following error is seen:
make: *** No rule to make target ../../STM32_USB_Device_Library/core/src/usbd_core.c', needed bySTM32F4-Discovery_Demo.elf'. Stop.

The Makefile points to a group of directories using the wrong capitalization.

«on_trans_done» undeclared

in branch master.
last hash "d2c78b96e05291d21e363c09840cd3cfac1c8961"
OS: Linux Mint 12

Integration with Eclipse IDE

Would be nice to have an Eclipse IDE integration for the stlink utility. I am not sure how one could link the stlink to the eclipse ide..

Would be nice to have this feature

Error: registers may not be the same -- `strexb r0,r0,[r1]'

Upon issuing the make command from stlink/example/libs_stm/build, I received the following error:

make[1]: Entering directory /home/thb/projects/stlink/stlink/example/libs_stm/build' arm-none-eabi-gcc -mcpu=cortex-m3 -Wall -O2 -mlittle-endian -mthumb -mcpu=cortex-m3 -ffreestanding -nostdlib -nostdinc -I../inc/stm32f10x -I../inc/device_support -I../inc/core_support -I../inc/base -c -o ../inc/core_support/core_cm3.o ../inc/core_support/core_cm3.c /tmp/ccVFQZtE.s: Assembler messages: /tmp/ccVFQZtE.s:318: Error: registers may not be the same --strexb r0,r0,[r1]'
/tmp/ccVFQZtE.s:333: Error: registers may not be the same -- strexh r0,r0,[r1]' make[1]: *** [../inc/core_support/core_cm3.o] Error 1 make[1]: Leaving directory/home/thb/projects/stlink/stlink/example/libs_stm/build'
make: *** [all] Error 2

The behavior of strexb and strexh is apparently undefined when the two registers are the same. I have attached a patch that fixes the issue. The problems are on lines 736 and 753 of inc/core_support/core_cm3.c. The : "=r" (result) should be changed to : "=&r" (result), which will cause GCC to use a different register for the target operand

I am using the following tools in my toolchain:
gcc-4.6.2
binutils-2.22
newlib-1.20.0
gdb-7.4

Loading elf fails

Hi,

I have an Ada toolchain, I'm currently using ST's linker and startup code (this will change). I have build an empty project that links and seems to have the right bits at the right places.

I can connect the stlink to the STM32F4DISCOVERY fine with target remote :4242, bbut when I say load blink I get the following:

Loading section .isr_vector, size 0x188 lma 0x8000000
Load failed

I can email you the elf if you would like?

Thanks,
Luke.

How to install stlink in Ubunut

I followed instruction to download stlink in /home/stlink
cd stlink
make

it said " make: *** No targets specified and no makefile found. Stop. "

How to solve this?

dependencies are installed.

Connection to USB Freezing

Hi, just wanted to mention really appreciate all the work you guys are doing.

I am running Fedora 16, and having incredible issues getting stm32f4discovery board working consistently.
I was able to get ./st-util working and was able to load the code, but very quickly the microcontroller stops responding. This is the output on the st-util:

[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)

This occurs continuously, I can't stop the st-util process at all, no matter what I do. The continue command in gdb always hangs the st-util. It is an uninterruptable process. And the only way to fix it is to restart the computer. I couldn't find any way to the get it working without restarting the entire computer. GDB consistently hangs. I seem to get flash working relatively well, it doesn't hang to to much, but it happens after a while. I am having a bit of a tough time figuring everything out, but this is making things far more difficult.

If I disconnect the board and reconnect it the LED close to USB blinks RED. A lot of the issues I can't seem to find info on anywhere, it doesn't looks like its a typical problem. Any help is really appreciated.

Also I noticed the makefiles for all the libraries on the recent update. I really appreciate this as well, for the last couple days I was working on getting the makefiles for the libraries, I had just finished gotten it working, but I can just use yours now.

Again thanks for the help.
TheLegace

gdbserver does not recognize correct CHIPID for F4DISCOVERY

stlink gdbserver does not correctly recognize the chipid for the mcu mounted on my F4DISCOVERY board returning a wrong memory map to gdb, here is the log from st-util:

andrea@andrea-HP-Pavilion-dv6-Notebook-PC:~/st-link/stlink.git/gdbserver$ ./st-util 
Chip ID is 00000000, Core ID is  00000000.
KARL - should read back as 0x03, not 60 02 00 00
init watchpoints
Listening at *:4242...
GDB connected.
recv: qSupported:multiprocess+;qRelocInsn+
query: Supported;multiprocess+;qRelocInsn+
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: qOffsets
query: Offsets;
send: 
recv: g
send: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000220ffffffff30040008
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"><memory-map>  <memory type="rom" start="0x00000000" length="0x0"/>  <memory type="ram" start="0x20000000" length="0x0"/>  <memory type="flash" start="0x08000000" length="0x0">    <property name="blocksize">0x0</property>  </memory>  <memory type="ram" start="0x40000000" length="0x1fffffff"/>  <memory type="ram" start="0xe0000000" length="0x1fffffff"/>  <memory type="rom" start="0x00000000" length="0x0"/>  <memory type="rom" start="0x1ffff800" length="0x8"/></memory-map>
recv: qXfer:memory-map:read::26c,d93
query: Xfer;memory-map:read::26c,d93
Xfer: type:memory-map;op:read;annex:;addr:620;length:3475
send: l
recv: m8000430,4
send: 002103e0
recv: m0,40
send: 0000022031040008d5030008e1030008e9030008f1030008f903000800000000000000000000000000000000010400080d040008000000001904000825040008
recv: qSymbol::
query: Symbol;:
send: 
recv: qTStatus
query: TStatus;
send:

Neither flash loading nor sram loading works in this conditions

STM32F4 writing does not work

After modifying the blink_flash example to work with the STM32F4 cortex-m4 family, I built and tried to write the program to flash. It stalled and outputted this repeatedly:

core status: running

*** stlink_status ***
submit_wait(req)
submit_wait(rep)
status == 0x80
data_len = 5 0x5
80 00 00 00 00

on both the "flash" and "gdbserver" applications. Reading seems to work, but i can't test if the reads are correct without a write to write the resulting file back. All other gdb commands seem to work.

Edit

On further testing, it shows that it writes to ram, but fails to execute. It occasionally gives several different errors and messages.

matthew@matthew-desktop:~/stlink/example/blink$ gdb
GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
Copyright (C) 2011 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 "x86_64-linux-gnu".
For bug reporting instructions, please see:
http://bugs.launchpad.net/gdb-linaro/.
(gdb) tar ext :4242
Remote debugging using :4242
0x00000000 in ?? ()
(gdb) kill
Kill the program being debugged? (y or n) y
(gdb) load blink.elf
Loading section .text, size 0x38 lma 0x20000000
Load failed
(gdb) load blink.elf
Loading section .text, size 0x38 lma 0x20000000
Load failed
(gdb) continue
The program is not being run.
(gdb) kill
The program is not being run.
(gdb) r
Starting program:
Could not write register "orig_eax"; remote failure reply 'E00'
(gdb) load blink.elf
Loading section .text, size 0x38 lma 0x20000000
Start address 0x20000000, load size 56
Transfer rate: 356 bytes/sec, 56 bytes/write.
(gdb) continue
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.

STM32F0 Discovery Flash Error

I'm using the STM32F0 Discovery board. The demo blinker firmware works great, but when I try to burn ChibiOS's demo on there I get the following:

(gdb) load ~/Dropbox/Projects/OpenSource/ChibiOS/demos/ARMCM0-STM32F051-DISCOVERY/build/ch.elf
Loading section startup, size 0xc0 lma 0x8000000
Loading section .text, size 0x67d8 lma 0x80000c0
Loading section .data, size 0xb0 lma 0x8006898
Error finishing flash operation
(gdb) continue
Continuing.
Cannot access memory at address 0xffffffff

When I burn it with the ST-LINK Utility it works fine.

second session on OSX fails without a power cycle

Connecting to an F4 discovery board with st-util works perfectly the first time. However, after exiting with ctrl-c and running again I get errors from libusb. Here is a verbose log from the two executions:

$ ./gdbserver/st-util -v99
2011-11-23T11:41:02 DEBUG src/stlink-common.c: stlink current mode: dfu
2011-11-23T11:41:02 INFO src/stlink-usb.c: -- exit_dfu_mode
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_exit_dfu_mode ***
2011-11-23T11:41:02 DEBUG src/stlink-common.c: stlink current mode: mass
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_enter_swd_mode ***
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** looking up stlink version
2011-11-23T11:41:02 DEBUG src/stlink-common.c: st vid         = 0x0483 (expect 0x0483)
2011-11-23T11:41:02 DEBUG src/stlink-common.c: stlink pid     = 0x3748
2011-11-23T11:41:02 DEBUG src/stlink-common.c: stlink version = 0x2
2011-11-23T11:41:02 DEBUG src/stlink-common.c: jtag version   = 0xe
2011-11-23T11:41:02 DEBUG src/stlink-common.c: swim version   = 0x0
2011-11-23T11:41:02 DEBUG src/stlink-common.c:     notice: the firmware doesn't support a swim interface
2011-11-23T11:41:02 INFO src/stlink-common.c: Loading device parameters....
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_core_id ***
2011-11-23T11:41:02 DEBUG src/stlink-common.c: core_id = 0x00000000
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
2011-11-23T11:41:02 WARN src/stlink-common.c: unknown chip id! 0
Chip ID is 00000000, Core ID is  00000000.
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_force_debug_mode ***
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_reset ***
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002000
KARL - should read back as 0x03, not 60 02 00 00
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002008
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe000200c
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002010
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002014
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002018
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe000201c
init watchpoints
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe000edfc
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0001028
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0001038
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0001048
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0001058
Listening at *:4242...
^C
$ ./gdbserver/st-util -v99
libusb_handle_events() timeout
[!] send_recv
2011-11-23T11:41:14 DEBUG src/stlink-common.c: stlink mode: unknown!
libusb_handle_events() timeout
[!] send_recv
2011-11-23T11:41:17 DEBUG src/stlink-common.c: stlink mode: unknown!
2011-11-23T11:41:17 DEBUG src/stlink-common.c: *** stlink_enter_swd_mode ***
2011-11-23T11:41:17 DEBUG src/stlink-common.c: *** looking up stlink version
libusb_submit_transfer(-9)
[!] send_recv
2011-11-23T11:41:17 DEBUG src/stlink-common.c: st vid         = 0x0000 (expect 0x0483)
2011-11-23T11:41:17 DEBUG src/stlink-common.c: stlink pid     = 0x0000
2011-11-23T11:41:17 DEBUG src/stlink-common.c: stlink version = 0x2
2011-11-23T11:41:17 DEBUG src/stlink-common.c: jtag version   = 0xe
2011-11-23T11:41:17 DEBUG src/stlink-common.c: swim version   = 0x0
2011-11-23T11:41:17 DEBUG src/stlink-common.c:     notice: the firmware doesn't support a swim interface
2011-11-23T11:41:17 INFO src/stlink-common.c: Loading device parameters....
2011-11-23T11:41:17 DEBUG src/stlink-common.c: *** stlink_core_id ***
libusb_submit_transfer(-9)
[!] send_recv
2011-11-23T11:41:17 DEBUG src/stlink-common.c: core_id = 0x00000000
2011-11-23T11:41:17 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_handle_events() timeout
[!] send_recv
2011-11-23T11:41:20 WARN src/stlink-common.c: unknown chip id! 0x8023
Chip ID is 00008023, Core ID is  00000000.
2011-11-23T11:41:20 DEBUG src/stlink-common.c: *** stlink_force_debug_mode ***
libusb_handle_events() timeout
[!] send_recv
2011-11-23T11:41:23 DEBUG src/stlink-common.c: *** stlink_reset ***
libusb_handle_events() timeout
[!] send_recv
2011-11-23T11:41:26 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002000

Cannot load .elf onto STM32F0-Discovery

I just got the new discovery board (STM32F0-Discovery) which has an STM32F051 chip on it. It still uses the ST-LINK version 2, and I can get st-util to connect. From the arm gdb I can continue and halt the firmware on the board, but I cannot load the blink example. It gives me "Load Failed".

I did alter the Makefile and main.c of the blink example to include the compiler flags and register mapping for this chip. I think the issue is with st-util talking to the chip. Below you'll find outputs from it, as well as the GDB session. It looks like the chip id is reading 00000000 which is a problem and I'm wondering if there is memory mapping issue? I don't mind lending a hand to bring support for this chip but I'm at a loss as to what to do. Any advice? Thanks!

st-util output:

mike@krusty:~/compile/stlink.git$ ./st-util 
2012-05-30T21:50:25 INFO src/stlink-common.c: Loading device parameters....
2012-05-30T21:50:25 WARN src/stlink-common.c: unknown chip id! 0
Chip ID is 00000000, Core ID is  0bb11477.
KARL - should read back as 0x03, not 60 02 00 00
init watchpoints
Listening at *:4242...
GDB connected.
recv: qSupported:multiprocess+;qRelocInsn+
query: Supported;multiprocess+;qRelocInsn+
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: 060000003817000018000000000000c00a000000010000000100000038170000ffffffffffffffffffffffffffffffffffffffffe80300206f010008f6010008
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"><memory-map>  <memory type="rom" start="0x00000000" length="0x0"/>  <memory type="ram" start="0x20000000" length="0x0"/>  <memory type="flash" start="0x08000000" length="0x0">    <property name="blocksize">0x0</property>  </memory>  <memory type="ram" start="0x40000000" length="0x1fffffff"/>  <memory type="ram" start="0xe0000000" length="0x1fffffff"/>  <memory type="rom" start="0x00000000" length="0x0"/>  <memory type="rom" start="0x1ffff800" length="0x10"/></memory-map>
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: m80001f6,4
send: a1483817
recv: qTStatus
query: TStatus;
send: 
recv: vKill;a410
send: OK
recv: ?
send: OK
cannot recv: -2
mike@krusty:~/compile/stlink.git$

arm-none-eabi-gdb output:

mike@krusty:~/compile/stlink.git/example/blink$ arm-none-eabi-gdb
GNU gdb (Sourcery G++ Lite 2011.03-42) 7.2.50.20100908-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) tar ext :4242
Remote debugging using :4242
0x080001f6 in ?? ()
(gdb) kill
Kill the program being debugged? (y or n) y
(gdb) load blink_F0.elf
Loading section .text, size 0x48 lma 0x20000000
Load failed
(gdb) disconnect
Ending remote debugging.
(gdb)

diff of the blink example files:

diff --git a/example/blink/Makefile b/example/blink/Makefile
index cf7221d..60fab84 100644
--- a/example/blink/Makefile
+++ b/example/blink/Makefile
@@ -12,8 +12,9 @@ DEF_CFLAGS+=-Wl,-Ttext,0x20000000 -Wl,-e,0x20000000
 CFLAGS_VL=$(DEF_CFLAGS) -mcpu=cortex-m3 -DCONFIG_STM32VL_DISCOVERY=1
 CFLAGS_L=$(DEF_CFLAGS) -mcpu=cortex-m3 -DCONFIG_STM32L_DISCOVERY
 CFLAGS_F4=$(DEF_CFLAGS) -mcpu=cortex-m4 -DCONFIG_STM32F4_DISCOVERY=1
+CFLAGS_F0=$(DEF_CFLAGS) -mcpu=cortex-m0 -DCONFIG_STM32F0_DISCOVERY=1

-all: blink_32VL.elf blink_32L.elf blink_F4.elf
+all: blink_32VL.elf blink_32L.elf blink_F4.elf blink_F0.elf

 %.bin: %.elf
    $(OBJCOPY) -O binary $^ $@
@@ -24,6 +25,8 @@ blink_32L.elf: main.c
    $(CC) $(CFLAGS_L) $^ -o $@
 blink_F4.elf: main.c
    $(CC) $(CFLAGS_F4) $^ -o $@
+blink_F0.elf: main.c
+   $(CC) $(CFLAGS_F0) $^ -o $@

 clean:
    rm -rf *.elf
diff --git a/example/blink/main.c b/example/blink/main.c
index b70a136..26fcca0 100644
--- a/example/blink/main.c
+++ b/example/blink/main.c
@@ -58,6 +58,26 @@ static inline void setup_leds(void)
    (1 << (13 * 2)) | (1 << (14 * 2)) | (1 << (15 * 2));
 }

+#elif CONFIG_STM32F0_DISCOVERY
+
+#define GPIOC 0x48000800 /* port C */
+#define GPIOC_MODER (GPIOC + 0x00) /* port mode register */
+#define LED_PORT_ODR (GPIOC + 0x14) /* port output data register */
+
+#define LED_BLUE (1 << 8) /* port C, pin 8 */
+#define LED_GREEN (1 << 9) /* port C, pin 9 */
+#define LED_ORANGE 0
+#define LED_RED 0
+
+void _tmain(void) {
+   main();
+}
+static inline void setup_leds(void)
+{
+  /* configure port 8 and 9 as output */
+  *(volatile uint32_t*)GPIOC_MODER |= (1 << (9* 2)) | (1 << (8 * 2));
+}
+
 #else
 #error "Architecture must be defined!"
 #endif /* otherwise, error */

No System Reset issued prior to flash programming.

Using either GDB server or the 'flash' utility and an STM32F4 Discovery board under Fedora 13 Linux to program an STM32F105RBT6 target processor. The target embedded application uses DMA to continuously load ADC values into SRAM. It appears that during flash programming the DMA peripheral continues to run, overwriting the flash data as it is loaded into SRAM, corrupting a block of 16 bytes in every flash page written and resulting in verification failures.

Attempts to modify the stlink_fwrite_flash() function in src/stlink-common.c to call stlink_reset() and stlink_force_debug(), or to hit the SYSRESETREQ bit in the SBC_AIRCR of the target in an effort to stop the DMA prior to flashing were unsuccessful.

A workaround is to flash twice - first with a binary that is smaller than the location of the corrupted 16-byte block which does not use DMA, then subsequently with the desired target code.

Usage documentation incorrect for ST-LINK/V2

It seems the documentation is incorrect for ST-Link/V2 type boards, e.g. the STM32L-Discovery.

When I run 'st-link', the sg devices are enumerated (/dev/sg0 thru sg2 on my machine), then st-link exits with this error:

philpem@ryoko:~/stm32/stlink$ ./gdbserver/st-util

*** stlink_open [/dev/sg0] ***
Error: the device /dev/sg0 is not a stlink
VID: got 46d2 expect 0483
PID: got 8800 expect 3744

*** stlink_open [/dev/sg1] ***
Error: the device /dev/sg1 is not a stlink
VID: got ff13 expect 0483
PID: got 0d23 expect 3744

*** stlink_open [/dev/sg2] ***
Error: the device /dev/sg2 is not a stlink
VID: got ff41 expect 0483
PID: got 2b50 expect 3744

Number of /dev/sgX devices found: 3
ST-LINK not found

After examining the code, it appears that st-link will not open ST-LINK/V2 devices unless argc == 3, i.e. the following command will work:

philpem@ryoko:~/stm32/stlink/gdbserver$ ./st-util port usb
stlink current mode: mass
*** looking up stlink version
st vid = 0x0483 (expect 0x0483)
stlink pid = 0x3748
stlink version = 0x2
jtag version = 0xe
swim version = 0x0
notice: the firmware doesn't support a swim interface
stlink current mode: mass
stlink current mode: mass

*** stlink_enter_swd_mode ***

*** stlink_read_mem32 ***
data_len = 4 0x4
16 64 18 10

*** stlink_core_id ***
data_len = 4 0x4
77 14 a0 2b

core_id = 0x2ba01477
Chip ID is 00006416, Core ID is 2ba01477.
Device connected: L1 Med-density device
Device parameters: SRAM: 0x4000 bytes, Flash: up to 0x20000 bytes in pages of 0x100 bytes

(and so on, and so forth).

It appears that either the documentation needs updating, or the command line parsing code modifying to match the documentation.

Configure Error

Hi,

I'm on Fedora 16 3.3.7-1.fc16.i686.PAE

When I run ./configure then following error appears :

configure: error: *** Required libusb-1.0 >= 1.0.0 not installed ***

and script stops.

Latest version of libusb is installed :

$ sudo yum install libusb
Loaded plugins: langpacks, presto, refresh-packagekit
Repository google-chrome is listed more than once in the configuration
Package 1:libusb-0.1.3-9.fc16.i686 already installed and latest version
Nothing to do

I did install libusb (version greater than 1.0.0) using source and running script again doesn't resolve the issue.

If I run : sudo yum remove libusb (to remove installed libusb) then it also throws message to remove dependencies mounting to 1GB.

May anyone point out the issue ?

can't write to flash

Hello,

I built from e714623.

:)~/sandbox/embedded/stlink/flash$ sudo ./flash  write ../example/blink_flash/blink.bin 0x8000000
stlink current mode: debug (jtag or swd)
stlink current mode: debug (jtag or swd)
st vid         = 0x0483 (expect 0x0483)
stlink pid     = 0x3748
stlink version = 0x2
jtag version   = 0xe
swim version   = 0x3
stlink current mode: debug (jtag or swd)
stlink current mode: debug (jtag or swd)
  core status: halted
 (2) ***
r_idx ( 2) = 0x00000020
write error, count == 32
run_flash_loader(0x8000000) == -1
stlink_fwrite_flash() == -1

The error message is printed from src/stlink-common.c:1237

st-util does not work with stlink/v1 discovery board after last fixes

Hi,

i tried to run st-util from the current version in the repository but it does not work. Here
is my logfile from the current version which is not working:

Friedrich-Beckmanns-MacBook:gdbserver fritz$ ./st-util -s1 -v99
libusb:info [process_new_device] allocating new device for location 0x04000000
libusb:info [process_new_device] found device with address 1 at 001-05ac-8005-09-00
libusb:info [process_new_device] allocating new device for location 0x24000000
libusb:info [process_new_device] found device with address 1 at 001-05ac-8006-09-00
libusb:info [process_new_device] allocating new device for location 0x24600000
libusb:info [process_new_device] found device with address 2 at 002-05ac-8507-ef-02
libusb:info [process_new_device] allocating new device for location 0x06000000
libusb:info [process_new_device] found device with address 1 at 001-05ac-8005-09-00
libusb:info [process_new_device] allocating new device for location 0x06300000
libusb:info [process_new_device] found device with address 2 at 002-05ac-0237-00-00
libusb:info [process_new_device] allocating new device for location 0x06600000
libusb:warning [process_new_device] could not retrieve device descriptor: device not responding. skipping device
libusb:info [process_new_device] allocating new device for location 0x06630000
libusb:warning [process_new_device] could not retrieve device descriptor: device not responding. skipping device
libusb:info [process_new_device] allocating new device for location 0x06400000
libusb:info [process_new_device] found device with address 5 at 005-0483-3744-00-00
libusb:info [process_new_device] allocating new device for location 0x26000000
libusb:info [process_new_device] found device with address 1 at 001-05ac-8006-09-00
libusb:info [darwin_open] device open for access
2012-01-03T19:36:01 WARN src/stlink-sg.c: Your stlink got into a real weird configuration, trying to fix it!
2012-01-03T19:36:01 DEBUG src/stlink-sg.c: setting new configuration (0 -> 1)
libusb:info [get_endpoints] building table of endpoints.
libusb:info [get_endpoints] interface: 0 pipe 1: dir: 1 number: 1
libusb:info [get_endpoints] interface: 0 pipe 2: dir: 0 number: 2
libusb:info [darwin_claim_interface] interface opened
2012-01-03T19:36:03 DEBUG src/stlink-sg.c: Successfully opened stlinkv1 by libusb :)
2012-01-03T19:36:03 DEBUG src/stlink-common.c: *** stlink_reset ***
2012-01-03T19:36:03 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=2
2012-01-03T19:36:03 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x3 00 00 00 00 00 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status -536854449
libusb:warning [darwin_transfer_status] transfer error: pipe is stalled
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:error [submit_bulk_transfer] bulk transfer failed (dir = In): pipe is stalled (code = 0xe000404f)
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:error [submit_bulk_transfer] bulk transfer failed (dir = In): pipe is stalled (code = 0xe000404f)
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
2012-01-03T19:36:03 WARN src/stlink-sg.c: Receiving failed: -9
data_len = 2 0x2
00 00

2012-01-03T19:36:03 DEBUG src/stlink-sg.c: core reset: unknown
2012-01-03T19:36:03 INFO src/stlink-common.c: Loading device parameters....
2012-01-03T19:36:03 DEBUG src/stlink-common.c: *** stlink_core_id ***
2012-01-03T19:36:03 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=4
2012-01-03T19:36:03 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x22 00 00 00 00 00 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:error [submit_bulk_transfer] bulk transfer failed (dir = In): pipe is stalled (code = 0xe000404f)
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:error [submit_bulk_transfer] bulk transfer failed (dir = In): pipe is stalled (code = 0xe000404f)
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:error [submit_bulk_transfer] bulk transfer failed (dir = In): pipe is stalled (code = 0xe000404f)
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
2012-01-03T19:36:03 WARN src/stlink-sg.c: Receiving failed: -9
data_len = 4 0x4
00 00 00 00

2012-01-03T19:36:03 DEBUG src/stlink-common.c: core_id = 0x00000000
2012-01-03T19:36:03 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=8
2012-01-03T19:36:03 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x36 00 0x20 0x4 0xe0 00 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:error [submit_bulk_transfer] bulk transfer failed (dir = In): pipe is stalled (code = 0xe000404f)
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:error [submit_bulk_transfer] bulk transfer failed (dir = In): pipe is stalled (code = 0xe000404f)
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:error [submit_bulk_transfer] bulk transfer failed (dir = In): pipe is stalled (code = 0xe000404f)
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
2012-01-03T19:36:03 WARN src/stlink-sg.c: Receiving failed: -9
2012-01-03T19:36:03 DEBUG src/stlink-common.c: *** stlink_read_debug32 0 is 0xe0042000
2012-01-03T19:36:03 WARN src/stlink-common.c: unknown chip id! 0
2012-01-03T19:36:03 DEBUG src/stlink-common.c: *** looking up stlink version
2012-01-03T19:36:03 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=6
2012-01-03T19:36:03 DEBUG src/stlink-sg.c: Sending CDB [ 0xf1 00 00 00 00 00 00 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:error [submit_bulk_transfer] bulk transfer failed (dir = In): pipe is stalled (code = 0xe000404f)
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:error [submit_bulk_transfer] bulk transfer failed (dir = In): pipe is stalled (code = 0xe000404f)
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:error [submit_bulk_transfer] bulk transfer failed (dir = In): pipe is stalled (code = 0xe000404f)
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
2012-01-03T19:36:03 WARN src/stlink-sg.c: Receiving failed: -9
2012-01-03T19:36:03 DEBUG src/stlink-common.c: st vid = 0x0000 (expect 0x0483)
2012-01-03T19:36:03 DEBUG src/stlink-common.c: stlink pid = 0x0000
2012-01-03T19:36:03 DEBUG src/stlink-common.c: stlink version = 0x0
2012-01-03T19:36:03 DEBUG src/stlink-common.c: jtag version = 0x0
2012-01-03T19:36:03 DEBUG src/stlink-common.c: swim version = 0x0
2012-01-03T19:36:03 DEBUG src/stlink-common.c: notice: the firmware doesn't support a jtag/swd interface
2012-01-03T19:36:03 DEBUG src/stlink-common.c: notice: the firmware doesn't support a swim interface
2012-01-03T19:36:03 ERROR src/stlink-sg.c: WTF? successfully opened, but unable to read version details. BROKEN!
Error: could not open stlink device
Friedrich-Beckmanns-MacBook:gdbserver fritz$

Here ist the logfile from the working version which includes my fix to read the parameters before the big pull which superseded that fix.

Friedrich-Beckmanns-MacBook:gdbserver fritz$ ./st-util -s1 -v99
libusb:info [process_new_device] allocating new device for location 0x04000000
libusb:info [process_new_device] found device with address 1 at 001-05ac-8005-09-00
libusb:info [process_new_device] allocating new device for location 0x24000000
libusb:info [process_new_device] found device with address 1 at 001-05ac-8006-09-00
libusb:info [process_new_device] allocating new device for location 0x24600000
libusb:info [process_new_device] found device with address 2 at 002-05ac-8507-ef-02
libusb:info [process_new_device] allocating new device for location 0x06000000
libusb:info [process_new_device] found device with address 1 at 001-05ac-8005-09-00
libusb:info [process_new_device] allocating new device for location 0x06300000
libusb:info [process_new_device] found device with address 2 at 002-05ac-0237-00-00
libusb:info [process_new_device] allocating new device for location 0x06600000
libusb:warning [process_new_device] could not retrieve device descriptor: device not responding. skipping device
libusb:info [process_new_device] allocating new device for location 0x06630000
libusb:warning [process_new_device] could not retrieve device descriptor: device not responding. skipping device
libusb:info [process_new_device] allocating new device for location 0x06400000
libusb:info [process_new_device] found device with address 5 at 005-0483-3744-00-00
libusb:info [process_new_device] allocating new device for location 0x26000000
libusb:info [process_new_device] found device with address 1 at 001-05ac-8006-09-00
libusb:info [darwin_open] device open for access
2012-01-03T19:45:17 WARN src/stlink-sg.c: Your stlink got into a real weird configuration, trying to fix it!
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: setting new configuration (0 -> 1)
libusb:info [get_endpoints] building table of endpoints.
libusb:info [get_endpoints] interface: 0 pipe 1: dir: 1 number: 1
libusb:info [get_endpoints] interface: 0 pipe 2: dir: 0 number: 2
libusb:info [darwin_claim_interface] interface opened
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Successfully opened stlinkv1 by libusb :)
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** looking up stlink version
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=6
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf1 00 00 00 00 00 00 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: st vid = 0x0483 (expect 0x0483)
2012-01-03T19:45:17 DEBUG src/stlink-common.c: stlink pid = 0x3744
2012-01-03T19:45:17 DEBUG src/stlink-common.c: stlink version = 0x1
2012-01-03T19:45:17 DEBUG src/stlink-common.c: jtag version = 0xb
2012-01-03T19:45:17 DEBUG src/stlink-common.c: swim version = 0x0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: notice: the firmware doesn't support a swim interface
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Reading current mode...
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=2
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf5 00 00 00 00 00 00 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: stlink current mode: dfu
2012-01-03T19:45:17 INFO src/stlink-sg.c: Current mode unusable, trying to get back to a useful state...
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Attempting to exit DFU mode
2012-01-03T19:45:17 DEBUG src/stlink-sg.c:
*** stlink_exit_dfu_mode ***
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf3 0x7 00 00 00 00 00 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 WARN src/stlink-sg.c: received tag 0 but expected 3
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** looking up stlink version
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=6
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf1 00 00 00 00 00 00 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: st vid = 0x0483 (expect 0x0483)
2012-01-03T19:45:17 DEBUG src/stlink-common.c: stlink pid = 0x3744
2012-01-03T19:45:17 DEBUG src/stlink-common.c: stlink version = 0x1
2012-01-03T19:45:17 DEBUG src/stlink-common.c: jtag version = 0xb
2012-01-03T19:45:17 DEBUG src/stlink-common.c: swim version = 0x0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: notice: the firmware doesn't support a swim interface
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_enter_swd_mode ***
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x20 0xa3 00 00 00 00 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 INFO src/stlink-sg.c: Successfully opened a stlink v1 debugger
2012-01-03T19:45:17 INFO src/stlink-common.c: Loading device parameters....
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_core_id ***
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=4
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x22 00 00 00 00 00 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
data_len = 4 0x4
77 14 a0 1b

2012-01-03T19:45:17 DEBUG src/stlink-common.c: core_id = 0x1ba01477
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=4
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x7 00 0x20 0x4 0xe0 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
data_len = 4 0x4
20 64 01 10

2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=4
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x7 0xe0 0xf7 0xff 0x1f 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
data_len = 4 0x4
80 00 ff ff

2012-01-03T19:45:17 INFO src/stlink-common.c: Device connected is: F1 Medium-density Value Line device, id 0x10016420
2012-01-03T19:45:17 INFO src/stlink-common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2012-01-03T19:45:17 DEBUG gdb-server.c: Chip ID is 10016420, Core ID is 1ba01477.
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_force_debug_mode ***
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=2
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x2 00 00 00 00 00 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: force debug: ok
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_reset ***
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=2
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x3 00 00 00 00 00 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: core reset: ok
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002000
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x8 00 0x20 00 0xe0 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
KARL - should read back as 0x03, not 60 02 00 00
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=4
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x7 00 0x20 00 0xe0 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002008
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x8 0x8 0x20 00 0xe0 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe000200c
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x8 0xc 0x20 00 0xe0 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002010
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x8 0x10 0x20 00 0xe0 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002014
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x8 0x14 0x20 00 0xe0 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002018
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x8 0x18 0x20 00 0xe0 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe000201c
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x8 0x1c 0x20 00 0xe0 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
init watchpoints
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=4
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x7 0xfc 0xed 00 0xe0 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe000edfc
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x8 0xfc 0xed 00 0xe0 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0001028
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x8 0x28 0x10 00 0xe0 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0001038
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x8 0x38 0x10 00 0xe0 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0001048
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x8 0x48 0x10 00 0xe0 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
2012-01-03T19:45:17 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0001058
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending usb m-s cmd: cdblen:10, rxsize=0
2012-01-03T19:45:17 DEBUG src/stlink-sg.c: Sending CDB [ 0xf2 0x8 0x58 0x10 00 0xe0 0x4 00 00 00]
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 2 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
libusb:info [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
libusb:info [ep_to_pipeRef] pipe 1 on interface 0 matches
libusb:info [darwin_async_io_callback] an async io operation has completed
libusb:info [op_handle_events] checking fd 4 with revents = 0
libusb:info [op_handle_events] checking fd 6 with revents = 1
libusb:info [darwin_handle_callback] handling bulk completion with kernel status 0
Listening at *:4242...

Regards

Friedrich

Doesn't work with STM32L discovery

I know it's not the same board, but I thought changing the usb PIDs would be enough. Apparently, it's not. I don't actually have an STM32VL discovery board to compare it to either, so who knows? Here's an lsusb -v for posterity....

karl@tera:~/src/stlink-git$ lsusb -v -d 483:3748

Bus 001 Device 022: ID 0483:3748 SGS Thomson Microelectronics 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0483 SGS Thomson Microelectronics
  idProduct          0x3748 
  bcdDevice            1.00
  iManufacturer           1 STMicroelectronics
  iProduct                2 STM32 STLink
  iSerial                 3 S�l�H�WQ%���
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              4 ST Link
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

32l_lcd example works but output is garbled

I've just tried to use the example in the directory examples/32l_lcd on a STM32l discovery board. So far it works just fine, but the output appears garbled—at the end of the display some blocks light up (that probably shouldn't). Single stepping shows, that the display is blanked just fine, the conversion logic is probably broken.

Here are some pictures:

flashing: Impossible to flash large file on stm32f4

If I flash a file of 0x74000 size with the following command

st-flash write file.bin 0x08080000

I obtain the following error:

2012-03-09T15:48:20 INFO src/stlink-common.c: Loading device parameters....
2012-03-09T15:48:20 INFO src/stlink-common.c: Device connected is: F4 device, id 0x20006411
2012-03-09T15:48:20 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
2012-03-09T15:48:20 INFO src/stlink-common.c: Ignoring 1 bytes of Zeros at end of file
2012-03-09T15:48:20 INFO src/stlink-common.c: Attempting to write 475135 (0x73fff) bytes to stm32 address: 134742016 (0x8080000)
2012-03-09T15:48:20 WARN src/stlink-common.c: unaligned addr or size
stlink_fwrite_flash() == -1

Ciao Angelo

Flash utility very slow on OS X 10.6

Hi All

THANKYOU for providing this utility. It's really appreciated!

I'm running Snow Leopard, and am finding the flash utility (last week's version) really slow when writing to STM32F4Discovery board. I'm playing with the audio example, which generates a 1MB binary, which takes about 20mins to download to the device. When using the ST-Link utility (the official ST one) on Windows, it downloads in 1-2 mins.

Is there a compilation flag, or something I'm missing that would speed things up?

Thanks!
Etienne

cant write to stm32l discovery board. may be a dead board

Been trying to flash the stm32l discovery board with blink_flash sample program. Git pulled the latest code but it is still dead. Turning log onto full I get this

2012-03-08T07:29:54 DEBUG src/stlink-common.c: stlink current mode: dfu
2012-03-08T07:29:54 INFO src/stlink-usb.c: -- exit_dfu_mode
2012-03-08T07:29:54 DEBUG src/stlink-common.c: *** stlink_exit_dfu_mode ***
2012-03-08T07:29:54 DEBUG src/stlink-common.c: stlink current mode: mass
2012-03-08T07:29:54 DEBUG src/stlink-common.c: *** stlink_enter_swd_mode ***
2012-03-08T07:29:54 DEBUG src/stlink-common.c: *** stlink_reset ***
2012-03-08T07:29:54 INFO src/stlink-common.c: Loading device parameters....
2012-03-08T07:29:54 DEBUG src/stlink-common.c: *** stlink_core_id ***
2012-03-08T07:29:54 DEBUG src/stlink-common.c: core_id = 0x00000000
2012-03-08T07:29:54 DEBUG src/stlink-common.c: *** stlink_read_debug32 e0042000 is 0xe0042000
2012-03-08T07:29:54 WARN src/stlink-common.c: chip_id=0xe0042000
2012-03-08T07:29:54 WARN src/stlink-common.c: unknown chip id! 0xe0042000
2012-03-08T07:29:54 DEBUG src/stlink-common.c: *** looking up stlink version
2012-03-08T07:29:54 DEBUG src/stlink-common.c: st vid = 0x0483 (expect 0x0483)
2012-03-08T07:29:54 DEBUG src/stlink-common.c: stlink pid = 0x3748
2012-03-08T07:29:54 DEBUG src/stlink-common.c: stlink version = 0x2
2012-03-08T07:29:54 DEBUG src/stlink-common.c: jtag version = 0xe
2012-03-08T07:29:54 DEBUG src/stlink-common.c: swim version = 0x0
2012-03-08T07:29:54 DEBUG src/stlink-common.c: notice: the firmware doesn't support a swim interface
2012-03-08T07:29:54 DEBUG src/stlink-common.c: stlink current mode: debug (jtag or swd)
2012-03-08T07:29:54 DEBUG src/stlink-common.c: stlink current mode: debug (jtag or swd)

7 o.addr=8000000 base=0 size=0
2012-03-08T07:29:54 DEBUG src/stlink-common.c: *** stlink_exit_debug_mode ***
2012-03-08T07:29:54 DEBUG src/stlink-common.c: *** stlink_write_debug32 a05f0000 to 0xe000edf0
2012-03-08T07:29:54 DEBUG src/stlink-common.c: *** stlink_close ***

printing out what is going on at the >>7 line I can see that the chip is just ignored. :(

I am concerned because I had plugged in rather a high current drawing TTL device onto the board that could have blown in. (CPU is slightly warm to the touch).

Or am I missing something?