headsup with SCI migrating from HC12

[imajeff]

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!

[mke_et]

You know, I've heard about this error/caveat from way back, and I've never seemed to be bitten by it. But then, maybe it's because I was bit by the 'letnI' bug so many times that I write my routines differently and that seems to mask the problem.

With that 'other' family of parts, there were tons of problems with the 8259, and especially with master/slaved 8259's. Phantom interupts and lost interrupts.

Anyway, I've always (since the early 80's) written my ISRs as 'poll' routines first, then used the ISR to just call the poll routines in a loop multiple times until all the status bits clear. That also means the ISR has to have an exit on 'no' interrupts.

I'm just wondering it that would clear the problem or if I just happen to have hidden the problem with something else I did in my code.

[imajeff]

I'm curious what the 'letnI' bug is. I googled "letnl bug", and came up with some interresting things.

As for the 'other', yeah, I knew there would be old implementation flaws. But I've been mostly interrested to jump into 32-bit, having true 32-bit addressing (get out of the dreaded memory banking). Yeah I know Freescale has some, but I just don't see the support that I do for others.

When you write your ISR so that it loops until all flags are cleared, then yes you would avoid this problem. It just would not give you the optimization (run slower, more code). I admit it's less often that an implementation really needs it, but then again maybe polling was all you needed, and the ISR is just unnecessary risk.

[mke_et]

letnI comes from 'The Knights who say letnI' which was a reworked section of Monty Python's King Arthur and the Holy Grail.

We are the Knights who say letnI.

We demand a sacrifice.

We want ...

A SEGMENT REGISTER!!!

Written by one of the engineers at Tandy during the Intel/Motorola wars.

Anyway, the letnI bug(s) I was refering to were the issues with the 8259. Like the phantom IRQ7's that occured if you didn't hold the int pin during the ack cycle. Or the way the pending worked when you did master/slave interrupts (Better check in service before you did EOI to a master if the int came from a slave). Or _____ (fill in the blank). Oh, the 8259 wasn't difficult to use, once you figured the thing out. At least it stayed consistant.

Message Edited by mke_et on 2007-06-18 03:03 PM

[Lundin]

I haven't heard of this particular error before, which maskset(s) does this apply to? Only to the B masks or to newer ones as well?

[imajeff]

The problem exists in the newest mask set of MC9S12: DG128, DP256, etc. (all compatible variations; I'll not guess which).

Keep in mind that the logic of newer masksets is arguably valid. It is just a difference in the requirements. Basically, I am trying to say that FSL has openly DENIED it as "error" in this design. It's just that I easily have problems in software ported from HC12.

I really am not certain the details exactly how HC12 worked different than S12 in this case. The bottom line is simply that if you don't learn to handle OR (overrun) after reading the rx char which triggered the ISR, you can end up with the OR flag set but never triggering another ISR and never getting RDRF because it cannot trigger when OR is already set.

[imajeff]

I'm beginning to wonder whether there is actually a flaw in Freescale design, not just a difference. I thought the documentation, in general, said that if an OR flag is set, it is supposed to trigger an interrupt. Isn't that supposed to be the case?

The problem in S12 seems apparently that the OR (overrun) flag is not generating an interrupt (only the RDRF that is sometimes accompanying it), so the ISR is not called. It tends to look like the same problem as explained in SCI errata MUCts00510, though it is not the same.

[Alban]

Good Evening Ima,

Yes, SCISR1_OR shall generate an interrupt if SCICR2_RIE == 1;

If you have a soft reproducing the error, may you please enter a Service Request for analysis ?
Don't hesitate to put a link to this thread so the TSR (technical support representative) have all elements.

Cheers,
Alban.

[imajeff]

Oh great... Thanks for responding, Alb 

Isn't it funny how much I've complained and re-explained before somebody representing FSL finally admitted that it should not be this way. But I'm glad you agree because it does make sense that OR should trigger the ISR.

Unfortunately, the software where I verified this is a large multipart system for my employer (a neat-o wireless control system running FreeRTOS). If I'm right about the system, there should be a simple way to reproduce. Of course if you know a good way to get OR set but not RDRF, then you know more than me.

Hopeful Reproduction

1. Wire SCI0 tx back to SCI1 rx (maybe works on same SCI port, i.e. loopback).
   
2. Send first byte on SCI0 tx.
   
3. ISR is called when SCI1 RDRF comes. Read SCI1SR1. Note that RDRF is set but not OR, therefore only 'arming' RDRF to be cleared.
4. Within the ISR, send another byte on SCI0 tx
5. Wait for the OR flag.
6. Read SCI1DRL, which is where we were in the process of reading the first byte. I am assuming this is where the RDRF got cleared but not OR.
7. Return from interrupt, and see if it really jumps right back to the start of the ISR. Anything else verifies that there is new SCI errata to fix.
   

Now, who wants to be thouroughly thanked by writing this code to help solve the mystery?  Thank you very much.    --jeffs


P.S. I love the fact that this forum now enables rich-text editing for Firefox on Linux. I no longer have to type in my own tags manually. Thanks!

[Alban]

Hello,

As I entered the Service Request, I will receive the updates...

The report is logged under SR# 1-365947664.

It seems an important enough claim to be investigated and usually Jeff, you are good at this !
You probably know that it is not only a matter of complaining, but there is Who you complain to and How you do it.
I'm really surprised that a FSL employee was not receptive. There is no incentive in hiding things, quite the opposite actually.

Cheers,
Alban.

[imajeff]

Yeah sorry I ran out of time on this.

Don't forget it depends on what state of mind the FSL person is in, and which of my words they choose to focus on. In the case of the SR, unless I'm remembering wrong, this detail was just overlooked because there was at least one other thing I changed in my code to fix the problem (elevate the interrupt priority of SCI1). They tend to get the feeling that all they have to do is find that I missed something, and then they've done their job.

I might search later, but I've talked about this problem in at least one, maybe both threads before this one. I think it wasn't further back then last year though, that I was able to explain why it looked like the old SCI errata but was different.

[Alban]

Jeff,

I remember a story about the SCI that we talked about last year.
There was a pseudo-belief that Freescale was covering up because the thread was not imported from FreeGeeks.net. But that matter had been dealt with, I thought.

Is it the same issue ?

If you have previous SR#, please give them to me so I can look at what was done and not do it again.

Are you saying that if you put SCI Interrupt in HPRIO, the OR interrupt occurs and is executed ?

The problem with level of support is that people don't know the knowledge of their contact. As it is the source most of the time, they start with the basic questions.
The solution would be to put a flag on profiles: "This customer knows what he is talking about", "good in C".... But it causes ethics and also Legal concern I believe.

Cheers,
Alban.

[imajeff]

Alban said:
> Are you saying that if you put SCI Interrupt in HPRIO, the OR interrupt occurs and is executed ?

Let me explain a little more about what brought out the condition in my software. SCI0 was sometimes taking a little longer because it processed an entire packet after receiving, within the ISR (was a quick design). SCI1 was trying to do some continuous flow of data, so relying on the ISR to keep going. When SCI0 was delayed, however, SCI1 had lower priority and therefore was barely getting OR (i.e. sometimes occurring right between reading SCI1SR1 and reading SCI1DRL. That caused the freeze I'm describing now, where OR was set without RDRF set, and no ISR was called. At first I only solved it by polling SCI1 regularly (same workaround as for famous SCI errata). Finally, the engineer handling my SR thought of suggesting HPRIO on SCI1. That way, the more-delayed ISR for SCI0 was not higher priority, and allowed SCI1 to be serviced before getting an OR. That would not have solved the problem in other situations, just happened to work on my software, and helped me discover what was really happening.

> The problem with level of support is that people don't know the knowledge of their contact. As it is the source most of the
> time, they start with the basic questions. [...]

I've stated before that I am not accusing FSL of covering up (no matter how much their employees make it look like they are), and I am not saying that the problem is them not knowing how experienced I am. If I forget to tell them that I've already tried plugging in my PC first, then they have the right to ask if I did. The problem was that they assumed the first thought they have is the problem, and would do something annoying to me like hang up on me (close the SR) instead of just asking me if I tried that, and then expecting a response from me even if it is, "thanks I had not thought of that".

I think now the issue we are talking about is the fact that you (or maybe FSL) did not understand what I was asking when I asked if this problem with OR was known. Well, as many times as I've found out that FSL just does not care, I have given up trying to cram this information down their throat. Thank you, Alban, because you do listen to me. It's just that I doubt now that any results will come of it via FSL.

Good day,   --jeffs

[imajeff]

I finally found the first thread I started about it:
http://forums.freescale.com/freescale/board/message?board.id=16BITCOMM&message.id=1199

You can see there that it was bigmac who responded, not Freescale, but he did refer to documentation which knew about the problem. Of course this is why I would have not bothered to submit another SR, even though it seemed like a design flaw to me.

Maybe there's nothing we can do about it though, because FSL already documented in "(S12SCIV2), on page 20 of Revision V02.08", therefore they are happy with the product.

[Alban]

Hello,

I am not sure to get it. I put my SR on hold in the meantime.
If it is documented in the device block guide, I don't see how it can be qualified as a flaw of the module.

At worst it is not designed as expectable.
But if the document states something, and the device works as documented, I understand why no erratum was issued.
An erratum is to state that the device is not working like specified.

Alban.

[imajeff]

Does the current documentation say it? Apparently I still have one that does not (S12SCIV2.pdf V2.05), at least not on that page, nor everywhere I've looked. I don't see it in the "Functional Description" either. But does the latest have it added?

Of course, I have studdied that part of the docs a few years, so I would not have trouble if it was in my docs. It is still not, so I hope it's not just hidden in one of the doc revisions.

Well thanks anyway.


Update: I verified that the latest doc , supposedly 2.10, has other problems. Within the doc (S12SCIV2.pdf), I see NO version information, nor title page, nor revision history. It just starts with "Chapter One"... [of what??]

No header information, even, to show any revision number. I cannot accept that as an official document... nobody should!



Message Edited by imajeff on 2007-06-11 09:03 AM

[Alban]

Hello Jeff,

I was asking confirmation, because in your post I read:

Maybe there's nothing we can do about it though, because FSL already documented in "(S12SCIV2), on page 20 of Revision V02.08", therefore they are happy with the product.

Which I understood: that is documented.

I'll report to datasheet owner about the lack of covering page. The downloading location should still show a version number though, even if not in the document itself. I see Rev.13 for the package of S12DG128, the product I think you are referring to.

Cheers,
Alban.

[imajeff]

Alban,

Besides the fact that I do not find the V2.13 that you see, here is the other issue more clearly:

Maybe there is some confusion between two issues. The question I had before was a combination of both problems:

1. The OR flag should trigger an interrupt.
   
2. My original thought was that the RDRF flag should always be set if OR is set.

Concerning #1, I can see a big problem. The S12SCIV2 does describe that I would need a dummy-read of SCIDRL if OR is set after reading a byte to clear RDRF, but it does not state, nor even imply, that OR will not trigger an interrupt. It is apparent from the register description before that, all these error bits should still trigger an interrupt.

Concerning #2, This is the thing that is documented in a tiny note in one place in S12SCIV2, and only starting at unknown revision after the one with good title pages which is V2.05.  If FSL chooses to randomly add a little side note in one spot of the next revision of Reference Manual instead of pointing out the unexpected behavior in "errata", then you are right, I should not complain. I should merrily move on to a reliable manufacturer, with which others are actually happy. [And I mean only after someone twists my ARM for so long...]

[Alban]

Hello Jeff,

I think we are referring to the same document. The revision 13 I mention is for the whole ZIP file and is not for individual files.

There are differences between a "spec clarification" and an "erratum". The second one means that the MCU does not behave as specified whilst the first one means that we had all the elements already, but that because confusion was reported, the manual was updated to avoid that confusion.

Now coming to 1...
I didn't know I would have the revelation at 4am, but I do understand fine now.

The SCI module has only ONE interrupt vector. By this, it means that Errors have to share the same interrupt subroutine as Normal transmission.
Then, I tought about... What is an Over Run condition ?
The OR condition means that the module received a new data but data previously received was not read. And that is the key! "The module received a new data" so an interrupt is generated when OR occurs, this is the interrupt occuring when the data is received.

An OR cannot occur unless you have a valid reception.
If the OR flag itself was to generate an IRQ, it would mean you would get a DOUBLE interrupt to the same vector in a case of over run:
- you would get the Receiver Full, because after all a VALID data was received,
- and the OR condition.
But which Interrupt source should be set first ? I mean to be in a case of OR, you need to have received and overwritten the previously received data, therefore you have to get Receiver Full first.
But you need to know before reading the receiver data that you skipped at least one to know where to put that data.
These two last conditions are contradictory, and it would be highly in-efficient to generate two IRQ back to back to execute the same ISR !

So what does make sense for the software ?
As OR cannot occur without RDRF, then you only need to generate an IRQ for RDRF.
Then, when the software enters the ISR, it can check if the valid value has overwritten the previous.

Generating an IRQ for each bit would only make sense either if RDRF and OR were independant events (which it will never be) or if we had a separate interrupt vector for Receiving and for Errors (like for the msCAN).
#1 - Therefore it is logical and normal that OR itself does not generate an ISR

On the second point.
Clearing a flag has a certain procedure. If RDRF is cleared and nothing has been done to clear OR, then RDRF is cleared when OR is set.
#2 - It means that the error condition does not clear by itelf and you need user intervention.
(May be the user receives by bursts and only want to check, out of the ISR that the data in the buffer is correct)

I hope it is now as clear for you as it is for me.

The document (S12SCIV2.pdf and the ZIP archive) will still have to be changed for the reason I gave previously.

Regards,
Alban.

[imajeff]

[I won't argue about the double interrupt on overrun, even though you should realize that there were indeed two characters received, therefore two interrupts is not incorrect.]

Great, though it does not solve the problem of non-backwards compatibility with HC12, but that's not a requirement.

I came to the same conclusion/revelation, before I started this thread. I was right to think you're pretty smart   I started this thread because of the lack of compatibility (requiring more software changes to migrate from HC12).

In that case, here is a quote from the docs which needs changed.

Section 1.3.2.4 of S12SCIV2 says:
''
The SCISR1 and SCISR2 registers provides inputs to the MCU for
generation of SCI interrupts. Also, these registers can be polled by
the MCU to check the status of these bits. The flag-clearing
procedures require that the status register be read followed by a
read or write to the SCI Data Register.It is permissible to execute
other instructions between the two steps as long as it does not
compromise the handling of I/O, but the order of operations is
important for flag clearing.
''

It should not say that the whole register(s) is "for generation of SCI interrupts". Instead it should specify which bits either in this paragraph, or more likely in the description of each bit.

NOTE:
I used to think that with this method, my ISR would have to check for OR twice. First before reading the DR (so I'd know that I've already lost it), and second after reading, in case the OR occurred just before reading DR. Rather, I see that because it preserves the previous byte that arrived first in the DR, then I really have that data stream intact right up to the OR which occurred after the byte my ISR is currently reading. I only need check for OR after reading the byte that generated the RDRF. I do like this way better.

Thank you Alban!

[imajeff]

Don't worry, I have not been lost in the conversation... I have understood your meaning. You do realize that was a quote (of course from the old thread). I knew that you would be confused about the V2.08, but was hoping that you would read the thread that I referred to. I did already waste my time back then, explaining that it was not in my version of S12SCIV2, and that I have no capacity to guess when to re-download each of the countless document files. I did explain that there was another flaw in the new one which said nothing about what revision it was. I am frustrated again because I do not benefit from having to say all of this yet again.

I have already gone through all this in previous discussions. Of course I did not remember everything from other threads, so I had to search and find out. And yes, somehow the missing title-pages in "S12SCIV2.pdf" is yet unresolved. I hope you will understand that I am sick from the SR thing. I won't have time to argue with tose guys anymore. Sure I eventually got something done in many of the SR I have submitted, but it was not worth the time I spent.

To see V2.10 as the latest, look here:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC9S12DG128
(In the Documents tab)