TMS320F28075: SCI disorder after power up

Here is a point I am thinking about.

Currently, in customer code, they check TXRDY before writing the next byte to TXBUF:

xxxx(UCHAR uc_SendData)

{

   if(m_ptrSciRegs->SCICTL2.bit.TXRDY)

     {

         uc_SendData = uc_SendData & 0xFF;

         m_ptrSciRegs->SCITXBUF.all = uc_SendData;

     }

}

However, when I look into our driverlib code, instead of checking TXRDY, TXFFST is checked:

SCI_writeCharArray:

for(i = 0U; i < length; i++)
        {
            //
            // Wait until space is available in the transmit FIFO.
            //
            while(SCI_getTxFIFOStatus(base) == SCI_FIFO_TX15)
            {
            }

            //
            // Send a char.
            //
            HWREGH(base + SCI_O_TXBUF) = array[i];
        }

Thus, I am wondering when FIFO is enabled, is TXRDY still meaningful?  I am thinking that if checking TXRDY in FIFO mode cause errors like overflow?

Regards,

Brian 

Hi Brian,

I can't find anything specifically in the documentation to support this, but yes, my understanding is that in non-FIFO mode TXRDY is used to determine when to transmit and in FIFO mode TXFFST would be used instead.  Certainly it is worth trying to follow the driverlib code example if you are using the FIFO, or to alternately set the module in non-FIFO mode with the existing methodology.

Is there anything else in the system that corresponds to the 8 seconds of time where the transmit goes back to being as expected?  Is there an ISR that is starving whatever code is calling the send data function? 

Are you sure the send data function is always being called with parameter of '0x0D'? (you could add a check + breakpoint to detect unexpected data). 

You might also add a toggle of some other GPIO when the 'If' statement is taken in the send data function; this will let you know if data is being stuffed into the TX buffer faster than it is being sent.

Hi Devin,

Thanks for the advice. The problem has been fixed by switching from USB power supply to DC power supplier. We did not know what is the difference, but it works finally.

By solving this problem, we have moved to the real problem which is the same as we observed in shipped products.

In the products, after power power up, F28075 start to send data to another MCU:

Data: AA 2B 01 00 07 00 00 00 00 00 00 00 33 0D

1. Normally, the data would be transferred successfully:

 2. However, for the first 1 or 2 send. The last data (0X0D) would not be send successfully.

And after the first 1-2 times send, everything works fine.

I've suggest customer to check FIFO status instead of TXRDY, not it is not fixed.

Regards,

Brian

Hi Brian,

Since the issue seems to be somehow related to the power supply, have you measured or scoped the 3.3V and 1.2V rails during operation of the SCI? 

Is a transceiver (if used) powered from the 3.3V rail or another rail?  Have you measured or scoped this rail during operation?

Do you see this issue both on the customer systems and on a TI evm, or does this only occur in the customer system?  

Hi Devin,

To isolate the problem, I've suggested customer to remove the external connection and measure the signal on F28075 directly. But the problem still exists.

I would suggest customer to test on the EVM later, to make sure it is not influenced by the H/D.

BTW, what is the available 28075 EVM right now? I cannot find any launchpad on the website right now.

Regards,

Brian

Hi Brian,

The EVM for F2807x is F28379D controlCard or LaunchPad since the F2807x family of devices is an intentional pin-compatible cut-down from the F2837x family.  

I definitely still think investigating the power rails is a good experiment.  You might also try and see if current is getting injected into any of the IO pins due to an over or under voltage condition due to the use of the USB for power.    

Devin,

Thanks!

As I mentioned in the previous reply, similar problem is also seen in their products. This is why they are doing the single board experiment. Thus this problem is definitly not caused by USB power.

Regards,

Brian

Hi Brian,

I'm a little confused by which board(s) you are using to debug, but it seems like you had the same issue (0x0D is not sent correctly) and this was solved by changing the power supply?  Even if the board is different, I'd think investigating the power supply is a good first step.

When this code is running, is anything else going on in the code/system? If so, if you shut down other components of the system, does the issue resolve?

If you start the system but delay the first SCI transmission, does the error still occur in the first 1-2 transmissions, or not? Conversely, can you start SCI transmissions earlier and see if the issues occur for a longer period?