Timing problems with USART and TIM2

[sarang]

Posted on September 30, 2009 at 13:10

Timing problems with USART and TIM2

[sarang]

Posted on May 17, 2011 at 13:25

I am seeing a weird scenario on our boards. If I try to print out something in a Timer 2 ISR then, there is a problem with the output freq. My Timer 2 ISR basically writes to GPIO BRR and BSRR to set/reset bits. Adding USART debug statements affects the output frequency for toggle.

Please let me know if I need to take any special care when setting up the NVIC. Also, I am using interrupt based USART.

[st3]

Posted on May 17, 2011 at 13:25

Quote:

If I try to print out something in a Timer 2 ISR

Printing stuff is almost certainly something that should not be done in an ISR! especially if you use printf... [ This message was edited by: st7 on 26-09-2009 21:28 ]

[sarang]

Posted on May 17, 2011 at 13:25

Thanks. I removed that print statement. But now it seems that there is an issue with a structure i am using. If i statically assign an array of structures with number of elements =6, my ISR timings go askew. But if the size of array is declared as 4, everything seems to be fine.

Could my heap be getting corrupted? If so, would that in anyway affect ISR timings?

[st3]

Posted on May 17, 2011 at 13:25

Quote:

Could my heap be getting corrupted?

You haven't mentioned anything that uses the heap - but have you checked your Stack?

[st3]

Posted on May 17, 2011 at 13:25

Quote:

How do i check stack issues?

Check your tool documentation to see if there's anything provided... Otherwise, standard tricks are: 1. Pre-fill the stack area with some easily-recognised pattern; if none of this pattern remains when the problem occurs, then your stack has probably overflowed; 2. Set a data breakpoint just beyond the end of your stack - if that breakpoint ever ''fires'', then your stack has overflowed!

[sarang]

Posted on May 17, 2011 at 13:25

How do i check stack issues?

I did a bit of modification in the code and changed USART to polling. I notice that USART input is disabled after the code runs for awhile. This happens only when I try to setup the timer config. If i donot start Timer2, the USART etc work fine.

[st3]

Posted on May 17, 2011 at 13:25

You need to use the 'CODE' tags to make your source legible - use the 3rd button from the right in the row of formatting buttons immediately below the 'Message' box...

[ This message was edited by: st7 on 28-09-2009 23:21 ]

[sarang]

Posted on May 17, 2011 at 13:25

Please let me know if this makes any sense -I notice that USART input is disabled after the code runs for awhile. This happens only when I try to setup the timer config. If i donot start Timer2, the USART etc work fine.

The code in question is :- GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; //PUSH PULL output GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOB, &GPIO_InitStructure); /* NVIC Config*/ /* Enable the TIM2 Interrupt */ NVIC_InitStructure.NVIC_IRQChannel = TIM2_IRQChannel; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 2; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure); while(1) { } //TIMER 2 IRQ Handler void TIM2_IRQHandler(void) { /* TIM2_CH1 toggling with frequency */ if (TIM_GetITStatus(TIM2, TIM_IT_CC1) != RESET) { //u16 temp=0x0; if (TIM_GetITStatus(TIM2, TIM_IT_CC1) != RESET) { TIM_ClearITPendingBit(TIM2, TIM_IT_CC1); if(tmrState==0) { GPIO_ResetBits(GPIOA,GPIO_Pin_8); tmrState=1; } else if(tmrState==1) { GPIO_SetBits(GPIOA,GPIO_Pin_8); tmrState=0; } capture = TIM_GetCapture1(TIM2); TIM_SetCompare1(TIM2, capture + CCR1_Val); } } }

[sarang]

Posted on May 17, 2011 at 13:25

I could make Timer2 Interrupt as well as USART1 work perfectly fine. The only change I made was changing Timer mode to Output Inactive. In output active, it was not working correctly. My Timer 2 ISR toggles PA0 and PA15 which are actually alternately mapped to Timer 2.

Changing the timer mode solved this issue but I have not found a justification as to why this should work.