ESCI Receive problems when TIM overflow ISR is enabled

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

ESCI Receive problems when TIM overflow ISR is enabled

2,581件の閲覧回数
Otze
Contributor I
Hello,

I'm working with a HC908QB8. The ESCI receives without errors when the Timer ISR is disabled. If the Timer ISR is enabled, than it seems that the ESCI misses telegrams proportional to the time the ISR is called (about 5% of the messages are not recognized).
Additional Info: it is a LIN Bus application, baudrate is 9600bps, and each 100ms a frame header is send out by LIN master. I stay in the Timer ISR for about 5us.

Has anybody similar experience or an idea what I'm maybe doing wrong?

Thanks!
ラベル(1)
0 件の賞賛
返信
5 返答(返信)

796件の閲覧回数
Alban
Senior Contributor II
Hi Otze,
 
What do you use the TIM for ?
Is it linked to LIN ? Because the ESCI has an integrated simple Timer.
 
What can happen from what you described is that your TIM ISR is too long compared to speed of messages and you get a Buffer Overrun. It means you get a new message when you haven't read/removed the previous one from the Data Register.
 
If the latest is the case and you need the TIM for something else, you need to have quicker TIM ISR.
Or you can also have the system having a greater bus clock so TIM ISR time is not significant compared a a LIN message.
 
Note that 9600 is quite slow and easily handled by an HC08QB8 which can be a LIN Slave node at 20kbps without the slightest glitch.
 
Cheers,
Alban.
0 件の賞賛
返信

796件の閲覧回数
Otze
Contributor I
Hello Alban,

Thanks for the reply. I just need this timer to increment some counter variable which I use to trigger some action in my main-loop when a counter value is reached.
For the timer routine itself: I stay in this ISR for about 5 microseconds, and a bit time is about 104 microseconds at 9600bps, and a byte takes about 1ms, so I don't think that I miss a received byte because I'm stucking in the timer ISR.

Best regards
0 件の賞賛
返信

796件の閲覧回数
Alban
Senior Contributor II
Hi again,
 
If you don't get out of the ISR it is likely that you didn't clear the Interrupt Flag properly.
 
When it is set, it generates an interrupt event.
As long as you don't acknowledge it, you will go back to the interrupt.
 
Check TxSC_TOF bit

TOF — TIM Overflow Flag Bit

This read/write flag is set when the TIM counter resets reaches the modulo value programmed in the TIM counter modulo registers. Clear TOF by reading the TIM status and control register when TOF is set and then writing a 0 to TOF. If another TIM overflow occurs before the clearing sequence is complete, then writing 0 to TOF has no effect. Therefore, a TOF interrupt request cannot be lost due to inadvertent clearing of TOF. Reset clears the TOF bit. Writing a 1 to TOF has no effect.

1 = TIM counter has reached modulo value
0 = TIM counter has not reached modulo value

Enjoy,
Alban.
0 件の賞賛
返信

796件の閲覧回数
Otze
Contributor I
Hi Alban,

this was a misunderstanding. Of course, I get out of the ISR. I just wanted to say that I don't think that the ISR is so long that I miss a received byte.
Here is the code itself:

interrupt void ISR_TimerOF()
{
/* variable declaration */
uint8_t ucDummy;


/* clear the overflow flag */
ucDummy = TSC; /* 1st step: read the status register */
TSC_TOF = 0; /* 2nd step: reset the TOF */


/* set the flag resp. increment the counters */
gucTimerFlag = 1;
gusCounterOpHour++;
gusCounterDiagnose++;
gusTimeSinceLastSynchBreak++;

}

Just to remember: without Timer ISR, I receive every byte. With the Timer ISR enabled, I miss approx. 5% of the telegrams.

Best regards,
Otze
0 件の賞賛
返信

796件の閲覧回数
transcend
Contributor I
Check if the TIM overflow is too short!


Message Edited by transcend on 2008-03-05 02:16 AM
0 件の賞賛
返信