You are reading a single comment by @fanoush and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@fanoush
The swd in nrf52 is designed for up to 8MHz https://devzone.nordicsemi.com/f/nordic-q-a/54961/nrf52840-programming-speed , typically SWD dongles use 1MHz, limit is probably also related to wire length. I did not see issues previously with bangle2/Q3 charging cable and SWD dongles used with openocd running at 1MHz. The overhead of the protocol is 14 extra bits with each 32bit transfer https://github.com/MarkDing/swd_programing_sram#32-successful-transaction-operation , when reading/writing in automatic incremental mode just one packet is needed to send/receive next 32bit value.
Of course the software must match the speed. Also from initial testing I see the MEM-AP transfer from memory produce some initial timeouts - not sure how many of those there will be when pushing the interface to maximum. When CPU is not stopped the transfer shares the AHB bus with code that is running and needs to use RAM/flash for that , see picture at https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/dif.html?cp=4_2_0_15#debugandtrace
Not sure if any of that answered the question, though ;-)
Direct writing to (internal) flash over SWD can be either done by toggling flash NVMC registers directly or another way that openocd is using is to upload some flashing code stub to ram then just send data block to ram and let the CPU do the flashing. However I suppose the easiest way is to make espruino console working over SWD and then push data over it.