Extra Byte received from SCI in HCS08

[ashushetty]

Hi all ,

I am working with MC13213 controller. i have written a code for SCI communication .
      ucStatus = SCI1S1;
      SCI1D = DataBuffer; ( data buffer which is to be transmitted)

      SCI1C2 = (RX_INT_ENABLE | RX_ENABLE | TX_SHIFT_REG_INT_ENABLE | TX_ENABLE); //TE bit enabled

now my isr gets activated.

    SCI1C2 &= ~(TX_SHIFT_REG_INT_ENABLE);
   
     SCI1C2 &= ~(TX_ENABLE);// TE bit disabled

This works really fine and i can transmit data easily without any error.

The problem is coming when on the same board we have interfaced MC13213 to MCHCS12DP512 (16bit controller) . The TXD1 of MC13213 gets connected to RXD1 of the MCHCS12DP512 . The moment the TE bit is disabled a character "0" gets transmitted. Is this the idle character which gets queued up?? But why doesnt it appear when i use only MC13213 with a serial port connected to hyperterminal. why is this happening only i interface those two controllers?

[bigmac]

Hello,

Do you actually wait until the transmission of the final character is completed before clearing the TE control bit?  It is a good idea to monitor the TC status flag, and release TE only after the flag becomes set.  Why is it necessary for your application to disable TE?

Another possible situation is that, when TE is released, the TxD pin will revert to GPIO, and the output state will be determined by the particular pin settings.  This should be a high output setting, or an input with pullup enabled.  This will ensure that the idle state continues after disable.

With either of these scenarios, it is possible you would also get a framing error at the receiving end.  Hyperterminal will probably ignore characters with framing error.

Regards,

Mac

Message Edited by bigmac on 2007-06-25 11:34 PM

[ashushetty]

Yes i am checking for TC flag , the complete code is as follows:

ucStatus =SCI1S1

 if((FALSE == g_ucSerialTxFinish)&&(ucStatus & TX_TRANSMITTER_EMPTY_BIT))
  {
    if(g_ucSerialTxDataIndex < g_ucSerialTxDataLength)
    {
      SCI1D = g_aSerialTxDataBuffer[g_ucSerialTxDataIndex++];
    }
    else
    {
      g_ucSerialTxFinish = TRUE;
    }
  }
  else
  {
    if ( ucStatus & TX_TRANSMIT_COMPLETE_BIT )
    {
      // All done - turn off the transmitter
   
    SCI1C2 &= ~(TX_SHIFT_REG_INT_ENABLE);
   
     SCI1C2 &= ~(TX_ENABLE);
              }

and also in the initialization of serial routine , i m doing:

  // Setup port E bit 0 (TDX) as output and set low
  // Enable the pull up on the TDX line
   __asm BSET 0,0x11;

so where is the problem? hyperterminal never ignores any values. " 0x00" this also a character,,how it can ignore?

regards

ashwini

[bigmac]

Hello Ashwini,

There seems to be some confusion about my previous post.  The SCI idle state is logic high at the TxD pin, so when TE is disabled the GPIO pin should be a logic high output (not low).  When the pin is set as an output, the pullup setting will have no effect.

With your current output state, and when TE is disabled, the remote end will see a start bit followed by zeros, but no stop bit.  The lack of stop bit should be detected as a framing error, and this is why it is unlikely that Hyper terminal would respond.

Regards,

Mac

[peg]

Hi Mac,

I just tested Hyper terminal before I made my previous post and it does not respond to a correctly framed null. So I presume it would not do anything different to a stop bit-less null either.

Hi Ashushetty,

Bigmac's previous question about why you are disabling the transmitter still begs for an answer as well.

[bigmac]

Hello Peg,

An extended "stop bit-less null" should actually represent a break signal (or perhaps a succession of breaks).  But this is probably unecessarily complicating the issue.  In the past, I have used the detection of a break (null character + framing error) to initiate a soft reset.

Regards,

Mac

[ashushetty]

I observed the output on the "advanced serial port tool" , so i cud see a " 0x00" , probably as u say i will check for framing errors  and also my TXD pin has been configured as input .

Well why we want to disable TE bit is to save the current drawn and when ever transmission is required TEbit is enabled

one more thing is (referred from data sheet) "

To avoid extra current drain from floating input pins, the reset initialization

routine in the application program should change the direction of unused

pins to outputs (programmed low) so the pins do not float. Outputs

programmed low is the preferred option for lowest power

" so shud i go for this ?

[rocco]

Hi Ashwini,

Although an "output-low" might be the lowest power for an "unused" pin, your TxD pin is not unused, and the lowest power would be determined by the device that the pin is connected to.

My understanding of the power consumption of unconnected pins are as follows:

• as an output, programmed low. (lowest consumption).
• as an output, programmed high.
• as an input, with the internal pull-up off, and with a very high value external pull-up.
• as an input, with the internal pull-up on.
• as an input, with the internal pull-up off and the input floating (highest consumption).

In your case, I would set the GPIO as an output, programmed high. This way, the serial data will be in the "idle" state when the SCI transmitter is disabled. I don't think there will be an appreciable difference in current consumption from the "output-low" state, but that would be determined by the input current of whatever device the TxD pin is driving.

[peg]

Hi,

I don't know what an "advanced serial port tool" is!

OK, understand that you are disabling to save power. But generally you would want the TXD's pins shared GPIO to be configured as an output set high to simulate the TXD's idle line state of '1'.

If you set it low then when you disable TE the line will drop low and you will generate a NULL without a stop bit. If the other end is picking this up as a null even though it had no stop bit then you have a problem. The way I see it you have two choices.

1. set the TXD GPIO as out high (probably very little difference from low)

2. modify the other end of the link to ignore nulls with framing errors (or breaks as Mac pointed out)

Don't forget about any "not bonded out" i/o in your quest to lower the current draw.

[bigmac]

Hello,

Actually, a third choice is possible, as previously mentioned -

3.  Set TxD GPIO pin as input, and enable pullup on the pin.

I would expect this to draw current similar to choice 1.  Have you also taken into account the current drawn by the RS232 interface device?  This will likely be a significant amount.

Regards,

Mac

[peg]

Hi,

Presumably, if the OP is concerned about the different current draw of output high to output low then he would be using a shutdownable driver. This may then dictate what is best done with the pin when transmission is finished. Maybe out hi - shutdown - out lo?

[peg]

Hi again ashushetty,

Most (all?) of the time hyperterminal will not do anything on the screen when it recieves a 0x00. Most other values will produce ASCII characters or other symbols or just a space, but 0x00 causes NOTHING visible to occur!

Don't forget that you or the reciever can't actually "see" an idle character. It's just the same as nothing. It only exists to easily produce nothing for just the same time as one character.

It is not actually that easy to "accidently" produce a null given that it is 9 consecutive bit times of zero.

It is easier to accidently produce characters with the uppermost bits set.

This of course is true only for characters recieved without framing errors.

How do you know you are generating a 0x00?

Is it recieved without a framing error?

[peg]

---

bigmac wrote:

Hello,

Do you actually wait until the transmission of the final character is completed before clearing the TE control bit?  It is a good idea to monitor the TC status flag, and release TE only after the flag becomes set.  Why is it necessary for your application to disable TE?

---

According to the datasheet this is not actually required:

Writing 0 to TE does not immediately release the pin to be a general-purpose I/O pin. Any transmit activity that is in progress must first be completed. This includes data characters in progress, queued idle characters, and queued break characters.

[peg]

Hi ashushetty,

Do you mean you recieve a null byte or a byte value 0x00, rather than character '0', 0x30?

If so then this is just a limitation of using hyperterminal for this purpose, it will not respond to a 0x00 sent to it.