TMS320F28379D: SCI-Address-bit Mode

Hi Tony,

Could you please expand on what you mean here: 

Tony Cline said:

Our first try with above change was unsuccessful. 

Was data able to be transmitted/received by the SCI at all? What was the behavior seen/symptom of the issue? What was the nature of how you tested? I'll take a closer look at the register values in the meantime and see if there's anything that seems to be off. 

Best Regards,

Allison

Good morning Allison,

Thanks for the reply -much appreciated.  I still do not have success. I've made progress, and have new updated information since my last post.

Background:

Since this is a very simple system with no other background tasks, I've implemented a SCI polling scheme within the main forever loop:

if(ScibRegs.SCIFFRX.bit.RXFFST != 0) {

    processIncomingChar(ScibRegs.SCIRXBUF.bit.SAR) ; }

I'd like to still maintain a polling scheme if possible.

I've tried initializing two ways: SCICTL1.all = 0x0003 (Rx sleep disabled) and SCICTL1.all = 0x0007 (Rx sleep enabled)

for the Rx sleep disabled case, I receive chars however, the values are incorrect.  For the Rx sleep enabled case, no chars are ever received.

I am able to Tx chars by writing to the ScibRegs.SCITXBUF.bit.TXDT register.  I am only ever the listener and therefore never assert the 9th bit in any frame.

That's where I'm stuck at the moment.  It appears polling may not work in addr-bit mode? 

It appears that in addr-bit mode, I must set b[2] in the SCICTL1 register at init.  Then, when any frame is received with the 9th bit asserted, it is interpreted as an addr and an Rx interrupt is thrown.  Within the Rx isr, the address can be checked for a match.  If true, Rx sleep is disabled to receive the remaining chars?  It appears the only way to know if the 9th bit is asserted is if an Rx interrupt is generated?

Hi Tony,

Have you tried using interrupts already instead of polling?

Perhaps this description from a related post will help shed some light: A read of RXWAKE in your RX ISR will tell you if a new frame has occurred. If RXWAKE is '1', the sleep mode processing should occur (set/keep sleep at '1' if address does not apply, set sleep to '0' if address does apply). If RXWAKE is '0' and you still get the interrupt, then you have theoretically already been through the sleep processing, and now you are getting interrupted on actual data. Data should be read and processed accordingly. When RXWAKE is '1' again going into your ISR, then an idle period or an address bit has been detected, and a new frame is beginning.

Best Regards,

Allison

Hi Allison,

Coding up interrupt architecture now. I'm using the FIFO interrupt mechanism.  For now, I'm working on getting an interrupt to fire. 

So far it is not.  I've confirmed bit stream is present at the SCI Rx pin (this has not changed and has always worked).

Q1: I see no reason why FIFO implementation will not work in this case?  Unless due to Rx sleep off in addr-mode. 

Q2: Does IER = M_INT1 assignment look correct?

Thank you as always,

-Tony

FIFO init:

ScibRegs.SCIFFRX.all = 0x2022;     //2 char intrpt lvl, intrpt enabled,  flag cleared, enable fifo

ScibRegs.SCIFFTX.all = 0xE022;     //fifo enable, oper enable, intrpt clr, intrpt enable 

InitPieVectTable();

EALLOW

PieVectTable.SCIB_RX_INT = &sci_rx_fifo_b_isr;

PieVectTable.SCIB_RX_INT = &sci_tx_fifo_b_isr;

EDIS;

PieCtrlRegs.PIEIER9.bit.INTx3 = 1;  // Enable SCIB_RX_ISR in the PIE: Group 9 intrpt 3

PieCtrlRegs.PIEIER9.bit.INTx4 = 1;  // Enable SCIB_TX_ISR in the PIE: Group 9 intrpt 4

IER = M_INT1;

Hi Allison,

Will you please confirm that FIFO interrupts will function when SCI is configured in "addr-mode".

I've used c2000 "Example_2837xDSci_FFDLB_int.c" as a basis for setting up my code and it is not working -no Rx intrpt.

The example SCI is configured in "idle-mode".  That is the only difference between my cfg and the example.

Since SCIB_RX_ISR is group9, I tried IER = M_INT9.  This did not work either.

Thank you in advance,

-Tony

Hi Tony, 

Apologies for the delay, I have not had the time to look much deeper into this. But since you are using address-bit mode, note that the RXRDY bit will not be updated unless the address byte is detected- as per the register description:

Given that RXRDY is set by the address byte detection, you should use interrupts without FIFO enhancements. SCI without FIFO has an RXINT triggered by the RXRDY flag: 

Best Regards,

Allison

Thank you Allison,

The first byte received has been confirmed to have the addr bit asserted in the frame.  So what I'm hearing you say is that I should not configure SCI w/FIFO implemented.  Is that correct? 

Hi Tony, 

Good that the byte is confirmed to have addr asserted. Yes, since the RXRDY flag is set when the address byte is recognized, you should either be polling that bit or using non-FIFO interrupts since the non-FIFO interrupt line is based on the RXRDY flag. The RX FIFO interrupts are dependent on a match between the RX FIFO interrupt Level (RXFFIL) and the RX FIFO status (RXFFST). Hope that helps clear it up!

Best Regards,

Allison

Thanks Allison for the quick reply.

I tried an experiment to test your theory.  All FF registers are no longer initialized/configured.  No interrupts at this time.

In the main forever loop I poll the RXRDY bit as follows:

if(ScibRegs.SCIRXST.bit.RXRDY != 0) {

ScibRegs.SCITXBUF.bit.TXDT = outBuffer[0] ;

} 

I send a two byte bit stream w/address bit asserted in first byte.  The if() statement is never executed -no data is sent.  Calling it day.

-Tony

Hi Tony,

Are you able to send a scope capture of the two bytes you are sending? And can you also send a snippet of the receive status registers after you try to send the two bytes:

• SCICCR
• SCICTL1
• SCIRXST
• SCIRXEMU

Side note: Are you watching the RXBUF register in the CCS window? Please be sure to read RXEMU and not RXBUF here: 

Best Regards,

Allison