This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SCI Length field in SCIFORMAT does not accept an update if the shift register is not empty.

Other Parts Discussed in Thread: TMS570LS1227

I am using a TMS570LS1227, transmitting in multibuffer mode, and want to use the TX interrupt.

The interrupt is thrown by the TMS570 hardware when the last character is written to the transmit shift register (TX RDY). However, at this point, that character has not been driven onto the TX line (confirmed with a scope trace).

In my ISR, I recalculate the new LENGTH field of the SCIFORMAT register, update the SCIFORMAT register, and then load the new data into the multibuffer.

The hardware, instead of utilizing the new LENGTH parameter, transmits the previous LENGTH's work of characters. However if I put a simple delay into my ISR such that the SCIFORMAT register is not updated until the transmit shift register is empty, the new LENGTH is utilized without a problem. It seems that the LENGTH parameter cannot be changed until the multibuffer and the shift register are both empty.

Am I missing something?

Adding a delay to the ISR (as done above for testing purposes), is not an option for me.

Thanks in advance for any assistance or insights any responders can provide.

  • Hello Richard,

    I have forwarded your question to one of our SCI module experts so they can give further details on the inter-workings of SCI TX Interrupt, the TXRDY and TXEMPTY flags in relation to setup of the next set of data to be transmitted.

  • Hi Richard,

    UnlessTX EMPTY bit is set you cannot change the SCIFORMAT register. You can wait for the TX EMPTY bit to be set instead of delay.

  • Prathap,

    Thanks for your response. Although it answers the question, the answer is unsatisfying.

    Waiting in an interrupt routine for a secondary event to occur is not reasonable. From a user's perspective, it would have been better if the on-chip implementation allowed the interrupt to be thrown on either TX READY or TX EMPTY. Perhaps in a future version this will happen.

    Richard