'-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.
-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.
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.
texane