Jeff Smith

headsup with SCI migrating from HC12

Discussion created by Jeff Smith on May 16, 2007
Latest reply on Jul 3, 2007 by Jeff Smith
I'm just letting people know about an important difference between my project using XC68HC912BC32 and the upgrade to MC9S12DG128B. I am not sure what the exact difference is, but the HC12 worked without flaw, and I have finally found what the 9S12 needed.

First of all, my project uses an SCI rx (input) to read a pre-recorded "NRZ" serial signal from the right track of an audio player. Those control codes are controling servos of a robotic character, so that it can be animated while playing audio from the left track. Using our original hardware with HC12, I thought it was great that I could just stop/start the audio or trun of/on the robot and it would always quicly restore contol from the control track.

Now when I upgraded the hardware to use the DG128B, I didn't see any problem because it is fairly straight forward, and the documents don't say any difference really between the SCI port of the two targets. It seemed verified when I only made simple changes to make the software work with the S12 target.

Unfortunately, our production team found that there was indeed a problem. Every time that the audio (with SCI control track) was playing before powering up the robot, the SCI would "freeze". Though input was getting to the MCU as expected, it was stuck in a state where no data was received (seemingly ignored).

While researching, I came across my old complaint about the new hardware, when I was accusing a newer maskset of still having the SCI errata MUCts00510, "SCI interrupt asserts only if an odd number of interrupts active".  Well, as Freescale stated, that was not the problem I was experiencing. But here is the problem, yet again, that I was indeed experiencing:

It did not really have to do with the SCI interrupt itself, but the symptom was that the SCI would get stuck in an error state and no longer trigger an interrupt, therefore completely ignore SCI further input until reset. The flag OR (rx overrun) would understandably be set, but that should simply be cleared when the character that was pending at the time of the overrun is read. So my software ignored the OR and other error bits. Well, that worked just fine until the upgrade to 9S12. Now it seems that it will often end up with the OR bit set, but not the RDRX, therefore does not call the ISR!

However stupid the design may be, at least there is a workaround provided you can realize that this is what is the problem. I simply made the ISR check and clear the OR at the end, after reading the next char available (not before, that still allowes OR to trigger between ISR reading of status and data, which does not clear the error).

So although I didn't save myself yet another painful problem-solving session, I hope that this helps others.  Good day!