cancel
Showing results for 
Search instead for 
Did you mean: 

Character match on STM32F303K8

dgiovanelli
Associate III

Hello,

I'm trying to set up the character match interrupt to detect the character '\n' (which indicates the end of a packet) and I don't manage to get the interruption.

The procedure I'm using is:

  1. initialize the uart, its gpios, and the dma.
  2. enable the uart as well as dma interrupt in NVIC
  3. disable uart
  4. write \n into CR2_ADD
  5. write to 1 CR1_CMIE
  6. enable uart
  7. HAL_UART_Receive_DMA
  8. in the USARTx_IRQHandler I check the ISR_CMF flag, and if it is not zero I call my routines to handle the input-

By doing this on UART1 I don't get any UART interrupt. I just see the dma TC interrupt when the buffer is full.

I also tried with HAL_UART_Receive_IT (i.e. without the DMA) with similar results.

Now I'm considering that I might misunderstood the specifications and maybe the stm32f303k8 doesn't support character match, or maybe some limitation applies to it. Is this the case?

The datasheet clearly states that Modbus communication is supported only on UART1 (which is the one I'm using), and the manual states that Modbus support includes timeout and CR/LF character recognition, therefore everything looks correct but I get no interruption with '\n'.

Any suggestion?

Thank you,

Davide.

1 ACCEPTED SOLUTION

Accepted Solutions
dgiovanelli
Associate III

OMG, I feel so stupid.

I just checked, and the terminal send the \r (and not \n)!! Now I changed the character to \r and the interruption works!

View solution in original post

7 REPLIES 7

Are you sure the mcu is receiving the character want to use as trigger? Can you confirm this by a polled receiver with the same settings?

Also read back check the content of USART registers.

JW

dgiovanelli
Associate III

So, before trying with the CM interrupt I used to manually check char-by-char on RXNE interrupt in order to detect the \n, it worked perfectly when I manually enter the data in a serial terminal (then the \n is there in the uart stream).

Now I need to use the CM interrupt because the data is transmitted in automatic fashion using a python script, therefore bytes are transmitted much faster (same baudrate but shorter inter character interval) and the mcu somehow miss the \n. I suppose it is because of overrun problem.

As I've said, read out and check/post the USART registers' content.

JW

dgiovanelli
Associate III

Oh yes, these are the values just before HAL_UART_Receive_DMA, CM interrupt should be enabled

USART1->CR1 = 0x0000400d

USART1->CR2 = 0x0a000000

USART1->CR3 = 0x00000000

USART1->BRR = 0x00000045

USART1->GTPR = 0x00000000

USART1->RTOR = 0x00000000

USART1->RQR = 0x00000000

USART1->ISR = 0x006000d0

USART1->ICR = 0x00000000

USART1->RDR = 0x00000000

USART1->TDR = 0x0000000a

After HAL_UART_Receive_DMA (when the interrupt is supposed to be fired) they are:

USART1->CR1 = 0x0000410d

USART1->CR2 = 0x0a000000

USART1->CR3 = 0x00000041

USART1->BRR = 0x00000045

USART1->GTPR = 0x00000000

USART1->RTOR = 0x00000000

USART1->RQR = 0x00000000

USART1->ISR = 0x006000d0

USART1->ICR = 0x00000000

USART1->RDR = 0x00000000

USART1->TDR = 0x0000000a

I hope the format is understandable, otherwise let me know if there is a better way to export it (I'm using arm gdb for debug).

Thank you,

Davide.

dgiovanelli
Associate III

OMG, I feel so stupid.

I just checked, and the terminal send the \r (and not \n)!! Now I changed the character to \r and the interruption works!

Thanks for coming back with the solution. Please select your post as "Best" so that the thread is marked as solved.

JW

PS. I personally confuse \r <CR> \n<LF> all the time too...

MStei.4
Associate III

Hello, one question to this regarding the commands:

  1. disable uart
  2. write \n into CR2_ADD
  3. write to 1 CR1_CMIE
  4. enable uart

Are there some HAL functions to control the registers. It is of course possible to set the register directly, but in terms of HW abstraction this is not the best solution. Or do I just overlook something?