Olivier Gay [Sun, 27 Oct 2013 15:17:08 +0000 (16:17 +0100)]
Restore gdb-server cleanup handlers for MinGW
There were removed in my previous commit 5851dee due
to compilation errors. It actually appears these signals
are supported in MinGW but there was an include error for
MinGW, this commit fixes it.
Olivier Gay [Sun, 27 Oct 2013 14:19:29 +0000 (15:19 +0100)]
Fix build issues with MinGW
Remove st-term from the list of the targets for MinGW.
st-term uses termios and would require a rewrite to have
it compile on MinGW. Also remove cleanup signal handlers
in gdb-server for MinGW to compile.
Michael Pratt [Wed, 6 Mar 2013 20:24:15 +0000 (15:24 -0500)]
Add option to not reset board on connect
'-n' in st-util will cause it to skip the reset step, and thus allow you
to begin debugging at whatever point the code may currently be at.
Adding this feature required changing the stlink_open functions to
accept a reset flag that tells them whether or not to reset after
connecting. Skipping reset does not seem to have any adverse effects on
stlink usb devices. Unfortunately, I have to stlink v1 devices to test.
Burns [Fri, 21 Jun 2013 21:36:15 +0000 (17:36 -0400)]
Support for STM32L1 medium-plus chips with chip id 0x427
-Changed the STM32L1 "medium plus" (id 0x436) support to be called HIGH.
-Added the device id 0x427 and call it medium plus.
-Gave the loader more time so it stopped timing out and thinking it failed.
-Added st-term to .gitignore
Note: ST seems to call some chips with 436 medium plus and some high. It seemed
easier to name 436 high and 427 medium plus.
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.
Jack Peel [Sat, 6 Apr 2013 00:55:19 +0000 (17:55 -0700)]
Add SIGTERM signal handler to also call cleanup
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!!
Jack Peel [Fri, 5 Apr 2013 16:06:26 +0000 (09:06 -0700)]
Add support for the STM32L1 Medium density device flash size calculation
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!
Jack Peel [Wed, 3 Apr 2013 23:43:13 +0000 (16:43 -0700)]
Add Support for STM32L1xx Medium Plus and High density Devices
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)
Ian Griffiths [Thu, 21 Mar 2013 16:28:15 +0000 (16:28 +0000)]
Limited DMA clearing to STM32F4, removed fatal error for flash loading.
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.
Ian Griffiths [Wed, 20 Mar 2013 13:01:49 +0000 (13:01 +0000)]
Added lock state check to stlink_erase_flash_page.
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.
Michael Pratt [Wed, 6 Mar 2013 21:15:15 +0000 (16:15 -0500)]
Add SIGINT handler for stlink cleanup
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.
Michael Pratt [Wed, 6 Mar 2013 17:52:12 +0000 (12:52 -0500)]
Add persistence support to gdb-server
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.
Bring the support for STM32 F3 Discovery board (ARM Techcon 2012)
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: