LAUNCHXL-F28379D: How to trigger Tx Interrupt

Allison,

I changed the FIFO interrupt level for my RX FIFO to 1, but when I fetch the value for RXFFST reg I always get 0, even though there is some value (2) being shown in Register debug window (see the screenshot attached). What I am trying to do is capture the bytes using ScibRegs.SCIRXBUF.all because I don't know how long is the coming data (receive data), its strange if I use SCI_readCharArray() I am able to capture the data but for this to work I need to know the size of coming data before hand. 

Could you explain why the ScibRegs.SCIFFRX.bit.RXFFST is returning 0.

Thanks,

Hi Sumit,

You can see from the register description that the RXFFIL bits will determine when the interrupt occurs. In this case, you are setting the interrupt level to 1, meaning an interrupt will trigger when the RXFIFO level (RXFFST) is at least 1 (or greater than 1). So it is not surprising to see the value 2 in the registers window.

Sumit B said:

I don't know how long is the coming data (receive data)

By this, do you mean that you don't know the bit-length of each data? Or you don't know how many bytes you are receiving?

Also, if you try reading the entire SCIFFRX 16-bit register instead of just the status, do you see the other register bits saved correctly into that variable properly?

Best Regards,

Allison

Allison Nguyen said:

By this, do you mean that you don't know the bit-length of each data? Or you don't know how many bytes you are receiving?

 - I am talking about how many bytes I am receiving.

Allison Nguyen said:

Also, if you try reading the entire SCIFFRX 16-bit register instead of just the status, do you see the other register bits saved correctly into that variable properly?

 - Yes, other register bit save correctly (see below)

Also for SCIB, I have to verify this. Is using SCIB_BASE in initscibfifo() essentially the same as using ScibRegs? What I mean is when using SCIB_BASE in init function, is it setting up ScibRegs's registers and I can use ScibRegs later in the code or do I have to point ScibRegs to SCIB_BASE , if yes, how can I do that?

Update: I was able to receive the data now using Rx FIFO Interrupt, Now I need help in how can I trigger the Tx FIFO Interrupt. See below the interrupt level setting in scibinit() function

Please Note: 

1. As you can see I am only enabling the SCI_INT_RXFF in SCI_enableInterrupt(), is this a right thing to do when you don't want tx interrupt to be trigger all the time?, because by not enabling the SCI_INT_TXFF it was not firing the tx interrupt continuously. ( I had both (TX and RX) before but then Tx interrupt was continuously firing).

2. Reason of it was continuously firing was the fifo interrupt level. I am not sure if I want this to be triggering all the time or not, but the condition of tx interrupt to be triggered is when TXFFST <= TXFFIL. and TXFFST is zero in the beginning and fifo level is 1 means tx interrupt is always triggering.

3. Now What I want is, how can I trigger the interrupt from the point shown in the screenshot. (this is important)

4. Also see below the Tx ISR

I am disabling the interrupt again in this function, is this a right thing to do? Is this line executes after every byte being transmit or after the entire array being transmitted? 

Hi Sumit,

Glad you were able to get RX working. 

When using the FIFO enhancements the interrupt that you are receiving can be thought of "the SCI is requesting more messages to be put in it's FIFO". This interrupt occurs anytime TXFFST<= TXFFIL. For example, you can clear the interrupt with SCIFFTX.TXFFINTCLR = 1, but it will be immediately reset if TXFFST is still less than or equal to TXFFIL. 

I know in your original post you mentioned you want to control TX and you were asking about stopping communication - are you disabling TXFF interrupt within the ISR to prevent future interrupts? Typically, you would not disable it if you want to continue to get TX ISRs (continue to transmit data)- you would just clear the interrupt flag and clear ACK in the PIE for that interrupt group.  

If you are preventing future interrupts, you can disable one of the "enable" bits along the interrupt flow to stop future interrupts. This can be within the SCI, within the PIE, or within the CPU: 

Do you only want one TX interrupt to occur?

Best Regards,

Allison

I m clearing the interrupt and ACK to the PIE group.

My question is still the same, How can I trigger this ISR from the code. I don't want it to be continuously firing. I want it to be triggered whenever I want. 

If you look the post from the past, someone has asked the same question and the response was to enable the trigger and then disable it.

but how to do it? I have tried this API: 

SCI_enableInterrupt(SCIB_BASE, SCI_INT_TXFF);

It takes me to the tx ISR but I dont see my transmitted data on the receiving end (not even sure if the ISR sending something or not)

Hi Sumit,

You also don't have to use interrupts if you don't want to - you can just write to SCITXBUF whenever you would like to transmit data by simply checking the TXFIFO level to make sure there is space and then transmitting data.

The enabling/disabling interrupts should also work as well as suggested in the past post.

Sumit B said:

It takes me to the tx ISR but I dont see my transmitted data on the receiving end (not even sure if the ISR sending something or not)

Have you already scope the TX pin (or RX on the other end) to see if data is being sent out properly? Are you stepping through (into the functions) the code to follow the program and be sure it is transmitting?

Best Regards,

Allison

Allison,

After further debugging, I noticed that there is little bit of transmission happening at the same time of receiving (that should not happening as I am using half-duplex RS485 interface), it just just be receiving when enable pin is low and only transmission when enable pin is high.

To be it seems tx interrupt happens (or at least it tries to) as soon as I receive something (rx interrupt). please see below my scope and fifo interrupt level screenshot.

and this is something I am using to trigger the tx interrupt

What is incorrect here?

thanks,

Hi Sumit,

If you set a breakpoint in your TX interrupt (or step through the code), do you see the program actually jump to the TX ISR? Is this happening as soon as you enable TX interrupts or long after they are enabled?

Is this behavior occurring every time you receive data? If you want, you can toggle a GPIO at the start and very end of your ISRs so that you can (1) see if the ISRs are happening at all and (2) view the timing of the ISRs. This is also helpful for debugging purposes.

Best Regards,

Allison

Tx Interrupt is being triggered twice for some reason. What causing it to be triggered twice?

Hi Sumit,

Forgive my misunderstanding, but are you toggling GPIOs in the ISRs (guessing it's the white channel)? I assume the orange signal is the TX line and so you are saying you see two transmissions occur which should not occur if you are disabling interrupts at the end of the first TX ISR, right?

If you step through your code and monitor the flags for SCI TX interrupts, do you see it get set when you step through the first ISR? And then can you check the registers to confirm that the interrupts are getting disabled after stepping over the disableInterrupt function?

Best Regards,

Allison

Allison,

I have solved my transmission happening twice issue, turned out it was the delay function inside the tx interrupt. Now I have a question regarding the SCI_readCharArray() function. In order to use this function I need to know the number of bytes (size) before hand right? but there will be incoming data (frames) whose length is not known, how do I go about that? Is there any other function or different approach where I can read until the entire msg has been read? (Note: I am reading Modbus rtu frame running on RS485).

Thanks,

Hi Sumit,

Glad you were able to resolve triggering twice!

If you have no idea the amount of data, there are two paths you can try:

1. If you don't care about number of interrupts that occur, you can use the single char read function and just have an RX interrupt ISR to read each character until no more data is received. 

2. If you do care about number of interrupts and want to maximize FIFO depth, you can increase your RXFFIL to 16 (wait to trigger interrupt until FIFO is full of 16 levels of data), and increase your read char array length to be 16. When there are no more interrupts, you'd have to check the FIFO for remaining data if there's less than 16 levels of data there. Or you can try to implement some sort of time-out, but that would likely require more effort.

Best Regards,

Allison

Allison,

I am trying the first approach (reading single char) but I have question regarding below two APIs, what is the difference between these two and when should I use each? 

1. This is the 1st api. It says "If there are no characters available, this function waits until a character is received before returning." I mean how long it will wait? what about about if there is not going to be any char coming?

I am using this api like this (see below) is this a right way to do it?

2. This is the 2nd api

Thanks

Hi Sumit,

Allison is currently out of office. Please expect her response to be delayed by a day or two. I apologize for any inconvenience.

Best Regards,

Delaney

Hi Sumit,

Thanks for the patience.

You can view the details of the functions by looking at them in the sci.h DriverLib file from {C2000Ware}\driverlib\f2837xd\driverlib:

So it will wait in the "while" loop while the specified condition (seen above) is met. If you don't want it to wait so long, you can try to modify it or implement a sort of time out.

To see examples of where the first API is used, you can refer to the C2000Ware example: {C2000Ware}\driverlib\f2837xd\examples\cpu1\sci\sci_ex3_echoback.c

Best Regards,

Allison