SCI - OR flg but no RDRF

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

SCI - OR flg but no RDRF

3,596 次查看
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.
标签 (1)
0 项奖励
回复
2 回复数

961 次查看
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 项奖励
回复

961 次查看
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 项奖励
回复