cortexm_initial_halt() repeats the DHCSR write with high values for TRNCNT in
CSW. This is needed to catch a STM32F7 mostly in WFI. While the repeated write
is running, STLINKV3 on a Nucleo-WL55 (V3J7M2B0S0) answers first with
STLINK_SWD_AP_WAIT and on more read if write command is still running with
STLINK_SWD_AP_FAULT. At some point when the last command is finished, normal
STLINK_ERROR_OK indicates finally successful read. Treat STLINK_SWD_AP_FAULT
after STLINK_ERROR_WAIT as STLINK_ERROR_WAIT in that case. STLINK_SWD_AP_FAULT
may still be issued on other invalid accesses and should still be treated as
error in the other possible cases. Fixes#1071.
Rather than casting here, use PRIu32 - as in "%" PRIu32 ".%" PRIu32 - it's undefined behaviour and quite illegal to do the cast as, depending on platform, you'll end up with only some of the bytes in units and tenths written and which ones and what that means will depend on endianess.
"Single" core STM32WLE still sees AP1 but on first scan aborts gracefully
after some errors and on later runs sees AP1 as unusable. Fixes#832.
Decode the Cross trigger interface found on CPU2 on STM32WBxx.
E.g on STM32WXXX AP1 with C2BOOT not set, the AP base registers have valid
values but reading them fails and turns the AP unusable. BMDA reading CIDR
with multiple calls will will loop and finally hang up BMD. Other target
devices may show similar behaviour.
Reading CIDR with a single call allows recovery from in that case and
additional spares target transactions.
Try to look for repeating sectors before reverting to reading the
JEDEC ID of the flash chip. This way we don't interrupt the flash
execution if a valid program is running, but can detect the flash
size if the flash memory has been erased.
F0 needs separation of DMA Interrupts, show problems with 128 Byte USART/DMA
buffers, perhaps caused by the st_usbfs_v2_usb_driver and has no
scb_reset_core.
Ubuntu's default /bin/sh is dash, which does not support the `&>`
redirection syntax. This commit moves version.h generation back into the
Makefile, as 8afaedd had it, but restores compatibility with
GNU Make < 4.0, which 8afaedd, broke. This also fixes building on macOS,
as macOS bundles GNU Make 3.81.
The command can be used either by specifying the length only, or
the start address and the length like so:
monitor erase_sector <length>
monitor erase_sector <start_addr> <length>
If no start address is specified, it will begin erasing from the
start of the flash sector.
There seems to be a bug in the bootrom for the rp2040 which means
that the chip erase command is not accepted. This is because the
CS pin must be released (set high) directly after sending the chip
erase command (0x60 or 0xC7) (see Winbond W25Q128JV datasheet for
details). Instead the bootrom sends the address after the command,
thus the SPI flash silently ignores the command. Instead, we must
erase each 64KB block one at a time, but thankfull the bootrom
handles this correctly for us.
There are some cases when the this old method for finding the flash
size will fail, such as if the flash chip has been erased with 0xFF
bytes (rather than blank 0x00 bytes). As this is unreliable,
setting the wrong flash size could cause problems when trying to
inspect memory regions which appear to be out of range.
There is also such a thing as blackpill, that uses stm32f1 instead of
stm32f4. At some point we might get support for the original blackpill
and it will force us to change the name then.
The target was building but not including the BMDA binary, as the
build system does not expect a binary that does not end with `.bin`.
Additionally this corrects the BMDA Makefile.inc that was missing the
`all` and `host_clean` targets.
The carbon contains two SoCs, an STM32 (host) and an nRF51 (BLE). The
STM32 implements the probe and allows the board to reprogram its own
radio firmware!
The BMP with hardware version 4 and newer, use option bytes instead of
physical GPIO to encode the hardware version. In some older BMP there is
a chance that the user option byte is set to 255 (0x00FF pattern). This
can throw off the hardware version detection routine.
The hw rev 4 and 5 both have the version stored in the Data1 user option
byte. This frees up the hw rev strapping pins for other uses, ie swtrace
decoding using USART1 RX, and additional peripherals on the SPI bus,
like bulk flash storage and displays.
lock_flash and lock_bootprot currently support only locking the whole flash and locking the maximal leading flash chunk (32k).
An optional numerical parameter is added. It can be specified in decimal or 0x prefixed hexadecimal.
For samd21 'lock_bootprot 0' locks the first 32k of flash while 'lock_bootprot 6' locks the first 512 bytes. 'lock_bootprot 0' is equivalent to 'unlock_bootprot'.
Similarly, 'lock_flash <number>' locks the flash segments corresponding to zeros in the binary representation of the given number.
'lock_flash 0xffff' is equivalent to 'unlock_flash'.
If the optional parameter is not given both commands work as previously.
The SAMD09 CPU is used in boards such as the Adafruit Seesaw. It has a
smaller amount of memory and flash than other SAMD ports.
This was tested with an Adafruit Seesaw. These boards come with preloaded
firmware. As a test, the firmware was dumped and flash was erased. Then,
flash was verified to be all zeroes. Finally, the firmware was loaded
back in:
(gdb) p/x *(unsigned int *)0@32
$8 = {0x20000f88, 0x1db, 0x1d1, 0x1d9, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1d9, 0x0, 0x0, 0xf5, 0x1081, 0x1d9, 0x1d9, 0x1d9, 0x1d9, 0x1d9, 0x1d9, 0x1d9, 0x0, 0x1d9, 0x1d9, 0x25e9, 0x0,
0x0, 0x1d9, 0x1d9, 0x1d9}
(gdb) dump ihex memory flash.ihex 0 8192
(gdb) mon erase_mass
Erase successful!
(gdb) p/x *(unsigned int *)0@32
$9 = {0xffffffff <repeats 32 times>}
(gdb) load flash.ihex
Loading section .sec1, size 0x2000 lma 0x0
Start address 0x00000000, load size 8192
Transfer rate: 5 KB/sec, 910 bytes/write.
(gdb) p/x *(unsigned int *)0@32
$10 = {0x20000f88, 0x1db, 0x1d1, 0x1d9, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1d9, 0x0, 0x0, 0xf5, 0x1081, 0x1d9, 0x1d9, 0x1d9, 0x1d9, 0x1d9, 0x1d9, 0x1d9, 0x0, 0x1d9, 0x1d9, 0x25e9, 0x0,
0x0, 0x1d9, 0x1d9, 0x1d9}
(gdb)
Signed-off-by: Sean Cross <sean@xobs.io>
Various SAMD devices have different amounts of memory. Up until now, all
SAMD devices have had the same amount, and therefore this value was
hardcoded to 32k of RAM and 256k of flash.
Add a parameter to the description field and set it to default to the
previous values. Use this description field when adding memories to the
target definition.
Signed-off-by: Sean Cross <sean@xobs.io>
Maciej Musiał
Uwe Bonnes
SId Price
dragonmux
James Turton
Rafael Silva
Jonathan Giles
Mikaela Szekely
Piotr Esden-Tempski
cyber-murmel
Dag Ågren
Gareth McMullin
Rafael Silva
Jonas Jelten
Koen De Vleeschauwer
Daniel Thompson
Michal Moskal
mean
Mike Ditto
Fabrice Prost-Boucle
arpadbuermen
Nicolas Schodet
Paul Mulders
Frank Kunz
Sean Cross