STM32F0 Discovery Receive Interrupt is not working

[MLoy.1]

Hi all​,

I tried the same setup for USART on PA10 and PA9 as the following example Project.

en.stm32f0_stdperiph_lib\STM32F0xx_StdPeriph_Lib_V1.5.0\Projects\STM32F0xx_StdPeriph_Examples\USART\USART_HyperTerminalInterrupt

I can send data to my Laptop via an FDTI 232R 3.3V cable. However I can not receive data via the cable. The FTDI cable is connected correctly.

I did also try the Setup from

en.stm32f0_stdperiph_lib\STM32F0xx_StdPeriph_Lib_V1.5.0\Projects\STM32F0xx_StdPeriph_Examples\USART\USART_8xUsartsOneBoard

for PA 9 and PA10 with the same result.

Can you please let me know what I need to do to bring the receive Interrupt to live ?

Thanks for you help in advance.

BR,

Melanie

[Ozone]

You didn't mention which F0 discovery board you are using, there are several different ones, with different MCUs.

The cited example might be originally for a different board, resulting in different clock setup.

Check the schematics, if those pins (PA9, PA10) are usable for UART, or clogged with other external components.

If you have a scope, check the signals at the PA9/10 port pins.

Finally, are the line settings (baudrate, bits, start/stop, parity) identical ?

[MLoy.1]

​Hi Ozone,

thanks for your reply. I am sorry that I did not make it clear enough that I have the STM32f0 discovery board with an STM32F051R8T6 on it.

The link Shows you the board https://www.conrad.de/de/p/entwicklungsboard-stmicroelectronics-stm32f0discovery-443923.html.

Both the Manual en.DM00050135.pdf and the data sheet for the MCU make it clear that PA10 and PA9 can be used as USART 1.

In the schemtic MB1304.pdf I could not see that PA10 is connected to something else.

I double checked that I have connected Rx of the cable to Tx of the microcontroller and Tx of the cable to Rx of the microcontroller.

I double checked also that I have 9600 baud rate , 8 data bits , 1 stop bit , no parity and no handshaking setup in my terminal program and the discovery board.

I also measured with the oscilloscope already on pin PA10 and I see the data package there.

I also tried it the way I saw in some other examples online where they set up PA10 as floating Input instead of Output push pull like it's done in the examples from the library. Did also not help to solve my issue.  And a third thing I tried was to use the Code snipets in the Appendix off the reference manual en.DM00031936.pdf.

So this leaves to check the clock setup. Do you have any other ideas now that you have the info which board I have ?

Thanks for your  help in advance.

BR,

Melanie

[berendi]

If the transmitted packet looks right on the scope (can you post a screenshot?) then there's nothing to improve on the STM32 side.

Disconnect the serial adapter from the board, and connect its Rx and Tx pins together. Can you see the echo of what you are typing in the terminal?

[Ozone]

Clock settings was a common beginner's problem with the SPL. Most examples were written for the more expensive Eval-boards, which had a different quartz then the cheaper discovery boards (often 25MHz instead of 8MHz). At some point, ST dropped the quartz alltogether, and fed the MCO output of the ST-Link MCU to the target clock input.

I think the F051 discovery was the first one, i.e. it receives an 8MHz clock from the ST-Link F103 MCU.

> I also measured with the oscilloscope already on pin PA10 and I see the data package there.

For a given setting (baudrate,start/stop/parity), the length of one transmission is determined, so you can check scope measurement against your expectations.

Check SB14 and SB15, which would connect PA9 and PA10 to the ST-Link MCU for VCP functionality. Both jumpers are not fitted by default (i.e. no VCP connection by default). However, adding this jumpers and trying VCP would be another option.

I used the following UART init code for one of my F051 based projects:

/* Initialize the USART1 (115200,8,n,1,none)
 * PA9  => TX_1
 * PA10 => RX_1
 */
void  initUART (void)
{
    GPIO_InitTypeDef  GPIO_InitStructure;
    USART_InitTypeDef USART_InitStructure;
    NVIC_InitTypeDef  NVIC_InitStructure;
 
    RCC_AHBPeriphClockCmd  (RCC_AHBPeriph_GPIOA , ENABLE);   /* Enable GPIOA and DMA clock */
    RCC_APB2PeriphClockCmd (RCC_APB2Periph_USART1, ENABLE);  /* Enable USART1 APB clock */
    GPIO_DeInit (GPIOA);
 
    /* Connect pin to Periph */
    GPIO_PinAFConfig (GPIOA, GPIO_PinSource9, GPIO_AF_1);
    GPIO_PinAFConfig (GPIOA, GPIO_PinSource10, GPIO_AF_1);
 
    /* Configure pins PA9(TX) and PA10(RX) as AF pushpull */
    GPIO_InitStructure.GPIO_Pin   = GPIO_Pin_9 | GPIO_Pin_10;
    GPIO_InitStructure.GPIO_Mode  = GPIO_Mode_AF;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
    GPIO_InitStructure.GPIO_PuPd  = GPIO_PuPd_NOPULL;
    GPIO_Init (GPIOA, &GPIO_InitStructure);
 
    USART_DeInit(USART1);
    USART_InitStructure.USART_BaudRate            = 115200;
    USART_InitStructure.USART_WordLength          = USART_WordLength_8b;
    USART_InitStructure.USART_StopBits            = USART_StopBits_1;
    USART_InitStructure.USART_Parity              = USART_Parity_No;
    USART_InitStructure.USART_Mode                = USART_Mode_Tx | USART_Mode_Rx;
    USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
    USART_Init (USART1, &USART_InitStructure);
    USART_Cmd (USART1, ENABLE);
 
    /* parametrize USART1-Interrupt */
    NVIC_InitStructure.NVIC_IRQChannel         = USART1_IRQn;
    NVIC_InitStructure.NVIC_IRQChannelPriority = 0;
    NVIC_InitStructure.NVIC_IRQChannelCmd      = ENABLE;
    NVIC_Init (&NVIC_InitStructure);
 
    /* Interrupt at reception and receive errors */
    USART_ITConfig (USART1, USART_IT_RXNE, ENABLE);
    USART_ITConfig (USART1, USART_IT_ERR, ENABLE);
}

Interrupts would be handled in void USART1_IRQHandler(void).

The handler name might differ between toolchains, though.

Check your startup code (assembler), which usually contains the vector table, and the expected handler names.

[Tesla DeLorean]

Check and clear any flagging error status like framing or noise​

[MLoy.1]

Hi Ozone, berendi and clive1,

I am sorry for my late reply.

I checked with the scope that data package see attachment. The value on the scope is 0x14 which is what I send.

Also when I bridged Tx and Rx on the FDTI cable. The reply was as it was supposed to be. Timing measured with the oscilloscope cursors was 100 microseconds per bit. I calculated 104 micro seconds for one bit for a baud rate of 9600.

I found out after the hind from Ozone that the Hyperterminal was tested on the STM320518-EVAL as well as the other example project for USART I mentioned yesterday.This EVAL board has exactly the same MCU as my STM32F0 discovery. I program and debug via the USB cable at the moment.

I used the USART setup from Ozone's last answer. Only thing different is the 9600 baud instead of 115200 baud.

Did also not help so far. I need to check SB14 and SB15. And I also still need to double check the on the flags.

This I'll do tomorrow.

Ozone can you show me what you do after you finished the USART initialization please and also your ISR ?

What I want to do is receive bytes. And do some action after I have decoded my bytes. After decoding I want to send an reply. That's why I did not implement the code part for the TX receive in my code like it's done in the Hyperterminal example main.c file.

By the way I use 4 pins as PWM outputs and 8 other pins as digital outputs. The PWM pins are PA8, PA6, PA7 and PA2.

Outputs on Port A I use PA15, PA12 and PA11. I also have the systick ISR to get a milliseconds counter for later on.

I init the timer pins, the outputs and the USART pins on Port A with separate GPIO_InitStructures. The GPIO Speed is the same for all those pins 50 MHz.

So I also can check tomorrow what happens if I only use the UART just to see if it makes a difference.

I'll let you know what I further find out tomorrow. Does anyone from you have still other ideas where the issue could be ?

Thank for your further help in advance.

BR,

Melanie