Electrical – STM32F7: activate USART Receiver Timeout Interrupt (USART_RTOR.RTOF)

interruptsstm32f7uart

I want the STM32F769NI to generate an interrupt when a pause after a received byte on USART6 was detected.

I cofigured USART6 with 9600 baud in asynchronous mode and enabled the receiver interrupt RXNE and the global USART6 Interrupt. So far this is working, on USART6 interrupt I can read the correct byte from USART_RDR of USART6.

I found the RTO interrupt in the reference manual. It says, the RTOF flag is set if no start bit is set for the number of bit times given in USART.RTOR.RTO. And the USART interrupt is generated if the RTOIE flag is set. I want to get an interrupt 100 ms after the last byte was received, so I configured:

// Set RTOR.RTO = 960 (0,1s * 9600baud = 960):
MODIFY_REG(USART6->RTOR, USART_RTOR_RTO, 960);

// Reset RTOF flag:
WRITE_REG(USART6->ICR, USART_ICR_RTOCF);

// Set RTOIE (enable RTO interrupt):
SET_BIT(USARTx->CR1, USART_CR1_RTOIE);

But the USART6 Interrupt never gets executed with the RTOF flag set.

The USART6 interrupt vector is executed if a byte was received (with the RXNE flag set). I expect the same interrupt to be executed if the timeout happens after the reception of one byte (with the RTOF flag set), but this does not happen. I tried to set a LED on, set breakpoints in the debugger, but after sending one byte to USART6, the interrupt gets executed only once and only with the RXNE flag set. I also tried to set the RTO value in the interrupt handler after the reception of one byte but this changes nothing. I also tried to set RTO = 1, also without result.

Is there something I am missing to configure? Do I need to set RTOR.BLEN (Block Length) to some value? But this is only for SmartCard mode.

Best Answer

I simply missed the USART_CR2_RTOEN flag. Only the USART_CR1_RTOIE flag is mentioned in the manual as necessary for the USART_ISR_RTOF to trigger an interrupt but USART_CR2_RTOEN is necessary to first generate the USART_ISR_RTOF flag.

My initialization now looks like this:

// Set RTOR.RTO = 960 (0,1s * 9600baud = 960):
MODIFY_REG(USART6->RTOR, USART_RTOR_RTO, 960);

// Set CR2.RTOEN (enable Receiver Timeout):
SET_BIT(USARTx->CR2, USART_CR2_RTOEN); // <- this was missing

// Reset RTOF flag:
WRITE_REG(USART6->ICR, USART_ICR_RTOCF);

// Set RTOIE (enable RTO interrupt):
SET_BIT(USARTx->CR1, USART_CR1_RTOIE);

Note: For some strange reasons, the USART_ISR_RTOF receiver timeout flag is set directly after the reception of one byte without a timeout together with the USART_ISR_RXNE interrupt flag. So you need to reset the USART_ISR_RTOF flag at the reception of every byte to not get an interrupt pending directly after the RXNE interrupt. My USART6 interrupt routine now looks like this (with the usage of the ST low level drivers):

void USART6_IRQHandler(void)
{
  if (LL_USART_IsActiveFlag_RXNE(USART6)) // USART6.ISR.RXNE set => Byte received
  {
    // Byte in USART6 RX register

    // Reading USART_RDR register clears RXNE flag.
    // This reads the USART6.RDR[7:0] register and handles the data
    handleRXByte(LL_USART_ReceiveData8(USART6));
    LL_USART_ClearFlag_RTO(USART6); // for some reason this is already set
  }
  else if (LL_USART_IsActiveFlag_RTO(USART6)) // USART6.ISR.RTOF set
  {
    // RX inter-byte timeout

    // reset RTOF:
    LL_USART_ClearFlag_RTO(USART6);

    // handle timeout (reset receiver state):
    serialHandleRXTimeout();
  }
}

Related Solutions

Electronic – What can be the cause of an exceptionally large latency for the UART receive interrupt

I'm assuming that you're using the same debugging process I would do in this case -- one of the first instructions in the interrupt routine turns on a LED, and one of the last instructions in the interrupt routine turns that LED off.

Then you used a dual-trace oscilloscope with one probe clipped to the appropriate pin to watch the bytes going into the UART, and the other probe clipped to the pin driving the LED.

I'm assuming your UART-handler interrupt routine ends with the return-from-interrupt instruction (rather than using the return-from-subroutine instruction used by normal instructions).

There are 4 things that can cause a long latency between the end of the last byte of a message and the start of the UART handler:

Some previous byte in the message triggering the UART handler, and somehow it takes a long time before interrupts are re-enabled. Some people structure their interrupt routines so that after the UART handler finishes storing a byte in the appropriate buffer, it checks a bunch of other stuff before executing the return-from-interrupt instruction -- it increases jitter and latency, but sometimes those people do it anyway because it improves throughput.
Some other interrupt taking a long time to execute before it re-enables the interrupts by executing the return-from-interrupt instruction. (If you can make each and every interrupt turn on and off some other LED, it's pretty easy to see on the o'scope if this is the problem or to rule this out).
Some non-interrupt code "temporarily" turning off interrupts. (This increases jitter and latency, but people do it anyway, because it's often the easiest way to prevent data corruption when both some interrupt and some main-loop background task both work with the same piece of data). (If you can make every bit of code that does this turn on and off some other LED, it's pretty easy to see on the o'scope if this is the problem or to rule this out).
Instructions that take a long time to execute.

The traditional way to figure out exactly what is causing the problem is to save the current version of your code (you're using TortoiseHg or some other version control system, right?), and then deliberately hack and slash at a temporary copy of your code, stubbing out and completely removing code a few subroutines at a time, re-testing after each round of deletions, until you have a tiny -- yet technically "complete" and runnable -- program that exhibits the same problem.

Far too often people show us bits and pieces of a complete program -- the parts those people think are relevant -- and we can't help them because one of the pieces they omitted is causing the problem.

The process of reducing a program to a small test case is a very useful skill, because often while going through that process, you quickly discover what the real problem is.

Once you have such a tiny -- yet runnable -- program, please post it here. If you figure out what the problem is during that process, please tell us that as well, so the rest of us can avoid that problem.

Electronic – PIC18 USART Interrupt for reception, doesn’t trigger

Every processor has its own special interrupt-handling quirks.

Microchip's PIC18F4331 page has links to an errata document and the PIC18F4331 datasheet. In particular, the datasheet has some good tips in section 20 "Enhanced universal synchronous asynchronous receiver transmitter (EUSART)" and even more particularly, the 3 steps listed in section 20.0 and the 10 steps of "To set up an Asynchronous Reception" in section 20.3.2.

I've changed a few things that look like they might help:

// WARNING: untested code
int main(void){

//***********************Initializing Values****************************//
unsigned int ResultADC, FLAG; 
unsigned char temp, idle; //High Byte result store, 8bits long

//***********************ADC and SPI Settings****************************//

Initialize_control();    //Initialize Control Configuration Pins
InitializeADC();         //Initialize ADC in Continuous Mode
USART_initialize();      //Initialize USART module
InitializeMasterSPI();   //Initialize SPI module

//***********************ADC Capture and Output to SPI******************//

  while(1){             //While ADC buffer has something

    //Enable transmission
     TXREG = 0xff; //Debugger

     while(!TXSTAbits.TRMT);//wait while TSR is full

     TXREG = 0x0; //Debugger

     while(!TXSTAbits.TRMT);//wait while TSR is full

  }
  return 0;
}

//////////////////INTERRUPT SERVICE ROUTINE/////////////////

static void interrupt isr(void){
    // The PIC hardware has already disabled global interrupts
    // by the time it starts executing the ISR,
    // so there's no need to do "PIE1bits.RCIE  = 0;".

int count;

//Read USART data
//PIR1bits.RCIF;//Data has been passed to RCREG
RX_Data[count] = RCREG; //Read RX register
count++;
//Reading RCREG automatically clears the RX flag.
// so there's no need to do "PIR1bits.RCIF = 0;".
// Q: How to read more than 1 byte?
// A: FIGURE 20-5 of the datasheet
// Implies that there's only a 1 byte buffer.
// Therefore, to read more than 1 byte, we must:
// pull the current byte out of the hardware buffer,
// store it in a software buffer RX_Data[] in RAM,
// then return to normal background main loop
// until the next byte in the message
// triggers another interrupt.

// Would it be better to do the following in the main loop?
  if (count==3){
    //Use data for control
    Control_Arduino(RX_Data);
    count = 0;
  }

/*
The datasheet p. 229 is a little confusing about
whether "CREN" should be set (step 5) or cleared (step 9).
p. 219 which clearly seems to say CREN should be set.
But maybe it needs to be cleared to flush out any errors,
and then be set?
Are the following 2 lines really necessary?
*/
RCSTAbits.CREN = 0; //clear error (if any)
RCSTAbits.CREN = 1; //Enables Receiver

// the PIC hardware enables global interrupts
// automatically during the return-from-interrupt,
// so there's no need to do a "PIE1bits.RCIE  = 1;"
// See the datasheet section 10.0: "Interrupts" for details.

}

//**********************Functions****************************//

void USART_initialize(void){

//Configuration TX and RX pins
// *normally* we use a "0" to indicate "output",
// but the TX output pin is different, see p. 217 of datasheet
TRISCbits.RC6 = 1; //TX output
TRISCbits.RC7 = 1; //RX input

//TXSTA: Transmit Status and Control Register
TXSTAbits.SYNC = 0; //Asynchronous mode
TXSTAbits.TX9 = 0; //8bit transmission
TXSTAbits.BRGH = 1; //Set HIGH Baud rate
TXSTAbits.TXEN = 1; //Enable transmitter
TXSTAbits.SENDB = 0; //Disable break

//RCSTA: Receive Status and Control Register
RCSTAbits.SPEN = 1; //Serial Port enabled
RCSTAbits.RX9 = 0; //8bit reception
RCSTAbits.CREN = 1; //Enables Receiver

//Test bits
//    RCSTAbits.FERR = 0; //No framing error, cleared by reading
//    RCSTAbits.OERR = 0; //No Overrun error, cleared by clearing CREN
                      //Disable receiver CREN 0

//BAUDCON Control register
BAUDCONbits.BRG16 = 1;  //16bit baud rate generator
SPBRG = 0xCF;           // Set to 19200 baud rate, 12Mhz, High Speed, BRG16
//Test bits
//    BAUDCONbits.RCIDL = 0; //Receive in progress

// USART interrupts configuration
RCONbits.IPEN   = 1; // ENABLE interrupt priority
// (p. 4 of http://www.gooligum.com.au/tutorials/midrange/PIC_Mid_C_3.pdf )
ei(); // same as INTCONbits.GIE  = 1; // ENABLE interrupts
INTCONbits.PEIE = 1; // ENable peripheral interrupts.
PIE1bits.RCIE   = 1; // ENABLE USART receive interrupt
PIE1bits.TXIE   = 0; // disable USART TX interrupt

// make sure the RX flag is clear
    PIR1bits.RCIF = 0;
}

Other code online:

"AN944: Using the EUSART on the PIC16F688" http://www.gooligum.com.au/tutorials/midrange/PIC_Mid_C_3.pdf https://forum.sparkfun.com/viewtopic.php?t=7542 http://panteltje.com/panteltje/pic/scope_pic/ http://www.microchip.com/forums/m411875.aspx http://www.enmcu.com/guides/autobaudratebasedoneusartmodule

Tell us if you ever figure out the real problem, OK?

Best Answer

Related Solutions

Electronic – What can be the cause of an exceptionally large latency for the UART receive interrupt

Electronic – PIC18 USART Interrupt for reception, doesn’t trigger

Related Topic