cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F303RE Comparator to Timer Channel Internal Mux Bug report with Workaround

charliepuch
Associate

Hello I recently solved an issue I was having with my STM32F303RE chip when using the internal comparators and attempting to connect them to the timers internally.

 

Here is a description of the issue:

 

1. Configure COMP6 Output Internal Selection to: Timer 4 Input Capture 4.

2. Configure Timer4 Channel 4 to Input Capture Direct Mode - Doing this automatically enables pin PB9 in CubeMx even though the timer should be wired internally. (important later)

3. Running testing with COMP6 toggling Timer 4 CH4 was never getting a trigger. If I temporarily enable the Comparator output Pin PC6 and wire externally to the Timer4 CH4 Pin PB9, then everything starts working as expected (except for the fact that I have to wire this externally).

4. Suspected a potential conflict between the GPIO Pin PB9 for Timer4 Ch4 and the internal mux wiring to COMP6. In CubeMX it is not possible to disable the Timer pin without also disabling the timer channel. To workaround this I needed to disable the pin after the timer is initialized using this code: HAL_GPIO_DeInit(GPIOB, GPIO_PIN_9); after TIM4 MPS GPIO init. After doing this, the internal routing of the comparator to the timer started working as expected.

5. I suspect that this issue affect all of the comparators that support linking to one of the STM32 timers. I was having this same issue when attempting to get the other comparators internally connected to the timers on the chip until I figured out the workaround.

6. Here is the code that needs to get added to the stm32f3xx_hal_msp.c file

/* USER CODE BEGIN TIM4_MspInit 1 */
/*
* TIM4_CH4 is used for the internal COMP6 -> TIM4_IC4 route, not the
* external PB9 pin. CubeMX generates PB9 as TIM4_CH4 for input capture,
* but leaving that alternate-function pin enabled prevents the internal
* comparator capture path from working on this board/configuration.
*/

HAL_GPIO_DeInit(GPIOB, GPIO_PIN_9);
/* USER CODE END TIM4_MspInit 1 */

 

 

3 REPLIES 3
waclawek.jan
Super User

Let me guess: PB9 was pulled up, internally or externally. Otherwise the TIM4_CH4 should've been able to "see" the COMP output, as the output from COMP is ORed together with the output from GPIO AF matrix.

However, this is not communicated in the RM, and I agree that CubeMX should disable the GPIO pin automatically as soon as the internal interconnection from COMP is selected.

JW

charliepuch
Associate

Actually there was no connections/pullups at all to PB9 initially until I performed my direct Comp Output to Timer Input test.

waclawek.jan
Super User

I've just tested on a STM32F303RB, PB9 set to AF/AF2, COMP6 set with + input to PB11 (set as GPIO In - it's a TT pin so doesn't need to be set to Analog) driven by a digital output externally and - input to VREF, output into TIM4_CH4; TIM4 set to capture at TIM4_CH4. And, indeed, as long as PB9 was high, toggling at PB11->COMP6 output did not influence TIM4_CH4, as soon as I set PB9 low, toggling at PB11 started to result in TIM4_SR.CC4IF being set.

> Actually there was no connections/pullups at all to PB9 initially until I performed my direct Comp Output to Timer Input test.

IMO you had it set with the internal pullup set. Try: revert to the original "non-functioning" setup and read out and check the GPIOB registers content.

JW

Announcement

We’re moving the ST Community to a new platform to give you a better and more reliable community experience.