[elektro] STM32F446 TIMER3 interrupt

Wed Aug 1 11:25:00 CEST 2018

ui:
Erdemes mindig ilyen esetekben az STM foruman megnezni a peldakodokat es
abbol inspiralodni. En amiket az alapjan osszeraktam mindig ment rendesen.
A kollega fejbol irta es nem is volt jo.
Meg hat ideje kinkek van elolvasni az ARM kezikonyvet es minden reszletet
kitanulmanyozni...

2018-08-01 12:23 GMT+03:00 uprogc <uprogc at gmail.com>:

> 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]
>>
>
>