stm32的swd接口的烧写协议是否公开的呢？

需要用一台好的示波器来抓才能有足够的存储深度，保证你能够过滤掉那个该死的50clock。

按照Arm的手册，每次转换发送方都需要一个TNR---但是我观察JLINK的波形却没有那个该死的TNR。

手册中说异步SWD需要，同步不需要----或者相反，但是我没有找到关于同步异步的描述。

姑且不管他，反正目前忽略掉TNR就能够读到该死IDR。

另外JLINK的复位时序很奇怪，大致是

70clk High，0xe79e（注意，SWD是LSB First），

70clk High，0xedb6（这里很奇怪，找不到描述），

70clkHigh，16clk Low，0xa5，

注意这里按照协议应该是TNR位-但是没有实际观测到这个位，

0b100（ACK-OK），0xba01477……

实际测试，不额外增加那个奇怪的0xedb6也能够照常读出IDR。

另外要注意，设备端的数据最哈哦在CLK的下降沿读取，或者上升沿过后延时1/2bit后读取。

如果想要深究，可以去sourceforge.net去下载SWD Lib，以及openOCD，两者对照着来会很方便。

利用好bitband写程序会很舒服，尤其是处理SWD的位流，一个int32指针跳起来很爽，并且是LSB First的结构。

完全没有任何障碍的。

另外发现在读IDR后，其他的读写命令的ACK后面，SWDIO会有两个bits的缓慢上升波形，

并且在clk的下降沿被Target拉底，按照格式硬套的话，这两个位应该忽略掉。

目前还没发现对于这两个位的说法。

有的时候能够看到当JLink读取信息的最后会把本该由Target发送的parity拉低，忽略掉。

还有需要注意的是，似乎除了读IDR，CTRL，ABOUT这三个寄存器外，其他的寄存器读取都有一个数据帧的延迟。

比如你发起第一个读取贞，读到的数据没有意义。

第二个读取帧，读到的是第一次的地址对应的数据，依次类推。

硬件上，SWDIO的上拉要足够强，不然上升沿可能不够陡峭，我现在用的是2.2k，还凑合。

看到SWD LIB的源码里面是按照8位读写，32位读写的方式来做的。

也就是说，只要控制好SWCLK，并且能够保证不丢掉任何SWDIO位信息，用SPI也可以模拟出SWD的时序。

这部分参考了SourceForge的LibSwd项目，该项目是开源的，写的很严谨，代码风格也很好，强烈大家下来看看。

原始代码是四个函数，读，写，8，32.我归结到两个函数，用了bitband结构所以入口就简单了一些，缓冲区和位数即可

intiLibSwdMosi(unsignedint*pBits,unsignedintiLen){unsignedinti;for(i=0;i

看到return（0）你想到了什么？
嘿嘿，本来我是采用定时器来控制clk的，这样就需要考虑程序运行出错的返回代码。
后来发现这样很傻，就该成死等了。
这样就不需要返回异常信息了，但是为了保持形式上的统一，函数还是带有返回值的样子。hoho
这里是延时函数，大写的量是宏定义

intiLibSwdDelay(unsignedintiDly){unsignedinti,k;for(i=0;i

这里是切换到SWD模式并且读取IDR的函数。

intiLibSwdSwitch2SWD(void){unsignedinti;for(i=0;i