Minimum clock speed for SWD?

CurtisHx gravatar image

asked 2016-12-22 17:48:39 +0100

We're trying to bit-bang SWD to program an nRF52832, and we're running into some problems getting the nRF52 to respond. One theory is we're not generating a high enough clock speed. Right now we're using a 10khz clock.

What's the minimum clock speed for SWD? Where can I find electrical specifications in general for SWD? I can't find them in the ARM Debug Interface Architecture Specification

edit retag flag offensive close delete report spam

2 answers

Sort by ยป oldest newest most voted
Aryan gravatar image

answered 2016-12-23 08:51:52 +0100

updated 2016-12-23 08:52:21 +0100

I see that this information seems to be missing in the nRF52 manuals. I would assume that it should be the same requirement as for nRF51 which was a minimum of 125 KHz mentioned here. 10 KHz that you have on your system seems too less.

edit flag offensive delete publish link more



Thanks for checking that out. Turns out the code wasn't correctly calculating the parity bit, and the nRF52 wasn't acking per the SWD spec. So it looks like we can use our 10khz clock, just with the understanding that we're outside of the spec and things may not work correctly.

CurtisHx ( 2016-12-23 15:16:46 +0100 )editconvert to answer


What processor are you using to bit-bang the SWD.

Only managing 10khz is quite slow for modern processors.

I know bit-banged I2C on a 72Mhz STM32F103 can be made to run at 400kHz without too many optimisations.

Are you running on an old slow processor ??

Roger Clark ( 2017-08-13 13:01:24 +0100 )editconvert to answer
slowcoder gravatar image

answered 2017-08-12 12:12:39 +0100

In case anyone else plays around with very slow SWD (and, as this is the only relevant discussion on the internet about the _slowest_ SWD speed), I just discovered that the nRF51 does indeed _not_ ACK (or, clock out _anything_) if you're running at 18KHz. After clocking up to 190KHz (no other changes), the nRF51 started to respond.

edit flag offensive delete publish link more


If one uses openocd to do the bitbanging and that process is preempted for a short while, causing swd clock to be stopped for a moment before continuing, do you think that could be an issue?

Emil Lenngren ( 2017-08-13 00:01:58 +0100 )editconvert to answer

I guess that depends on what state SWCLK/SWDIO is in when it stops, and for how long a "moment" is. If both lines are low for 100uS or longer (not _entirely_ sure about this value), I guess the nRF51 could interpret it as a reset due to the shared SWDIO/nRESET functionality.

However, if you're just talking about very minor changes in timing, it seems to handle that well. Every now and then the MCU that I'm implementing this on wants to service an IRQ or something else, and I get a SWCLK that's about twice as long. The nRF51 seems to handle this just fine.

slowcoder ( 2017-08-13 09:48:07 +0100 )editconvert to answer

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer. Do not ask a new question or reply to an answer here.

[hide preview]

Question Tools

1 follower


Asked: 2016-12-22 17:48:39 +0100

Seen: 227 times

Last updated: aug. 12

Related questions