STM32L1 - ADC mit Timertriggerung und EOC-Interrupt hängt sich auf

[Niklas B. (niklas90)]

Hallo,

ich versuche mit dem STM32L1 mit dem DAC Daten auszugeben und mit dem 
ADC einzulesen. Beide sollen unabhängig von Timern getriggert werden. 
Beim DAC habe ich den Timer (TIM7) zusätzlich als Interrupt verwendet um 
neue Daten in in das DHR einzugeben.

Beim ADC verwende ich den TIM6 als Trigger, zum Testen ist er auf 1 sek 
eingestellt. Als Interrupt verwendet ich hier die EOC (end of 
conversion) Bedingung.

Bei beiden lösche ich das "interrupt-pending-bit" im Interruphandler, 
damit diese erneut ausgelöst werden können.

Nun zum Problem: Der DAC funktioniert wie er soll - allerdings nur so 
lange bis der erste TIM6 Trigger auslöst - danach hängt sich der µC in 
einer internen System-Endlosschleife auf. Ich weiß nicht woran es liegen 
könnte, ich weiß nur, dass der DAC wunderbar ohne den ADC funktioniert, 
also denke ich nicht, dass es an ihm liegt.

Übrigens: die LED sollte zu Testzwecken im Interrupthandler des ADC 
getoggelt werden, allerdings leuchtet sie nie auf, ich vermute also, 
dass der Handler nicht aufgerufen wird. Allerdings tritt der Fehler 
tatsächlich nach 1 sek auf, also wenn der ADC von TIM6 getriggert wird.

Ich hoffe ihr könnt mir helfen :(

[Michael K. (Gast)]

Wenn Du im Debug Modus von Run auf Halt gehst solltest Du sehen in 
welchem Programmteil der stehen bleibt.
Ist in den meisten Fällen irgend ein IRQ Flag das man zu löschen 
vergessen hat oder ein Register (AD Wert ?) das man hätte lesen müssen 
um bit xy zurückzusetzen.

[Niklas B. (niklas90)]

Das mit dem Debugger habe ich natürlich schon probiert, das Problem ist, 
der gibt eine für ihn unbekannte Addresse als "Sprung" an (Atollic 
TrueStudio light). Das passiert häufiger bei solchen Problemen, wäre 
nicht das erste mal und ist sehr nervig bei der Fehlersuche.

Das IRQ Flag sollte ja eigentlich mit

ADC_ClearITPendingBit(ADC1, ADC_IT_EOC);

 gelöscht werden, gell? Nur, wie gesagt, der hüpft ja nicht einmal in 
den Handler, er muss sich kurz davor aufhängen, weil zeitlich gesehen 
zum Zeitpunkt der ersten Datenaufnahmen, also muss iwas bei der 
Conversion schiefgehen. Vielleicht ist der ADC falsch konfiguriert? Muss 
man noch zusätzlich die Resolution irgendwie einstellen oder passiert 
das automatisch bei

ADC_RegularChannelConfig(ADC1, ADC_Channel_2, 1, ADC_SampleTime_4Cycles);

?

edit: Btw, am Timer liegt es auch nicht, ich habe testweise den 
Update-Interrupt (wie bei TIM7) für ihn konfiguriert, der funktioniert 
wunderbar. Es muss an der Conversion vom ADC liegen.

[Michael K. (Gast)]

Ok das war meine Vermutung, das der TIM6 doch angesprungen wird aber 
keine Routine hat in die er gehen könnte.

Es gibt aber mehr als eine IRQ für einige Peripherie.
Stell sicher das der nicht in einer anderen rumdümpelt die Du nicht auf 
dem Zettel hast.

Über die ST LIBs läßt sich manches nicht völlig korrekt konfigurieren 
bzw. wird viel mehr oder viel weniger gemacht als es offensichtlich ist.
Das sieht man aber erst wenn man das bit für bit im Datenblatt durchgeht 
und mit den Registern vergleicht.
Das würde ich Dir in dem Fall empfehlen.

[Niklas B. (niklas90)]

Ok, Problem gelöst. Zwei Sachen: zum Einen muss die Struct für den 
Interrupt des ADC anders benannt werden als die des TIM7, sonst fängt 
sich der µC beim initialisieren dieser bei NVIC_Init(&INTInitStruct) 
auf.

Und zum Anderen heißt der Interrupt-Handler für den ADC anders, nämlich 
"ADC1_IRQHandler()".