OT - ST-Link 2 - bug v implementacii SWO

[Jan Waclawek]

Toto je nieco, co by som mal napisat na support ST. Lenze tam na mna ako na
<<100kpcs/year uzivatela budu zvysoka kaslat, naviac nie som si isty, ze
to, co napisam, sa bude pacit vsetkym co su tam po ceste... a dufam, ze
kolegovia tu co su z ST to vhodnym sposobom posunu kam treba ;-)

Sucasne ARMoidy maju pomerne rozsiahly zabudovany on-chip debug, a jednou z
metod, ako z toho debugu dostat von data je rozhranie co sa vola SWO
(Serial Wire Output). V podstate to navonok funguje ako normalny UART.
Maju to k dispozicii aj STM32. Debugovaci "dongle" STLink2 (ktory je aj
zabudovany do vsetkych vyvojovych dosak ST vratane serie DISCOVERY) ma
toto rozhranie implementovane, takze sa to da pouzit ako pomerne luxusny
"printf" priamo na PC (k tomu vedia urobit "konzolu" rozne IDE a aj
aplikacia ST-LINK Utility), a dali by sa robit aj nejake trasovacie finty.
Samozrejme je to obmedzene rychlostou toho UARTu, a zozerie to jeden
konkretny pin na cielovom procesore, ale aj tak je to pomerne prijemna
zalezitost.

Bohuzial, data posielane cez to rozhranie maju neprijemnu tendenciu sa
"stracat", resp. nielenze sa data stratia, ale sa aj prenesie niekolko
nezmyselnych udajov. A to aj ked je baudrate nastaveny nizko, takze by to
uz nemala byt zalezitost nejakeho nestihania procesora STLink-u, alebo
USB/PC. Vid napr.
https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy.st.com%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fST%20Link%20utility%20Serial%20Wire%20Viewer%20feature%20via%20ST%20Link%202&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=116
alebo
https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/ITM%20data%20missing&currentviews=17
. 

Teraz pride to, co sa oficialne nebude pacit :-) Aj ked firmware nie je
verejne dostupne, ba dokonca je kodovane, pomerne rychlo sa na internete
daju najst nejake nekodovane binarky, mozno nie uplne najnovsej verzie
firmwaru, ale povedzme ze predposlednej ano. No a odtial je len krok k
tomu, aby sa do toho zvedavy clovek ako ja pozrel. No a uvidel som tam
prijem dat cez normalny hardwarovy USART1, ukladany pomocou DMA1Ch5. A
uvidel som to, ze v preruseni od DMA sa po ukonceni prenosu (t.j. po
prijati nejakeho nastaveneho mnozstva udajov) ten USART vypne, urobi sa
niekolko roznych ukonov, napriklad sa nanovo nakonfiguruje prislusny DMA
kanal, a az potom sa ten USART znova zapne. Toto podla mna staci na to,
aby sa jednak nejake byte v case, ked je USART vypnuty, postracali, ak je
vysoka prenosova rychlost; a druhak po zapnuti (potencialne uprostred uz
prebiehajuceho byte) sa chytila najblizsia hrana medzi bitmi 1->0 ako
startbit cim sa prijmu nejake nezmysly.

Mohol by prosim niekto, kto ma pristup k zdrojakom, sa na to pozriet, a
pripadne to opravit? Ja viem, ze vzhladom na nepritomnost dvojiteho
buffrovania v pouzitom STM32F103 sa vypadkom bytov pri vysokych
rychlostiach nemusi podarit uplne zabranit, ale minimalne to vypinanie
USARTu je zbytocne a jeho odstranenie by malo umoznit dobru funkciu pri
nizsich rychlostiach (ak som nieco neprehliadol). Zda sa mi aj, ze by sa
dalo pooptimalizovat napriklad predpocitanim nejakych hodnot, necitanim
overrun bitu z USARTu (co, ako som dobre pochopil, sa potom nikde
nepouzije, ale mohol som to aj zle pochopit), ci, ze som taky smeli, aj
poasemblerovanim (ide o tucet-dva instrukcii). A nedal by sa pouzit
cirkularny mod DMA, to by tiez znizilo pocet operacii...?

Bolo by to fajn, kebyze to funguje tak, ako ma; a je to aj v zaujme
zakaznikov ST, co predpokladam, ze znamena aj, ze je to v zaujme ST.

Dakujem.

wek