cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F407: Strange Idle/RXNE on UART4-5 (not on USART1-3/6)

flyer31
Senior
Posted on November 20, 2014 at 12:30

Hi,

I found a very strange behaviour for the UARTs:

The IDLE Flag of UART4-5 will ''extinguish'' after typically 100-500msec (Baudrate 100kB and 9600).

I tried with 2 Discovery boards and with all UARTs. The ''synchronized'' USARTS 1, 2, 3, 6 work well, just the ''unsynchronized'' UART4-5 show this behaviour. For these 2 UARTS I also see a problem with the RXNE, sometimes it does not seem to come (every 100'th byte, but no regular interval).

The VERY odd thing with this IDLE flag ''extinguish'' problem: It happens only if I am in Debug mode - not if I start the Discovery without Debugger. This is really very bizarre. Anyone has an idea what is going on here? (When I search the forum for ''UART4 problem'' I recognize that some people already reported unresolved RXNE problems for UART4...).

This is the source code, you can easily try yourself, if you program another discovery to send you some bytes. I tried it with Baudrate 100k and 9600 and with or without OVER8 oversampling. It is always after 100-500msec that the IDLE Flag somehow ''disappears'' by itself - but only if the Discovery is running in Debug mode (in the following code then, after receive of a Byte the green LED will switch off after 100-500msec in Debug mode, whereas it keeps on indefinitely when I run it without Debugger (as it should ...)) (I use uVision 4.7 with ST-Link Debugger):

int main(void) {

 

  #define LED_GREEN 0x1000

  #define AF_UART1 7

  #define AF_UART2 7

  #define AF_UART3 7

  #define AF_UART4 8

  #define AF_UART5 8

  #define AF_UART6 8

 

  //PD12_GREEN LED PIN

    RCC->AHB1ENR|= RCC_AHB1ENR_GPIODEN;

    GPIOD->MODER|= GPIO_MODER_MODER12_0;

 

  //UART5_Rx pin PD_2

  RCC->APB1ENR|= RCC_APB1Periph_UART5;

  GPIOD->MODER|= GPIO_MODER_MODER2_1; //Alternate Function (AF)

  GPIOD->OSPEEDR|= GPIO_OSPEEDER_OSPEEDR2_0; //25_Mhz

  GPIOD->AFR[0]|= (0x00000100 * AF_UART5); //AF_8

 

 

  //UART5_Tx pin PC_12

  RCC->AHB1ENR|= RCC_AHB1ENR_GPIOCEN;

  GPIOC->MODER|= GPIO_MODER_MODER12_1 ; //Alternate Function (AF)

  GPIOC->OSPEEDR|=GPIO_OSPEEDER_OSPEEDR12_0; //25_Mhz

  GPIOC->AFR[1]|= (0x00010000 * AF_UART5); //AF_8

  //UART5

  UART5->BRR= (USART_BRR_DIV_Mantissa&(546<<4) ) | (USART_BRR_DIV_Fraction&7); //Baud Rate 9600

//  UART5->BRR= (USART_BRR_DIV_Mantissa&(52<<4) ) | (USART_BRR_DIV_Fraction&4); //Baud Rate 100kb

  UART5->CR1=USART_CR1_M|USART_CR1_RE|USART_CR1_TE | USART_CR1_OVER8;

    UART5->CR1|=USART_CR1_UE;

 

    while(1){

    if(UART5->SR&  USART_SR_IDLE){

      GPIOD->ODR ^= LED_GREEN;

    }   

    else{

      if(GPIOD->ODR & LED_GREEN)

        GPIOD->ODR&=~LED_GREEN;

    }

  }

}

3 REPLIES 3
flyer31
Senior
Posted on November 20, 2014 at 12:48

As this problem seems to be somehow linked to the Debug interface, I just tried one further thing:

I switched of the Debugger setting ''View'' - ''Periodic window updates''.

In this case also the IDLE flag keeps on - it does NOT have this ''extinguish problem''.

So the problem seems to be linked to the ''Periodic window update'' of the Debugger. But how can this be? To my info ARM and STM are very proud that their Debug readout runs at full processor speed without any processor interaction, how can it have the influence that a peripheral flag is changing due to such Debug interaction?

Or is there some not so reliable behaviour on APB1 (UART4 and 5 are on ABP1, but USART 2 and 3 too, USART 1 and 6 are on ABP2)????????

flyer31
Senior
Posted on November 20, 2014 at 15:11

One further remark: The window ''UART5 system viewer'' was open, when this happens.

Just two things anyway are strange:

- why only with UART4-5 (not with the USARTS 1-3/6)?

- the system viewer window in ''Periodic window update'' mode quite sure will get its data not by register access to DR register, but by ''debug memory readout'' of the UART registers - how can this interfere with the state of the IDLE or RXNE bit?

... so then it would be interesting to know from an STM expert, on which peripheral something similar might happen, and which perpherals definitely are safe concerning this debug readout.

flyer31
Senior
Posted on November 20, 2014 at 16:21

One hopefully last remark:

The difference between UART4-5 and USART1-3/6 now also has sort of clarified - we had only the system viewer window of UART 4 and UART5 open, when we tested it.

If we do the test with USART1 and open the system viewer window of USART1 with ''Periodic Window Update'' active, then the same happens also with USART1 ...

So just be careful with the system viewer windows for such ''variables with read implication'' as the UART / USART DR register ... .