topic Re: Sci for MC9S08GT60 in 8-bit Microcontrollers

Sci for MC9S08GT60

kris — Thu, 05 Jul 2007 14:44:34 GMT

Hi all.

// ---- External Crystal = 32768 Hz, Fbus = 3,67 MHz - FEE mode
ICGC1 = 0b00111000;
ICGC2 = 0x52;

For baud rate 9600 - BR is set to 24;

interrupt sci2rx void SCI2_RX_RS()
{
rej=SCI2S1;
if(rej&0x8) {
Rbajt=SCI2D;
}
Rbajt=SCI2D;
if(SCI2C1_M) osmy_bit = SCI2C3 & SCI2C3_R8_MASK;
}

Sometimes when I "call" the read interrupt routine the OR flag is automatic set.

Thanks.

Re: Sci for MC9S08GT60

thisobj — Thu, 05 Jul 2007 21:35:12 GMT

Hello Kris,

The clock and SCI baud rate setup appear to be okay. I'm assuming that the baud rate register value is DECIMAL "24" and not 0x24.

A common cause of overrun error (OR bit set) is another section of code disabling global interrupts for long periods of time or another interrupt requiring so much time to complete that an SCI receive interrupt goes unserviced.

Frank

Re: Sci for MC9S08GT60

bigmac — Fri, 06 Jul 2007 02:00:05 GMT

Hello,

Do you happen to be using 9-bit mode? If so, both SCIxD and R8 bit must be read to clear the RDRF flag. Failure to do so could result in an overrun error.

Regards,

Mac

Re: Sci for MC9S08GT60

peg — Fri, 06 Jul 2007 06:12:12 GMT

Hi and welcome Kris,

I did not confrim your baudrate settings however the ISR looks ok.

You also seem to be handling 9-bit mode correctly.

Although I wonder if you have represented your code correctly.

Here, you seem to be reading SCID (into Rbajt) twice if OR set and once if not, which does not make sense to me.

So it would seem that the ISR is being blocked (by being disabled either directly or other ISR's).

This would need to occur for one character time though.

You could perhaps try (for a test) doubling your bus speed (but keeping baud the same) to see if this has any effect. Or disabling other interrupts?

Message Edited by peg on 2007-07-06 09:20 AM

Re: Sci for MC9S08GT60

kris — Fri, 06 Jul 2007 13:15:20 GMT

Hi.

How increase priority of ISR (SCI1)?

Best regards.

Re: Sci for MC9S08GT60

thisobj — Fri, 06 Jul 2007 18:52:52 GMT

Hi Kris,

There is no way for the user to prioritize interrupts. There is an internal priority, and this is described on page 66 of document, MC9S08GB60/D.pdf. Keep in mind that internal priority is only relevant in the case of multiple interrupts pending. When an interrupt occurs, further interrupts are locked out until (1) that interrupt service returns (with an RTI) or (2) the code specifically enables interrupts within the service code. Choice (2) is extremely risky in a processor with limited RAM or if using an RTOS, since stack overflow can easily occur.

The suggestion by Peg to disable other interrupts as a test is a good one. Typically, multiple PWM interrupts can cause long holdoff times in servicing lower priority interrupts.

You could eliminate the double read on the data register as follows:

// modify code as follows:

rej = SCI2S1;
Rbajt = SCI2D;

if( rej & 0x08 ) {
rej = rej; // this could be your breakpoint on OR set.
}

// remaining 'M' test code...

NOTE: Since rej and Rbajt are assigned to register values, they should be delcared as volatile byte-length types (example: volatile char rej).

Frank

Re: Sci for MC9S08GT60

bigmac — Fri, 06 Jul 2007 22:36:41 GMT

Hello Kris,

With a baud rate of 9600, other higher priority ISR(s) would need to take more than 1ms (about 3700 bus cycles) for overrun to occur. If the execution time for any of the other ISRs is of this magnitude, this would seem excessive, and I might suggest that you consider a different approach with respect to these lengthy ISRs. As a general rule, there should not be intensive processing within any ISR.

If there happens to be a single offender ISR it should be feasible to re-enable interrupts within this one ISR only, provided you prevent re-entry to that particular interrupt. This way, there would be stack usage for a maximum of two interrupts only.

The following thread provides a discussion about the nesting of interrupts -

http://forums.freescale.com/freescale/board/message?board.id=CWCOMM&message.id=4977

Regards,

Mac