STM32 + TrueStudio + breakpoint

[Minti (Gast)]

Hallo,

ich programmiere mit Atollic TrueStudio Lite auf STM32F103 über ST-Link. 
Zur Zeit hat mein Programm 2 Interrupts:
- TIM2
- USART2 (für Kommunikation mit XPort)

Wenn ich von Laptop über LAN ein Byte an µC schicke, kommt es nicht an. 
Setze ich aber ein Breakpoint in USART2_IRQHandler, dann wird diese 
Nachricht bearbeitet.

Woran liegt es? Und wie kann es behoben werden?
Ist es ein Bug in der Atollic TrueStudio? Oder kriegen sich die 
Interrupts in die Wolle?

Danke im voraus, Minti

[holger (Gast)]

>Zur Zeit hat mein Programm 2 Interrupts:
>- TIM2
>- USART2 (für Kommunikation mit XPort)

TIM2 hat nicht zufällig eine höhere Priorität
als der USART2?

Löschst du das Interruptflag bei TIM2 auch?
Beispiel:

 TIM_ClearITPendingBit(TIM2, TIM_IT_CC1);

[Minti (Gast)]

Hi holger,

hier sind NVIC_InitStructures

// Enable the TIM2 global Interrupt
  NVIC_InitStructure.NVIC_IRQChannel = TIM2_IRQn;
  NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
  NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1;
  NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;

NVIC_InitStructure.NVIC_IRQChannel = USART2_IRQn;
    NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0x0; //1;
    NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0x0; //1;
    NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
    NVIC_Init(&NVIC_InitStructure);

>Löschst du das Interruptflag bei TIM2 auch?
ja

Kann es daran liegen, dass die Bearbeitung von Interrupt von TIM2 lange 
dauert, so dass in dieser Zeit 2. Interrupt von TIM2 sofort dran ist und 
so USART gar nicht dran kommt?

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Das Ändern der Sub-Priority bring rein gar nichts.

Wenn ein wichtiger Interrupt einen unwichtigen unterbrechen können soll, 
dann muss der wichtige eine höhere PreemptionPriority haben (kleinere 
Zahl!).

Mit:
NVIC_PriorityGroupConfig(NVIC_PriorityGroup_2);
hat man für die PreemptionPriority 2 Bits und SubPriority auch zwei.

Dann können als PreemptionPriority 0..3 eingestellt werden.
Der wichtige bekommt 0, der unwichtige 1. Somit kann der wichtige den 
anderen Interrupt unterbrechen.

[Minti (Gast)]

Hallo Markus Müller,

wenn ich dich richtig verstanden habe, dann haben beide Interrputs 
gleiche Prio und somit unterbrechen sie sich nicht, sondern einer wartet 
auf den anderen und wird danach ausgeführt. Richtig?

Aber das erklärt nicht, warum in "normalen Modus" die Nachricht nicht 
ankommt. Denn dann würde USART nach TIM2 ausgeführt und die Nachrit 
würde bearbeitet werden. Oder verstehe ich was falsch?

Und warum funktioniert es, wenn ich breakpoint in Debug setze?

[Minti (Gast)]

PS: holger und Markus Müller, Danke für die schnelle Antwort

[holger (Gast)]

>Und warum funktioniert es, wenn ich breakpoint in Debug setze?

Ohne kompletten Sourcecode kann dir das keiner beantworten.
Schalte TIM2 doch einfach mal ab. Ist das Problem dann weg?

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

> Richtig?
Ja.

Man sollte eine Zähler-Variable im Main-Loop drin haben. und sich jede 
Sekunde die Differenz merken.
Immer wenn dieser Zähler nur wenig hoch zählt hat man irgendwo ein 
"Hänger" programmiert.
Somit kannst Du einzelne Teile nacheinander auskommentieren und dann 
sehen wo es klemmt.

Ansonsten kann sicher niemand sinnvoll helfen, bei diesen wenigen 
Codezipfel die wir bisher sehen durften.

[Minti (Gast)]

>Schalte TIM2 doch einfach mal ab. Ist das Problem dann weg?
Ich kann jetzt nicht testen, aber was würde bedeuten, wenn das Problem 
weg wäre? Dauert die Bearbeitung von der Interruptroutine zu lange?

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Messe das doch mit einem Oszi:

Start Interrupt >> Port Pin setzen
Ende Interrupt >> Port Pin löschen

Wenn das Bit immer nur gesetzt ist, dann dauert der Interrupt zu lang.