Ukončení přenosu využitím DMA

[Hynek Sladky]

Ted jsem si vzpomnel na jedno podobne podivne chovani:

Procesor byl STM32L051, IDE Keil, debugger Ulink2.
Pri ladeni zobrazene registry periferie (zde treba SPI).
Debugger pravidelne vycita stavy registru a zobrazuje je. To ale obcas 
zpusobilo nulovani nejakeho bitu. Kdyz se to seslo, tak se funkce 
programu prerusila, protoze cekal na bit, ktery se ale vynuloval ctenim 
debuggeru.

Jakmile jsem vypnul zobrazeni periferie pri ladeni nebo pustil program 
bez ladeni, podivne nahodne chyby zmizely a vse se chovalo dle ocekavani.

Nemuze to byt podobny problem?

Hynek Sladky




Dne 14.9.2016 12:47, Tomáš Hamouz napsal(a):
>> No toto mi vobec nedava zmysel. Takze nakoniec sa aj pri tom "zakopnuti"
>> prenesie ocakavany pocet znakov (/ 8 = pocet clockov zodpovedajuci poctu
>> bytov nastavenych v Tx DMA), ale v Rx buffri nie su?
> Pokud dojde k zakopnutí, tak se přenos ukončí předčasně. Z nějakého
> důvodu vypadne ze smyčky kde se čeká až Rx kanál DMA skončí přenos.
>
>>     while(SET == DMA_GetChannelActiveStatus(SSP1_DMA_CHAN_RX)) {;}
> (Ta funkce jen testuje příslušný bit, nic jiného)
>
> Kanál se dle DS zastaví buď přenesením daného počtu přenosů, nebo
> výskytem chyby, nebo ručně.
>
> Standardně po ukončení přenosu v následujícím kódu oba kanály (pro
> sichr) zastavím ručně. Za normálních okolností jsou už oba stopnuté.
>
>>     DMA_ChannelCmd(SSP1_DMA_CHAN_RX, DISABLE);
>>     DMA_ChannelCmd(SSP1_DMA_CHAN_TX, DISABLE);
> Protože mi vypadne z výše uvedené smyčky dříve, utnu tím i Tx kanál.
> Tím se vysvětluje proč se přestane odesílat FF, ale záhadou je proč
> dojde k předčasnému stopnutí Rx kanálu. Přitom Tx kanál se
> pravděpodbně nezastaví, tak až pak zastavím v kódu.
>
>
>> Chcelo by to pozriet ako je to prelozene.
> Ta čekací smyčka, o kterou předpokládám jde
>
> Debug build
>
> while(SET == DMA_GetChannelActiveStatus(SSP1_DMA_CHAN_RX)) {;}
>    0000EC68    E1A00000    mov r0, r0
>    0000EC6C    E59F3130    ldr r3, 0x0000EDA4
>    0000EC70    E5933000    ldr r3, [r3]
>    0000EC74    E1A00003    mov r0, r3
>    0000EC78    E59F3130    ldr r3, 0x0000EDB0
>    0000EC7C    E12FFF33    blx r3
>    0000EC80    E1A03000    mov r3, r0
>    0000EC84    E3530001    cmp r3, #1
>    0000EC88    0AFFFFF7    beq 0x0000EC6C
>
>    0000EDA4    040006DC    .word 0x040006DC       ; *DMA_Channel5
>    0000EDB0    0000C498    .word 0x0000C498       ; DMA_GetChannelActiveStatus
>
>
>
> Release build
>    0000A320    E59F4088    ldr r4, 0x0000A3B0
> while(SET == DMA_GetChannelActiveStatus(SSP1_DMA_CHAN_TX)) {;}
>    0000A324    E59F0080    ldr r0, 0x0000A3AC
>    0000A328    E12FFF34    blx r4
>    0000A32C    E3500001    cmp r0, #1
>    0000A330    0AFFFFFB    beq 0x0000A324
>
>    0000A3AC    780001A0    .word 0x780001A0       ; DMA_Channel5
>    0000A3B0    00007C18    .word 0x00007C18       ; DMA_GetChannelActiveStatus
>
>
>
>> Bolo by tiez dobre mat pred,
>> medzi a za tymi while nejaku znacku (zacvicit nejakym pinom) a pozerat
>> osciloskopom/LA spolu s tymi hodinami od SPI.
> Přesně tak jsem to dělal.
>
> Tomáš
>
>> wek
>

------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20160914/01ae35af/attachment.html>