[elektro] STM32F446 TIMER3 interrupt

Wed Aug 1 11:23:27 CEST 2018

Hasonlokeppen jartunk STM32L15-el. Az kezzel irott kod volt. ( Nem en
irtam:) )
Ketszer futott le. De volt olyan build ami csak egyszer, rendesen:)

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

> A közepére. Előtte is van user code begin, meg utána is.
> DE én kiremeltem a HAL hívást, mert az jelen esetben
> feleslegesen hosszű(végig vizsgálja az összes flaget).
> Én meg, megszokásól a végére szúrtam be a
> flag törlést.
> Mint írtam első sorból jól műxik.
>
> Üdv.  Zoli
>
> ----- Original Message ----- From: "uprogc" <uprogc at gmail.com>
> To: <elektro at tesla.hu>
> Sent: Wednesday, August 01, 2018 10:46 AM
>
> Subject: Re: [elektro] STM32F446 TIMER3 interrupt
>
>
> 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]
>>>
>>> -----------------------------------------
>>          elektro[-flame|-etc]
>>
>
> -----------------------------------------
>          elektro[-flame|-etc]
>