[elektro] STM32F446 TIMER3 interrupt

[uprogc]

Nem az IT elejere teszi a flag torleset ?

2018-08-01 11:36 GMT+03:00 Bali Zoltán <eltexto at freemail.hu>:

> Tamás, köszönöm neked is!
>
> A CubeMx az EWARM "szája ize" szerint generálja a kódot.
> Persze, ha majd jobban bele tudok mélyedni a compiler
> doksijába, lehet találok ott is néhány varázsigét a
> problémára vonatkozóan.
>
> Üdv.  Zoli
>
> ----- Original Message ----- From: "Stolmár Tamás" <
> knight at borsodi.qualitis.hu>
> To: "r3flow via Elektro" <elektro at tesla.hu>
> Sent: Tuesday, July 31, 2018 10:10 PM
> Subject: Re: [elektro] STM32F446 TIMER3 interrupt
>
>
> Szia!
>
> Előrebocsátom, nem használok ARM-es kontrollereket, csak más
> tapasztalatok alapján ötletelek.
>
> Cache-hez szokott lenni data cache flush és opcode cache invalidate
> utasítás is.
> Ez pont akkor kell, ha ilyesmi adat-versenyhelyzet alakulna ki,
> pl. egy LAN csatoló memóriáját (mmapped) kell feltölteni, és utána
> indítani pl az adatküldést.
>
> Lehet hogy van a write buffer flush-ra is utasítás, vagy valami IO-reg
> írás ami csak akkor tér vissza ha minden OK.
> Ezzel a buffer is maradhat, gyorsít, de amikorra kell addigra már minden
> a helyére került.
> Az is lehet, hogy elég ha csak kikapcsolod, majd vissza.
> Biztos már más is találkozott ezzel a problémával (write buffer race
> condition flush).
>
> Más fordító, pl a GCC milyen IRQ handlert fordítana?
> Nem kellene az interrupt handlert valami __attribute__ interrupt
> opciókkal megtámogatni?
>
> Üdv:
> Tamás
>
> On 07/31/2018 09:53 PM, r3flow via Elektro wrote:
>
>> Amit kikapcsoltál az a Flash-ből utasítás olvasásra vonatkozik.
>>
>> Ami a te problémádat okozza az a RAM előtti write buffer ami az ST
>> Cortex-M4-ekben van, ami azért van, hogy a CPU-nak ne kelljen megvárni a
>> RAM írással azt, hogy szabad legyen a busz. Emiatt a RAM write buffer
>> miatt van az, hogy a flash törlésed még nem történt meg amikor már
>> kiléptél az ISR-ből emiatt a CPU újrahívta az ISR-t.
>>
>> Ezt a write buffert az ACTLR (0xE000 E008) regiszter 1. bitjével
>> (DISDEFWBUF) tudod kikapcsolni ezt a write buffert. Ebben az esetben
>> viszont lelassul a végrehajtásod mert a CPU mindig meg fogja várni a RAM
>> írás végét mielőtt végrehajtja a következő utasítást.
>>
>> https://www.st.com/resource/en/programming_manual/dm00046982.pdf
>>
>> Üdv,Z.
>>
>>
>> On 2018-07-31 21:25, Bali Zoltan wrote:
>>
>>> Köszönöm, ez megmagyarázza, de akkor nem értem,
>>> hogy kikapcsoltam(elvileg, CubeMx) az Insruction, data cache-t,
>>> meg a prefetch-et, és mégis dupláz. Vagy átver a Cube MX.
>>> Na mindegy, megnézem még online a regiszterekben.
>>>
>>> Köszi még egyszer.
>>> Üdv.  Zoli
>>>
>>>
>>> 2018.07.31. 21:03 keltezéssel, r3flow via Elektro írta:
>>>
>>>> Régen olvastam végig az ARM.com-ot a cortex doksit de van olyan emlékem,
>>>> hogy külön felhívták a figyelmet arra hogy M3/M4 esetén ha túl gyorsan
>>>> kilép az ISR akkor duplázás történhet, mert a memória írás ami törölné
>>>> az interrupt bitet az írás cache miatt nem történik meg az ISR-ből
>>>> kilépés előtt, emiatt a CPU újrahívja az ISR-t.
>>>>
>>>> http://www.keil.com/support/docs/3928.htm
>>>>
>>>> Üdv,
>>>> Z.
>>>>
>>>>
>>>> On 2018-07-31 20:23, Bali Zoltan wrote:
>>>>
>>>>> Hali!
>>>>>
>>>>> Itt a már lekopasztott kód, ami most fut is valójában.
>>>>>
>>>>> void TIM3_IRQHandler(void)
>>>>> {
>>>>>     /* USER CODE BEGIN TIM3_IRQn 0 */
>>>>>     GPIOC->BSRR = 1<<10;
>>>>>     /* USER CODE END TIM3_IRQn 0 */
>>>>> //HAL_TIM_IRQHandler(&htim3);
>>>>>     /* USER CODE BEGIN TIM3_IRQn 1 */
>>>>>     if(TIM3->SR & TIM_SR_UIF) {
>>>>>     }
>>>>>     TIM3->SR  = TIM3->SR & ~TIM_SR_UIF;
>>>>>     GPIOC->BSRR = 1<<(10+16);
>>>>>     /* USER CODE END TIM3_IRQn 1 */
>>>>> }
>>>>>
>>>>> F446, 48MHz, maximális optimalizálással, mindenféle prefetch
>>>>> varázslás kikapcsolva, csak UIE-vel, kétszer fut le az interrupt.
>>>>> A csatornák PWM-re vannak állítva, belső órajel, semmi különleges.
>>>>> Optimalizálás nélkül, egy interrupt van csak, mint a másik(F051)
>>>>> képen. Persze, ekkor  hosszabb ideig magas a billentett port.
>>>>> Lehet túl rövid az IT futása? Ha bent volt a végrehajtási
>>>>> saját kódom is, akkor időnként duplázott csak. Azután kezdtem
>>>>> lekopasztani, miután az a gyanúm támadt, hogy a futási idővel van
>>>>> összefüggésben. Speciel most, pont kéne, hogy minél rövidebb legyen
>>>>> az IT... Volt már olyan változat, hogy SR regiszter simán nullázva.
>>>>>
>>>>> http://www.kepfeltoltes.eu/images/hdd1/2018/07/31/1462018073
>>>>> 1173944.png
>>>>>
>>>>>
>>>>> Átraktam a kódot, F051-re, ugyanazzal(remélem, mert Cube MX-el
>>>>> generáltam újra). Ez max optimalizálással sem dupláz, a fenti IT
>>>>> kóddal-
>>>>>
>>>>> http://www.kepfeltoltes.eu/images/hdd1/2018/07/31/4992018073
>>>>> 1172830.png
>>>>>
>>>>> F446-on még az IT prioritásokat vissza vettem mindet 4-re, csak a
>>>>> TIMER3
>>>>> van 0-án.
>>>>>
>>>>> Errátát néztem, semmi timer, IT vonatkozás.
>>>>>
>>>>> Ötlet? Tapasztalat?
>>>>>
>>>>> Köszi
>>>>>
>>>>> Üdv.  Zoli
>>>>>
>>>>> -----------------------------------------
>>>>>            elektro[-flame|-etc]
>>>>>
>>>> -----------------------------------------
>>>>             elektro[-flame|-etc]
>>>>
>>>> -----------------------------------------
>>>           elektro[-flame|-etc]
>>>
>> -----------------------------------------
>>            elektro[-flame|-etc]
>>
>
>
> -----------------------------------------
>          elektro[-flame|-etc]
>
> -----------------------------------------
>          elektro[-flame|-etc]
>