The chip IDs are defined up top and those macros are used throughout the
code so let's remove the magic numbers in .chip_id so that everything is
using the macros.
No functionality changes, just a find/replace.
When stopping st-util under Eclipse as an external tool the st-util
receives a SIGTERM signal, and would not return the device to
usb mass storage mode. This change now calls cleanup in the SIGTERM handler too!!
In devices before "Rev X" the flash size register is 0 so we assume 128k
Note that "Rev X" is a LATER revision than "Rev Y" and others that might
seem like they are later!
Using reference RM0038 Rev 7
The flash size register moved
and the values in the registers changed their meaning
Note that Medium Plus and High density deives have the
same device ID, but only the Medium Plus definition is
used in the code (the High comes along for free)
Commit 0ed3907 added the clearing of DMA registers that was preventing
programming (see issue #74), however it uses hardcoded addresses of the
DMA registers on the STM32F4. This seems to prevent the flashing and
verification on STM32L1, as the registers only partly cover the range
zeroed. So the DMA clearing has been limited to the STM32F4
microcontroller.
Additionally, sometimes, typically directly after erases, a 'flash
loader run error' will occur that terminates the writing. This is not
necessary, as the writing is successfully performed by page writing
(line 1581 onwards of stlink-common.c), and so has been returned to a
error message (see issue #112). There is a comment on line 1574 (added by
Uwe Bonnes in commit 0164043f) that this may happen on blank devices,
and so the fatal error message is the incorrect response.
On the STM32L152 processor, the erase fails for the first page as the
lock is already disabled (with the unlocking code causing the lock to
become re-enabled). This commit adds checking of the lock state and will
only unlock if necessary.
SIGINT causes st-util to immediately exit, without closing the open
stlink. This leaves devices (at least the F4 Discovery) in a state
where they are unable to reset. st-util could still connect and control
them, but a power cycle was required before they could reset on their
own.
A signal handler is added for SIGINT, which performs cleanup and closing
of the open stlink device, allowing it to function normally on
disconnect.
When started with -m, or connected with 'target extended-remote', the
GDB server will not terminate upon disconnection from GDB, instead it
will begin listening for conenctions again.
Starting with extended-remote also has the advantage of allowing 'run'
to be used to reset the target and begin again. Unfortunately, 'start'
is not working properly, as it does not send a reset packet (R), so it
complains when it tries to access memory before it is connected to the
target.
Support was tested by attaching USB cable to USB ST-LINK USB port, starting
./st-util
Which resulted in proper device recognition:
2012-11-03T23:11:25 INFO src/stlink-common.c: Device connected is: F3 device, id 0x10016422
2012-11-03T23:11:25 INFO src/stlink-common.c: SRAM size: 0xa000 bytes (40 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 2048 bytes
Chip ID is 00000422, Core ID is 2ba01477.
Then from GDB, after "target remove localhost:4242", I tested reads:
x/w 0x20000000
And writes:
set {int}0x20000000 1
And ELF loading:
(gdb) load main
Loading section .text, size 0x10 lma 0x20000000
Start address 0x20000000, load size 16
Transfer rate: 410 bytes/sec, 16 bytes/write.
And verified dissasembly (in my case--with Thumb mode) with objdump -d <elf>
output:
(gdb) set arm force-mode thumb
(gdb) x/7i 0x20000000
=> 0x20000000: push {r7}
0x20000002: sub sp, #12
0x20000004: add r7, sp, #0
0x20000006: ldr r3, [r7, #4]
0x20000008: add.w r3, r3, #1
0x2000000c: str r3, [r7, #4]
0x2000000e: b.n 0x20000006
texane