STM32G030F6P6 - projekt prostownika - problem z HardFault_Handler oraz NMI_Handler

Witam,
Jakiś czas temu na forum pytałem o koncepcję prostownika mikroprocesorowego. Od tamtego czasu zacząłem działać i stworzyłem płytkę, wlutowałem komponenty i zacząłem pisać program i testować układy. Wszystko szło dobrze dopóki nie rozbudowałem programu i zacząłem testy pod obciążeniem. W aplikacji wykorzystuję 3 wejścia ADC do pracy z DMA: pomiar prądu (wzmacniacz (INA180A1), napięcia na wyjściu(dzielnik), oraz potencjometr do ustawienia prądu ładowania. Odczyty są w miarę okej, dane zapisuję w tablicy. Na tej podstawie zmniejszam lub zwiększam PWM tak by U_odczyt nie przekroczyło 14,8V oraz jednocześnie nie było przekroczenia I_odczyt ustawionego na podstawie I_zadane z potencjometru. Wszystko działało w miarę ok, do czasu gdy nie zwiększę prądu do 4-5A. Wtedy układ się zawiesza i wpada w HardFault_Handler lub czasem NMI_Handler. Wykluczyłem problemy z zasilaniem, na sztywno Potencjometr->PWM wszystko chodzi bez zarzutu. Próbowałem szukać przyczyny i modyfikować kod, debugować ale bezskutecznie, jestem tylko hobbystą i dopiero co zacząłem przygodę z CortexM0. Poniżej zrzuty rejestrów w momencie wykrycia HardFault przez CubeIDE oraz kod w funkcji main. Proszę o pomoc w namierzeniu problemu bo próbuję od kilku dni i nic nie mogę wymyśleć. Z góry dziękuję.

RoMeK19 napisał:

Wykluczyłem problemy z zasilaniem, na sztywno Potencjometr->PWM wszystko chodzi bez zarzutu.

Może by tak zasymulować potencjometrami sygnały U i I?
.

Wywala sie zawsze w tym samym miejscu w kodzie?

volatile uint16_t adc_value[6];
U_odczyt = adc_value[0];
I_odczyt = adc_value[1];
I_zadane = adc_value[2];
HAL_ADC_Start_DMA(&hadc1, (uint32_t*)adc_value, 3);

typy zmiennych ogarnij najpierw.

Jeśli chodzi o typy zmiennych to zmiana tablicy na typ uint32_t nic nie daje i powoduje tylko błędny zapis danych z ADC. Zresztą we wszystkich przykładach dotyczących ADC i DMA w stm32 widziałem rozwiązane to w ten sposób, a w Cortexie M3 zawsze działało to bez zarzutu. Co do momentu pojawiania się ErrorHander to jest on niestety losowy. Może zbyt wcześnie odrzuciłem opcję, że to wina zasilania. Po eksperymentalnym dodaniu 5x 100nF na linii 3,3V oraz zmianą 4,7uF na 100uF problem ustąpił i przy prądzie wyjściowym 6A wszystko chodzi jak trzeba. Zmieniłem także częstotliwosć kluczowania na ok 7,5 kHz na próbę. Obawiam się jednak, że przy próbie wejścia na 8-10A problem może wrócić. Pomiar linii 3,3V przed dodaniem kondensatorów wskazał na szpilki sięgające do 3,6V przy wyższych prądach co w zasadzie łapie się w granicach, w których producent deklaruje poprawną pracę urządzenia: 2-3,6V. Pytanie co jeszcze mogę poprawić jeśli chodzi o filtrację linii 3,3V bo wszystko obecnie wskazuje, że tu leży problem? Może koralik ferrytowy za stalilizatorem liniowym 3,3V?

Ja bym założył źle zaprojektowany PCB. Przy większych prądach i impulsowym przełączaniu trzeba uwzględniać pasożytnicze wartości ścieżek.

RoMeK19 napisał:

Pomiar linii 3,3V przed dodaniem kondensatorów wskazał na szpilki sięgające do 3,6V przy wyższych prądach co w zasadzie łapie się w granicach, w których producent deklaruje poprawną pracę urządzenia: 2-3,6V. Pytanie co jeszcze mogę poprawić jeśli chodzi o filtrację linii 3,3V bo wszystko obecnie wskazuje, że tu leży problem? Może koralik ferrytowy za stalilizatorem liniowym 3,3V?

Nie wiem czym to mierzysz, ale jak masz zmierzone w impulsie 3,6 V to może on mieć więcej niż 3.6V. Trudno coś doradzić jeżeli nie mamy projektu płytki. Koralik oczywiście nie zaszkodzi (raczej). Mógłbyś jeszcze dodać po prostu jakiś filtr na zasilaniu procka (jakiś T albo pi z elementami RLC). Pytanie też jak masz rozwiązane sterowanie wyjściem z procesora, czy masz tam jakieś snubbery, czy robisz to przez jakiś gate-driver...