SCI / Null character

[Scott134]

Does anybody know if a null character will trigger an interrupt or even be detected by the sci?

Thanks

[celsoken]

Dear Scott,

I know your problem was solved but I've got a big problem last week that looks like the description you gave so instead of opening a new topic, I've just appended here.

I was working on CW 10.5 with S08PA16 and noticed that the PA16 sometimes did not generate interrupts upon reception of NUL (0x00) character.

I've set a logic analyzer on the reception frames, toggled a pin based on rx interrupt and noticed that all problems detected were related to NUL reception.

Thanks to Mr. Marco Aurelio from Siletec (FS brazilian distributor) the problem was solved!! He pointed me that the problem was related to the uC trimming procedure.

CW 10.x changed 31.25KHz default trim frequence for internal osc to 32.768 KHz. This results in 4.86% frequency drift which brings in cumulative problem on NRZ protocol.

This happens exactly at the middle of stop bit, signalling a false framing error.

I believe this happens only on NUL because with any other character there is at least one edge that is possibly related to a hardware resync procedure.

Changing the trimming to the old default value (31.25KHz) made all communication problems disappear.

I hope it helps someone.

Regards,

Celso

[KevinBrandt]

Celso,

Thanks for the info. I am using CodeWarrior for MCU 10.6 and developing a project using MODBUS RTU on a MC9S08PA4 using 38400 baud, even parity, & 1 stop bit. I have been battling this very problem for the last few weeks - NUL characters do generate an interrupt but also set the framing error flag. Processor Expert shows that the CPU internal frequency is set for 31.25KHz but when I measure bit time with a transmitted character of 0x55 with an Oscilloscope I get an actual bit time of 24.6uSec or 40650 baud (a 5.5% error)! If I attempt to change the CPU internal frequency to 29.52KHz to correct the situation, then CodeWarrior complains that the value is outside acceptable range and will not re-compile my code. So far the only work around I have tried that works, is to adjust my desired baud rate to 37037. This yields an actual bit time of 25.6uSec which is an actual 1.7% error and works. I don't like this solution because at 1.7% error I do not feel comfortable that the baud rate mismatch error is close enough to guarantee consistent reliable communications.

But at least now I understand what is going on.:smileysad:

Thanks

Kevin

[peg]

Hello,

There is no automatic analysis of recieved characters apart from 8 or 9th bit checking for wake up if so configured.

What are you trying to achieve?

Of course when you move it out of the SCID you will set the zero flag in the CCR like usual.

[Scott134]

Hi Peg,

Thanks for the responce.  I am trying to detect the end of a data stream that ends in a null character.  It appears that I get the interrupt (I think) but I was not detecting the null character.  I thought of the zero flag in the CCR and I have some other approaches I thought of after sleeping.  I will keep you posted.  Thanks again.

[peg]

Hi Scott,

I actually slightly miss-understood your question, I think. I thought you were thinking that something special might happen BECAUSE it was a null. I now think you were asking does a recieved null act just like any other character. Well yes it does. The SCI has to be able to understand binary data, not just ASCII or null terminated strings. As rocco added, it is even dumber than that, as long as something like a start bit is recieved it just interprets whatever is on the pin after that and always generates RDRF (if it was clear) and generates an interrupt if configured so no matter what the data was, along with possibly setting an error flag.

[Scott134]

Hi Peg,

It appears that the null character does not generate an interrupt or the device is really not sending the null character - still experimenting.  Thanks for the responses and I will keep you posted.

[bigmac]

Hello,

Another useful tool for monitoring serial ASCII data is to use a PC based terminal program that is capable of displaying non-printable ASCII character, including the NUL character, in addition to the normal printable characters.  Alternatively, some terminal programs are capable of showing the received bytes as decimal or hexadecimal values.

Regards,

Mac

[PeterHouse]

Try not to think of it as a null character. It is a valid byte of data with all the bits set to zero - a start bit followed by 8 zeros and a stop bit or two depending on your communication settings. Only in C and other high level languages is it a null character with any special significance. To the micro it is nothing special.

If you are communicating to it using a PC and a high level language - it can sometimes be difficult to send a byte with a value of zero to a serial port. Make sure this is not your problem. An oscilloscope can be a very good friend about now.

Good Luck.

[Scott134]

Thanks for all the info.  I am aware of most of the tools mentioned.  I found the the device was NOT sending a null character as I was lead to believe. I had to modify my code, but all seem to work.  Never trust others for info and don't always believe spec sheets.  Thanks again.

[AndersJ]

Why not purchase a serial analyzer at www.fifo.se to check if the null byte is actually being sent.

AJ

[rocco]

To reinforce what Peg said: Any time there is a "start-bit", there will be an interrupt. It doesn't matter what the character that follows the start-bit looks like. It doesn't even need to have a "stop-bit", although lack of a stop-bit will cause a framing-error.