SCI - OR flg but no RDRF

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SCI - OR flg but no RDRF

3,110 Views
imajeff
Contributor III
I have told someone before, concerning SCI interrupts, that I did not think OR would ever be set without RDRF being also set. I hope that doesn't mess them up, because I had it happening to me which caused trouble.

I finally think I figured out how it works (correct me if I'm wrong):

The OR is cleared the same way that RDRF is cleared, and also will never be set unless RDRF is still set as another byte is received. That fooled me into thinking it will always be cleared at the same time RDRF is cleared. There is good reason why my assumption was false.

To clear either flag,
  1. read SCISR1 while the flag is set
  2. read SCIDRL
See, the key that makes a difference is this phrase, "while the flag is set". Since there are two seperate steps which take time, the OR could happen between the two steps. Since status was read with only RDRF set, the OR could still happen up to the point of reading data, and not clear because software has not yet detected the OR.

The only way I see to ensure clearing OR in the same ISR call instead of a separate call is to test for OR (and not RDRF) immediately after reading SCIDRL received.

Hope this helps others.
Labels (1)
0 Kudos
2 Replies

475 Views
bigmac
Specialist III

Hello Jefferson,

I notice that this issue is specifically mentioned in the SCI block guide (S12SCIV2), on page 20 of Revision V02.08.  The explanation given is as you have already said.

To ensure that both RDRF and OR flags are cleared, the following solution is suggested.

  1. read SCISR1
  2. read SCIDRL
  3. read SCISR1
  4. read SCIDRL (dummy read)

Regards,
Mac

 

0 Kudos

475 Views
imajeff
Contributor III
Huh, well, at least I figured it out.

Too bad details in the documentation are so often missed by those who need the information. This is evidence that it is not well written nor organized. I have V2.06 (which doesn't seem to spell it out at least near pg 20. I see no way to downloade V2.0.8. I normally don't know when it's time to re-download these things. Notice when I go to the device (DP256B) summary page, I cannot even see what revision is available, unless it is "Rev # 10". Doesn't seem the same naming system. Downloading that document
(http://www.freescale.com/files/microcontrollers/doc/ref_manual/S12SCIV2.pdf) I see no revision info, and not even an index. It took a long time for that reason to find a similar section, so I seem to find what you refer to on pg 9 of rev#10. This documentation mess is crazy, and could not resolved until all docs are radically improved (which would cause even more confusion).

If documentation like this was all fixed (facts easily spotted in text and better index to find specific info), perhaps Freescale's MC9S12 families could be considered the greatest general-purpose MCU of all times. What a sad way to lose reputation.

Thanks for pointing it out, anyway.
0 Kudos