Difficulty setting up SCI0

[roberthiebert]

CW V 5.9.0 SE, MC9S12XEP100, absolute assembly. I am having some difficulty setting up SCI0 with a new program. The hardware is good because when I load another program with a similar setup it works fine. I've written a small test program to see if my RTI and SCI0 interrupts are working. The RTI is good, but when I connect CoolTerm to the board at 115k baud and send a character my test LED does not energize. I suspect there could be something wrong with my set up, but I am at a loss to figure it out. Any suggestions would be appreciated. I am attaching the program.

Regards,

Robert 

[RadekS]

Hello Robert,

I checked several settings in your code and everything looks OK.

SCI0_ISR sets PTB2. That is clear. 

But I do not see here a code for RX flag clearing. 

The flag-clearing procedures require that the status register be read followed by a read or write to the SCI data register.

Without that code, the execution will be stuck in SCI0_ISR (the code will be executed in the loop. Except for higher priority ISRs events).

Please look also at https://www.nxp.com/docs/en/application-note/AN2554.pdf for more details about clearing interrupt flags. But be aware that SCI is quite a specific case (flag is cleared automatically). 

I hope it helps you.

Best Regards

Radek

[StanoA]

Hello Robert,

Your code looks good. I have only one small comment besides Radek's suggestions:

I suggest you to use the loop mode (TX & RX enabled) with external TX to RX connection. Then you can measure the SCI0_TX pin for generated data. You can measure the TX data whether it is right and also the input RX pin. Then the send data must be in receive data register. There is one mistake in RM – the SCI0 is on PORTS[1:0], not as mentioned in RM in Table 2-26 / PTS1 and PTS0.

I hope it helps you.

Best Regards,

Stano.

[roberthiebert]

Hi Radek and Stano,

Thank you for your suggestions. Stano, I believe the error in the Reference Manual you are referring to is on page 126 where there is a typo in the descriptions for  for PTS1 and PTS0 describing them as pins 3 and 2 respectively. I am using PTS1 for SCI0 TX and PTS0 for SCI0 RX. I don't think it matters, but I added code to initialize Port S as all inputs with pullups enabled. It didn't make any difference. I also added code to clear the flag in the interrupt routine, but that didn't make any difference either.

I think the problem is that for some reason I am not entering the ISR at all, because PB2 never gets set. I am using CoolTerm terminal connected at 115200 baud and I transmit a string, actually just a single character. As I understand it, as long as the receiver and it's interrupt are enabled, when a character is sent from the terminal the ISR should be triggered and PB2 should be set. That isn't happening. I thought perhaps my baud rate was wrong, but I tried all available rates with no response. I thought perhaps I had my bus frequency wrong, but I don't think that is an issue. I am quite sure that the hardware is good because it works well on another program with similar setup. I also thought I may have done something wrong configuring the interrupt vector, but I don't see anything obvious there. I checked that PB2 would set correctly and it does. It really is quite puzzling. I am attaching my latest program, this is all there is to it so there isn't anything else that could affect anything.

Regards,

Robert

Robert

[RadekS · Accepted solution]

Hello Robert,

thank you for your check.

My notes about flag clearing code should be more general. Sorry for the confusion.

Please add flag clearing code into RTI ISR.

I mean for example something like : CRGFLG = 0x80;    // Clear the flag (here in C code)

Since RTI and SCI0 have the same priority (1), the core execution will run in the loop inside RTI_ISR.

RTI vector is higher than SCI0, therefore it wins and you never reach SCI0_ISR.

BR

Radek

[roberthiebert]

Hi Radek and Stano,

Thank you gentlemen! It made sense to me that the RTI interrupts would take priority over the SCI0 interrupts and because they are happening so fast, SCI0 may never get a chance to say anything. I disabled the RTI and the SCI0 interrupt worked right away. Then I changed the SCI0 priority to 2 and enabled RTI. Everything worked. Then I put them both back to level 1 and made sure I cleared the flag in the RTI interrupt routine. Everything worked. So It looks to me that the problem was that I just didn't clear the RTI flag. That was a good lesson, and I learned a lot of other things as well. Thanks so much to you both.

Regards,

Robert

robert 

[StanoA]

Hi Robert,

There is one feature on this family of MCUs – when such pin has several possible functions the “function precedence” is valid – (see Table 1-19/Sheet6 on p.56) the basic function in column Pin: PS[1:0] is changed to TXD0/RXD0 when SCI0 is enabled. The function which is more in right in table has precedence.

Did you check it in loop mode? What is the result? Are the send data on TXD pin right? If it is right, the BusCLK is OK and SCI0 TX line is OK. Then you can connect it externally to RXD pin and debug it by send one byte and check in debug mode the receive data register. If the data are inside, then check all generated flags and then interrupt.

I review your asm code and want to suggest you change the sequence of rows for clock setup:

movb #$07,REFDV

movb #$D8,SYNR

You need divide the external clock 16MHz to 2MHz as first and then multiply it to 100MHz in PLL. Otherwise the PLL VCO could be damaged by very high frequency in some MCUs.

The second think is the interrupt priority. Try disable RTI interrupt and enable only SCI0 interrupt. The RTI interrupt has highest priority so it is possible that the SCI0 interrupt can’t be serviced due to RTI active very frequently.

Please could you send me the schematic of your SCI0 connection too? I would like to check it independently if it is all OK.

I hope it helps you solve this issue.

Best Regards,

Stano.