stm32的swd接口的燒寫協(xié)議是否公開的呢？

需要用一臺(tái)好的示波器來抓才能有足夠的存儲(chǔ)深度，保證你能夠過濾掉那個(gè)該死的50clock。

按照Arm的手冊(cè)，每次轉(zhuǎn)換發(fā)送方都需要一個(gè)TNR---但是我觀察JLINK的波形卻沒有那個(gè)該死的TNR。

手冊(cè)中說異步SWD需要，同步不需要----或者相反，但是我沒有找到關(guān)于同步異步的描述。

姑且不管他，反正目前忽略掉TNR就能夠讀到該死IDR。

另外JLINK的復(fù)位時(shí)序很奇怪，大致是

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

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

70clkHigh，16clk Low，0xa5，

注意這里按照協(xié)議應(yīng)該是TNR位-但是沒有實(shí)際觀測(cè)到這個(gè)位，

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

實(shí)際測(cè)試，不額外增加那個(gè)奇怪的0xedb6也能夠照常讀出IDR。

另外要注意，設(shè)備端的數(shù)據(jù)最哈哦在CLK的下降沿讀取，或者上升沿過后延時(shí)1/2bit后讀取。

如果想要深究，可以去sourceforge.net去下載SWD Lib，以及openOCD，兩者對(duì)照著來會(huì)很方便。

利用好bitband寫程序會(huì)很舒服，尤其是處理SWD的位流，一個(gè)int32指針跳起來很爽，并且是LSB First的結(jié)構(gòu)。

完全沒有任何障礙的。

另外發(fā)現(xiàn)在讀IDR后，其他的讀寫命令的ACK后面，SWDIO會(huì)有兩個(gè)bits的緩慢上升波形，

并且在clk的下降沿被Target拉底，按照格式硬套的話，這兩個(gè)位應(yīng)該忽略掉。

目前還沒發(fā)現(xiàn)對(duì)于這兩個(gè)位的說法。

有的時(shí)候能夠看到當(dāng)JLink讀取信息的最后會(huì)把本該由Target發(fā)送的parity拉低，忽略掉。

還有需要注意的是，似乎除了讀IDR，CTRL，ABOUT這三個(gè)寄存器外，其他的寄存器讀取都有一個(gè)數(shù)據(jù)幀的延遲。

比如你發(fā)起第一個(gè)讀取貞，讀到的數(shù)據(jù)沒有意義。

第二個(gè)讀取幀，讀到的是第一次的地址對(duì)應(yīng)的數(shù)據(jù)，依次類推。

硬件上，SWDIO的上拉要足夠強(qiáng)，不然上升沿可能不夠陡峭，我現(xiàn)在用的是2.2k，還湊合。

看到SWD LIB的源碼里面是按照8位讀寫，32位讀寫的方式來做的。

也就是說，只要控制好SWCLK，并且能夠保證不丟掉任何SWDIO位信息，用SPI也可以模擬出SWD的時(shí)序。

這部分參考了SourceForge的LibSwd項(xiàng)目，該項(xiàng)目是開源的，寫的很嚴(yán)謹(jǐn)，代碼風(fēng)格也很好，強(qiáng)烈大家下來看看。

原始代碼是四個(gè)函數(shù)，讀，寫，8，32.我歸結(jié)到兩個(gè)函數(shù)，用了bitband結(jié)構(gòu)所以入口就簡單了一些，緩沖區(qū)和位數(shù)即可

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

看到return（0）你想到了什么？
嘿嘿，本來我是采用定時(shí)器來控制clk的，這樣就需要考慮程序運(yùn)行出錯(cuò)的返回代碼。
后來發(fā)現(xiàn)這樣很傻，就該成死等了。
這樣就不需要返回異常信息了，但是為了保持形式上的統(tǒng)一，函數(shù)還是帶有返回值的樣子。hoho
這里是延時(shí)函數(shù)，大寫的量是宏定義

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

這里是切換到SWD模式并且讀取IDR的函數(shù)。

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