Having a type of flash information has some advantages:
 - Make the code easier to read
 - Make adding family derivatives easier (only add a new entry in header file)
 - Make the backends error propagation easier to implement (less places to fix)

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>

Now that libusb errors are propagated up to stlink API, we can handle these
errors.

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>

As the libusb returns errors, make the backends propagates them so that
callers can decide to continue or stop task execution.

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>

_stlink_usb_target_voltage already returns an error value.
If value return is positive, this is a voltage, if negative this is an error.
Check the return on callers side to inform there is an error in reading the
voltage, instead of notifying of a too low voltage.

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>

This rework is done in order to prepare for propagating errors returned by
libusb.

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>

This rework is done in order to prepare for propagating errors returned by
libusb.

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>

Add st-info to CMakeLists.txt

be quicker about determining erased byte pattern when flashing

make st-flash clean up on sigint/term/segv, make gdb-server clean up on sigsegv.

make usb backend status check work, remove some dead code

use libusb synchronous api

remove empty byte truncation from stlink_fread

clamp gdb memory reads to 0x1800

Stm32 l4 flash fix

st-util: Fix for connecting to running devices

Add memory map for STM32L4

Fix issue where "unknown chip id!" is seen every other time

Previously, even with the reset enabled, st-util would not connect
to a target if it was running. This change will reset the chip
when opening the connection, which allows st-util to connect
successfully.

Signed-off-by: Greg Meiste <w30289@motorola.com>

Signed-off-by: Greg Meiste <w30289@motorola.com>

Previously when running the program, reading the chip version
would fail. Running the program a second time worked. This
sequence is repeated the next time st-flash/st-util is run.

Giving reset 10ms to complete before trying to read the chip
version resolves the issue.

Signed-off-by: Greg Meiste <w30289@motorola.com>

Allow flashing of STM32L4 down to 1.71 V

The STM32L4 specification specifies that VDD can be 1.71 - 3.6 V.

Signed-off-by: Greg Meiste <w30289@motorola.com>

st-util: synchronize cache for stm32f7

This patch handles the cache on the cortex-m7 stm32f7 cpu.
When gdb inserts a soft breakpoint (which is the default for
code in RAM), it replaces an instruction with a breakpoint
instruction.  But if the caches are enabled, the replacement
may be made only in the D-cache.  To reach the I-cache, the
D-cache must be flushed and the I-cache invalidated.

This implementation is coarse: it cleans the whole D-cache
and invalidate the whole I-cache.  It is possible to
track which cache lines have to be cleaned and invalidated.

stm32f7: also send features to gdb.

Do not send a NUL at end of packets to gdb.

So that 'extra' registers (msp, psp, ...) are visible to user.