TMS320F28379D: SCI RXENA Register

Hi Tony,

Tony Cline said:

1) Confirm Tech Ref is the correct SCI block diagram.

You are correct, the Technical Reference Manual for F2837xD has the correct placement of RXENA. Thanks for pointing this out-  I have noted this difference between datasheet and TRM and will look into why this has occurred and if it is already documented to be edited.

Tony Cline said:

2) I currently disable RX inputs by de-asserting the RXENA bit prior to transmitting the response packet.  Once TX packet has been sent, I re-assert RXENA.  Based on the SCI Tech Ref information, I see no reasonable way to clear/flush the RXSHF register after RXENA has been re-asserted.  Therefore, even though RXENA has been de-asserted, 8 bits of TX data will be received into the RXSHF register.  What am I missing?

Once data is in the shift register, if TXENA/RXENA was not disabled already, it will go to the next stage before closing. You cannot clear data once it's in the shift register if transfer to FIFO for RX has already begun. But if it hasn't started transfer yet, you can clear using SWRESET.

Tony Cline said:

3) I need a reasonable way to flush the RXSHF buffer.  Since command/response occurs approx. every 100ms, it's impractical to do any sort of SCI re-boot every time RX is re-enabled.

I am not aware of another direct way to do this, but I'll look into it more and let you know if I find another way.

Best Regards,

Allison

Thank you Allison.  A few comments:

1) You're welcome.  This is a big deal however.  I engineered the HW to the data sheet and only referred to the TRM once I observed anomalies.  Operationally, the RXENA bit behavior is completely different between the two block diagrams.  A head scratcher why TI went with the current embodiment.

2) Data will be shifted into the register during the TX operation due to loop-back as explained earlier.  Since there are 11 TX bytes I'm assuming the last byte will ultimately end up in the register when TX has finished transmitting.  At that point, RXENA will be re-asserted.  At that moment, the RXSHF register will be full (8-bits).  Q: Is that when the transfer to FIFO occurs?  So, I need to know exactly when the transfer to FIFO occurs.  Perhaps I issue a SWRESET before I re-assert RXENA????

I have tried, without success:

EALLOW

ScibRegs.SCICTL1.SWRESET = 0 ;

ScibRegs.SCICTL1.SWRESET = 1 ;

EDIS

I've also tried, without success:

EALLOW

ScibRegs.SCICTL1.all = 0x0003 ;

ScibRegs.SCICTL1.all = 0x0023 ;

EDIS

Next, I will do a SWRESET BEFORE I re-assert RXENA.  Fingers crossed....

Best regards and thank you as always.

Allison,

Unfortunately, that did not work.  Here is the code:

ScibReg.SCICTL1.bit.RXENA = 0;

For(...){ send 11 bytes TX data }

DELAY_US(100) ;

ScibRegs.SCICTL1.bit.SWRESET = 0;

DELAY_US(100) ;

ScibRegs.SCICTL1.bit.SWRESET = 1;

DELAY_US(100) ;

ScibReg.SCICTL1.bit.RXENA = 1;

I also tried resetting the FIFO pointer and re-enabling RX FIFO operation immediately after SWRESET=0.  Still no luck.

ScibRegs.SCIFFRX.bit.RXFIFORESET = 0 ;

ScibRegs.SCIFFRX.bit.RXFIFORESET = 1 ;

Q: After SWRESET, is there any other action/initialization that needs to be taken??

-Thanks.

Hi Allison,

Should we reach out to others at TI for thoughts and suggestions?  Customers in town tomorrow...

Hi Tony, 

While RXENA does not prevent the data from entering the shift register, that SCI reset should clear the shift register. Are you seeing only the last byte of transmission appear in the RXFIFO still even with the reset? We will try to test this out on our end as well. 

Best Regards,

Allison

Thank you Allison for the reply.  A few comments.

I should note that I have two HW configurations: One is RS422 and the other is RS485.  We offer either comm interface to the customer.    They both use the same exact F2837xD part w/identical firmware.  The RS422 config uses ICs that do not incorporate loop-back meaning the Tx data are not looped back to the Rx side of the IC.  The RS422 version is working exceedingly well -no issues what-so-ever.  The issue we are dealing with in this thread only applies only to the RS485 config.  I thought that is worth mentioning.  FYI I've looked at the signals for both and both are clean.

Agreed, RXENA switch is post shift reg RXSHF per the TRM.  This is the heart of the issue!!

It seems there are two questions: 1) when does the contents of the shift register get transferred to the FIFO and 2) if I perform at SWRESET are there any other re-initializations that need to be performed?

If I issue a SWRESET to clear the shift register and THEN re-assert RSENA then all should be good -but it is not.  It appears issuing a SWRESET has other side-effects that I need to deal with.