2023-05-04 07:10 AM
As per the title: I am using Timer 2 for a PWM. Channel 1 and 2 work just fine, but Channel 3 and 4 won't output anything. Created the project with CubeMX. Tried enabling all 4 channels with all the same values except pulse (CCR) and probed the output-pins. The only user code is enabling the PWM with HAL_TIM_PWM_Stop(&htim2, TIM_CHANNEL_1), ..._2), ..._3) and ..._4).
In the created code the Config-Struct is created, Channel 1 is initialized, only the pulse variable is changed, Channel 2 is initialized, etc.
The only difference between Channel 1 and 2 and Channel 3 and 4 I found is the CCMR1 / CCRM2 register.
Has anyone an idea where this error might stem from?
Solved! Go to Solution.
2024-08-12 06:11 AM
yes rxe is same as the usart_sr_rxne i just forgot to format while asking .
also i am using usart1 now
the problem i am facing if i am putting a delay of 10 ms before sending in arduino i am recieving correct data everytime but when i put not delay in transmission then whenever i reset the stm the data value changes in a particluar pattern then again keep on resseting fetches me the correct value i am sending from arduino.
also when i am trying to send from the serial monitor i obsered then whenerver a new number i send the idle line flag sets and resets on its own what does it indicate .
and also can you please elaborate this more to me
"Also, if you observe the USART registers (namely USART_DR) in the debugger, it will clear the USART_SR.RXNE flag in the same way as if you read it from processor, so don't observe the USART registers in debugger during debugging."
2024-08-12 07:26 AM
> when i put not delay in transmission then whenever i reset the stm the data value changes in a particluar pattern then again keep on resseting fetches me the correct value i am sending from arduino.
I don't quite understand what do you mean by this.
If you transmit a continuous stream of bytes towards the STM32 and you reset the STM32, it may start to receive in the middle of a byte, resulting in confused data. If this is a possibility in reality, your program has to cope with that, e.g. by putting data into frames, adding checksums, etc.
> whenever a new number i send the idle line flag sets and resets on its own what does it indicate
UART_SR.IDLE indicates, that there was some data transmitted and then there was at least one byte's of "idleness" (no transmission) on the line. As its description in RM says: It is cleared by a software sequence (a read to the USART_SR register followed by a read to the USART_DR register).
> and also can you please elaborate this more to me
> > "Also, if you observe the USART registers (namely USART_DR) in the debugger, it will clear the USART_SR.RXNE flag in the same way as if you read it from processor, so don't observe the USART registers in debugger during debugging."
Debugger (the on-chip hardware which talks to the debugging program in PC) is part of the processor. The peripheral can't distinguish accesses from the debugger and from the processor (i.e. from the program). The UART_SR.RXNE bit is cleared, when UART_DR is read, and it does not matter, if the read was from the debugger or from the program.
JW
2024-08-12 10:25 AM - edited 2024-08-12 10:26 AM
Thank you so much for this explaination.
but can you show me like the best way to recieve data as i want to recieve a continous data frame from esp to stm32 without much error , so can u provide me a code snippet which i can refer to create my own recieve function for the usart1 reception of that type of data. on stm32f401re.
2024-08-12 10:29 AM
I'm not writing code on request.
JW
2024-08-12 10:33 AM
i dont want whole code just want a better approach or something to solve this problem,
like jusr directly storing the dr register contents in a variable and observing it is not the correct way to receive Ig.