diff options
| author | Andreas Fritiofson <andreas.fritiofson@gmail.com> | 2010-04-17 01:03:39 +0200 |
|---|---|---|
| committer | Øyvind Harboe <oyvind.harboe@zylin.com> | 2010-04-20 08:55:48 +0200 |
| commit | ddf7aabc6726956315f21394559ba1c543fcbf36 (patch) | |
| tree | 660c32c8b3bcfb94f45b45f7e9c099410a1a4e4c /testing/examples/SAM7X256Test | |
| parent | 620310bcc64a0ba9103c4c05300fe9d25cc92b12 (diff) | |
| download | openocd+libswd-ddf7aabc6726956315f21394559ba1c543fcbf36.tar.gz openocd+libswd-ddf7aabc6726956315f21394559ba1c543fcbf36.tar.bz2 openocd+libswd-ddf7aabc6726956315f21394559ba1c543fcbf36.tar.xz openocd+libswd-ddf7aabc6726956315f21394559ba1c543fcbf36.zip | |
stm32x: allow flash probe on a running target
If the flash has not yet been probed and GDB connects while the target is
running, the flash probe triggered by GDB's memory map read will fail. In
that case the returned memory map will be empty, causing a subsequent load
from within GDB to fail. There's not much you can do from GDB to recover,
other than a restart; a 'mon reset init' and manual 'mon flash probe' won't
help since GDB has already made up its mind about the memory map.
It seems there's no reason to require the target to be halted when probing
the flash. Remove the check to let a valid memory map be provided to GDB
even when connecting to a running target.
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Diffstat (limited to 'testing/examples/SAM7X256Test')
0 files changed, 0 insertions, 0 deletions