cancel
Showing results for 
Search instead for 
Did you mean: 

Changed parity flag after calling HAL_TIM_PWM_Start_IT()

JPiet.3
Associate II

Hello,

I found a strange behaviour now in my code. When I initialize my UART3, I can communicate with my terminal as expected. During runtime, I call the function HAL_TIM_PWM_Start_IT() to start timer 1. After this call, the received characters are not same as before. When I step through the code, I found within the HAL_TIM_PWM_Start_IT() function the call to enable the timer (line 1623), which causes this change of my parity settings.

This is my function call.

printf("\033[2;1H ==>> Correct output");
if(HAL_OK != HAL_TIM_PWM_Start_IT(&htim1, TIM_CHANNEL_1))
		  Error_Handler();
printf("\033[3;1H ==>> What happend now?");

0693W00000Y97c6QAB.pngWhen I start debugging, it ends here in stm32h7xx_hal_tim.c (lines are added by me, just for this box).

1620      tmpsmcr = htim->Instance->SMCR & TIM_SMCR_SMS;
1621      if (!IS_TIM_SLAVEMODE_TRIGGER_ENABLED(tmpsmcr))
1622      {
1623        __HAL_TIM_ENABLE(htim);
1624      }

Register from UART3 before

0693W00000Y97VQQAZ.jpgand after the function call.

0693W00000Y97ZSQAZ.jpg 

Here are my settings for the UART

huart3.Instance = USART3;
  huart3.Init.BaudRate = 115200;
  huart3.Init.WordLength = UART_WORDLENGTH_8B;
  huart3.Init.StopBits = UART_STOPBITS_1;
  huart3.Init.Parity = UART_PARITY_NONE;
  huart3.Init.Mode = UART_MODE_TX_RX;
  huart3.Init.HwFlowCtl = UART_HWCONTROL_NONE;
  huart3.Init.OverSampling = UART_OVERSAMPLING_16;
  huart3.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
  huart3.Init.ClockPrescaler = UART_PRESCALER_DIV1;
  huart3.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;

It would be great, if someone has a good idea, what happen. Unfortunately, I cannot go deeper in the code, it ends with the call of __HAL_TIM_ENABLE().

Thanks,

Jan

6 REPLIES 6
gbm
Lead III

First, printf doesn't start the transfer until it encounters newline, so you first printf doesn't start UART transfer. What hapens if you remove the timer call from between printfs? How is your stdout redirection implemented?

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice
JPiet.3
Associate II

When I comment out my TIM_START like this

  	 printf("\033[2;1H ==>> Correct output\n\r");
 //	if(HAL_OK != HAL_TIM_PWM_Start_IT(&htim1, TIM_CHANNEL_1))
 //		 Error_Handler();
 	 printf("\033[3;1H ==>> What happend now?\n\r");
 

I get this

0693W00000Y98JtQAJ.png 

gbm
Lead III

That's even stranger. you call printf("\033[2;1H ==>> Correct output\n\r");

and it prints quite a different message "Correct output is used". "\n\r" is not the correct EOLN sequence - use \r\n instead. Introduce changes step by step, try wit and without timer call, show the real output from real code, finally show your printf output redirection - an error might be there.

Do you call printf from main function, from interrupt service (bad practice if the redirection is not interrupt-driven), or from both (that would be a serious error)?

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice
JPiet.3
Associate II

I think, the sequence is not related to this issue because the ASCII sequence at start is assigning the cursor position. The linefeed was just added for a better presentation. Without, it looks like this (with the TIM_START_IT function.

0693W00000Y98neQAB.png

JPiet.3
Associate II

As you can see in the register settings, the bit UEN in register USART_CR1 is set to one. In the datesheet (pg. 2251 from RM0399), it is written "This bitfield can only be written when the USART is disabled (UE=0)." I wonder why changing of these bits is possible?

JPiet.3
Associate II

It is really strange, it looks, it is a little bit time delayed, when the change is happend. When I readout the settings, the original value is still in. But the debugger is showing the changed register.

I change my communication protocol and continue with the paritiy settings in my configuration.

0693W00000Y9KiRQAV.png