Hi Paul,
It’s very hard to get consistent results.
I am using Okdo E1 Evaluation Board which has an onboard CMSIS-DAP programmer.
It am experiencing issues with PyOCD as well (programs one out of 3 times).
I found out that flash erase works, however after flash erase_address
0x00000000 0x98000, I cannot connect anymore with OpenOCD ( If I do erase from
0x00008000, it will occasionally connect after erase).
S: Info : CMSIS-DAP: SWD supported
S: Info : CMSIS-DAP: Atomic commands supported
S: Info : CMSIS-DAP: FW Version = 1.10
S: Info : CMSIS-DAP: Serial# = 1402B011
S: Info : CMSIS-DAP: Interface Initialised (SWD)
S: Info : SWCLK/TCK = 1 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
S: Info : CMSIS-DAP: Interface ready
S: Info : clock speed 1000 kHz
S: Info : SWD DPIDR 0x6ba02477
S: Error: [lpc55xx.cpu] Could not find MEM-AP to control the core
S: Error: [lpc55xx.cpu] Examination failed
S: Warn : target lpc55xx.cpu examination failed
S: Info : starting gdb server for lpc55xx.cpu on 50000
S: Info : Listening on port 50000 for gdb connections
S: Info : accepting 'gdb' connection on tcp/50000
S: Error: Target not examined yet
S: Error executing event gdb-attach on target lpc55xx.cpu:
S: Error: Target not examined yet
S: Error: Unknown LPC55xx variant and ROM API table address not specified
S: Error: auto_probe failed
S: Error: Connect failed. Consider setting up a gdb-attach event for the target
to prepare target for GDB connect, or use 'gdb_memory_map disable'.
S: Error: attempted 'gdb' connection rejected
After that I can only connect with PyOCD:
S: 0002357 I required flash area is erased [target_lpc5500]
S: [---|---|---|---|---|---|---|---|---|——]
S: 0002430 I required flash area is erased [target_lpc5500]
Once connected with PyOCD, I am able to connect (attach) again with OpenOCD
S: Info : SWD DPIDR 0x6ba02477
S: Info : [lpc55xx.cpu] Cortex-M33 r0p3 processor detected
S: Info : [lpc55xx.cpu] target has 8 breakpoints, 4 watchpoints
S: Info : [lpc55xx.cpu] Examination succeed
S: Info : starting gdb server for lpc55xx.cpu on 50000
S: Info : Listening on port 50000 for gdb connections
S: Info : accepting 'gdb' connection on tcp/50000
G: Note: automatically using hardware breakpoints for read-only addresses
mon flash erase_check 0
G: keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not
sent! (1668 ms). Workaround: increase "set remotetimeout" in GDB
G: successfully checked erase state
G: Bank is erased
And when trying to program an erased part:
S: Info : Listening on port 50000 for gdb connections
S: Info : accepting 'gdb' connection on tcp/50000
G: Note: automatically using hardware breakpoints for read-only addresses.
load
/Volumes/Data/VScode/DAPlink/DAPLink/projectfiles/make_gcc_arm/lpc55s69_bl/build/lpc55s69_bl.elf
G: Error erasing flash with vFlashErase packet
Error erasing flash with vFlashErase packet (from interpreter-exec console
"load
/Volumes/Data/VScode/DAPlink/DAPLink/projectfiles/make_gcc_arm/lpc55s69_bl/build/lpc55s69_bl.elf")
mon reset init
G: [lpc55xx.cpu] target was in unknown state when halt was requested
G: SWD DPIDR 0x6ba02477
{"output":"","token":19,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}
load
/Volumes/Data/VScode/DAPlink/DAPLink/projectfiles/make_gcc_arm/lpc55s69_bl/build/lpc55s69_bl.elf
G: Error erasing flash with vFlashErase packet
Error erasing flash with vFlashErase packet (from interpreter-exec console
"load
/Volumes/Data/VScode/DAPlink/DAPLink/projectfiles/make_gcc_arm/lpc55s69_bl/build/lpc55s69_bl.elf")
After attaching with PyOCD (and disconnecting) and reconnecting OpenOCD:
S: Info : accepting 'gdb' connection on tcp/50000
load
/Volumes/Data/VScode/DAPlink/DAPLink/projectfiles/make_gcc_arm/lpc55s69_bl/build/lpc55s69_bl.elf
G: Loading section .interrupts, size 0x400 lma 0x0
G: Loading section .text, size 0x9160 lma 0x400
G: Loading section .ARM, size 0x8 lma 0x9560
G: Loading section .init_array, size 0x4 lma 0x9568
G: Loading section .fini_array, size 0x4 lma 0x956c
G: Loading section .data, size 0x248 lma 0x9570
G: Loading section .fill, size 0x6848 lma 0x97b8
G: Start address 0x000004bc, load size 65536
G: Transfer rate: 16 KB/sec, 6553 bytes/write.
{"output":"","token":17,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}
mon verify_image
/Volumes/Data/VScode/DAPlink/DAPLink/projectfiles/make_gcc_arm/lpc55s69_bl/build/lpc55s69_bl.elf
G: verified 65536 bytes in 0.432980s (147.813 KiB/s)
Op 6 mei 2025, om 18:52 heeft Paul Fertser <fercer...@gmail.com> het volgende
geschreven:
On Tue, May 06, 2025 at 04:24:45PM +0000, Rolf | Onethinx wrote:
Unfortunately flash programming doesn’t work. It might have seemed that it was
working because the flash was already programmed.
...
S: ** Programming Started **
S: Warn : Adding extra erase range, 0x0003fc00 .. 0x0003ffff
S: Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive
packet not sent! (9791 ms). Workaround: increase "set remotetimeout" in GDB
S: ** Programming Finished **
S: Warn : negative acknowledgment, but no packet pending
But it didn't complain about anything, it's not possible to tell from
this output if programming failed or not.
Since you're using GDB anyway can you try "load" and then
"compare-sections"? And when you're using "program" can you add
"verify" parameter to its options so we see if anything at all was
written? Are you sure flash wasn't somehow "protected" or "locked" by
firmware itself or other tools?
Does erasing flash work?
On the hardware I had access to I did many tests and flashing was
indeed functional so I'm quite confused by your results.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
