You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I enabled -Ddebug_output=true and adjusted DEBUG_TARGET to get complete in-probe diagnostic logging. Per grabserial a page erase took 38ms on average -- 2048 byte pages, 512+512 KiB in two banks. I wrote a test project in AT32IDE and experimented with .rodata blob sizes to iterate quickly (this is also a flash readback test I used to validate some of my upstream AT32F4 PRs), and around 60 KiB is the bug trigger threshold.
Basically BMFlash issues a RSP packet of vFlashErase:8000000:5800 then times out waiting 500ms for a response, despite the probe being actively busy polling on FPEC registers. Judging by ttyBmpTarg output it completes erasing all requested pages, so that target layer engine works -- but the target stays erased (and halted), with BMP awaiting further instructions. I measured ~10 seconds during a per-page erase (effectively mass erase, but that'd be a different command), which is 20 times more than this timeout.
Consider either increasing this erase timeout, which postpones the problem, or write a loop to issue vFlashErase commands per single page, these will likely complete fast enough.
Problem 2.
I was using highest frequency in SWD mode that is available in-tree, around 6-8 MHz, but it's only relevant for write and readback phases, if any. Of course, after writing a big project (ELF file with 512 KiB of loadable content), then BMFlash throws another error right at the end of verification pass, but I wanted to measure timings.
notice(BMPERR_FLASHCRC, "Segment %d data mismatch", segment);
At the best read speed (bmd_crc32 in-probe reporting) of 125-150 KiB/s it takes about 4 seconds per bank to verify, which is slightly more than 3000ms. Please bump timeout.
Problem 3. There is a stray clock() remaining in bmflash.c whereas everything else was migrated to custom timestamp().
sprintf(msg, "Completed in %.1f seconds\n", (tstamp_stop-state->tstamp_start) / 1000.0);
At minimum, please replace to timestamp(), I tried it and this works. At maximum, consider also refactoring timestamp() from gettimeofday() to clock_gettime(CLOCK_MONOTONIC, ) because otherwise timestamp could jump during daylight savings time switch and from NTP adjtime corrections.
Problem 4. Blackpill-f4 in default in-tree configuration does not support qRcmd,tpwr monitor commands, and per RSP returns a Nak with 0 length payload, this triggers an assert somewhere, I had to #if 0 out this block. There is an optional shield with enables this command, so behaviour is not universal.
BMFlash: when file given on the command line is not found, flag this as an error, but do not drop back to most recent file.
BMSerial: option for "presets" file (for quickly changing between configurations).
Adaptive timeouts om lengthy GDB-RSP operations, addresses issue #46.
Help dialogs: fix for line-break, better calculation for vertical scrolling.
Signed-off-by: Thiadmer Riemersma <[email protected]>
Fix timestamp function used for printing time spent uploading (courtesy ALTracer, issue #46).
Use monotonic timer (in Linux) for timestamp function (courtesy ALTracer, issue #46).
Adaptive timeout for firmware CRC calculation (issue #46).
Avoid 'enumeration value not used' warnings.
Signed-off-by: Thiadmer Riemersma <[email protected]>
Hello again.
BMFlash is unusable (without tweaks) against
blackpill-f411ce
platform and AT32F403A target.Problem 1. vFlashErase throws an "Flash erase failed" error before even proceeding to vFlashWrite.
Black-Magic-Probe-Book/source/bmp-support.c
Lines 920 to 924 in 6010ef3
I enabled
-Ddebug_output=true
and adjustedDEBUG_TARGET
to get complete in-probe diagnostic logging. Per grabserial a page erase took 38ms on average -- 2048 byte pages, 512+512 KiB in two banks. I wrote a test project in AT32IDE and experimented with .rodata blob sizes to iterate quickly (this is also a flash readback test I used to validate some of my upstream AT32F4 PRs), and around 60 KiB is the bug trigger threshold.Basically BMFlash issues a RSP packet of
vFlashErase:8000000:5800
then times out waiting 500ms for a response, despite the probe being actively busy polling on FPEC registers. Judging by ttyBmpTarg output it completes erasing all requested pages, so that target layer engine works -- but the target stays erased (and halted), with BMP awaiting further instructions. I measured ~10 seconds during a per-page erase (effectively mass erase, but that'd be a different command), which is 20 times more than this timeout.Consider either increasing this erase timeout, which postpones the problem, or write a loop to issue vFlashErase commands per single page, these will likely complete fast enough.
Problem 2.
I was using highest frequency in SWD mode that is available in-tree, around 6-8 MHz, but it's only relevant for write and readback phases, if any. Of course, after writing a big project (ELF file with 512 KiB of loadable content), then BMFlash throws another error right at the end of verification pass, but I wanted to measure timings.
Black-Magic-Probe-Book/source/bmp-support.c
Lines 1015 to 1023 in 6010ef3
At the best read speed (bmd_crc32 in-probe reporting) of 125-150 KiB/s it takes about 4 seconds per bank to verify, which is slightly more than 3000ms. Please bump timeout.
Problem 3. There is a stray clock() remaining in bmflash.c whereas everything else was migrated to custom timestamp().
Black-Magic-Probe-Book/source/bmflash.c
Lines 1924 to 1925 in 6010ef3
At minimum, please replace to timestamp(), I tried it and this works. At maximum, consider also refactoring timestamp() from
gettimeofday()
toclock_gettime(CLOCK_MONOTONIC, )
because otherwise timestamp could jump during daylight savings time switch and from NTP adjtime corrections.Problem 4. Blackpill-f4 in default in-tree configuration does not support
qRcmd,tpwr
monitor commands, and per RSP returns a Nak with 0 length payload, this triggers an assert somewhere, I had to#if 0
out this block. There is an optional shield with enables this command, so behaviour is not universal.bmp-bmflash.log
Success screenshot
Worktree differences
The text was updated successfully, but these errors were encountered: