TIM2 (PA0/PA1) Can't Receive RS422 Encoder Signals via Differential Converter

[baby361200]

Hi all,
I'm working on an STM32F429 project and trying to read quadrature signals from an RS422 encoder (SIKO MSK5000). I'm connecting the encoder to TIM2 pins (PA0/PA1) in encoder mode (using timer input capture), but I can't get any signal detected by the timer.

The RS422 output is connected through a differential-to-TTL converter (based on MAX485), and I'm using the STM32's built-in encoder interface. However, the counter stays at zero, and I see no changes at all.

• MCU: STM32F429

• Encoder: SIKO MSK5000 (RS422 differential A/B output)

• Interface: TIM2 in encoder mode (PA0 = CH1, PA1 = CH2)

• RS422 to TTL Converter: 2x QYB-998 modules (each handling one channel)
  
  

• MSK5000 A+ / A− → QYB-998 #1 → output → STM32 PA0 (CH1)

• MSK5000 B+ / B− → QYB-998 #2 → output → STM32 PA1 (CH2)

• Both converters powered by 5V (shared with STM32)

• All GNDs connected properly

• TIM2 initialized in encoder mode (count on both edges)

Any advice, especially from those who’ve worked with encoder mode + RS422, would be greatly appreciated! I’m happy to provide schematics or scope captures if that helps.

Thanks in advance!

[waclawek.jan]

Observe GPIOA_IDR to see whether the input signals propagate to the given two pins.

JW

[baby361200]

Hi, thanks for the suggestion!

Just to clarify — do you mean I should observe the input state of PA0 and PA1 by reading GPIOA->IDR inside the main() loop like this?

while (1) {
uint32_t idr = GPIOA->IDR;
uint8_t pa0 = idr & 0x01;
uint8_t pa1 = (idr >> 1) & 0x01;
printf("PA0: %d, PA1: %d\r\n", pa0, pa1);
HAL_Delay(100);
}

Is this the method you meant for checking if the signals are actually reaching the pins?

I’m using STM32CubeIDE, so I can also monitor GPIOA->IDR in the debugger.

Thanks again for your help!

[waclawek.jan]

Well either of what you've mentioned above. The idea is to exclude hardware error and make sure the A and B signals reach the respective pins. Of course, if you have an oscilloscope, you'd just measure the signals directly at the mcu's pins.

If there's adequate signal and the timer does not count, the next step is to read out and check/post the TIM and relevant GPIO registers' content.

JW

[waclawek.jan]

Have you tried the short snippet of code you've written above?

From the video it appears that you are using the 'F429 Disco board. Note, that even the pins brought out to the headers are still connected to on-board circuitry; check that in the documentation/schematics. You may want to choose some other pins; or you may want to experiment on a "plain" board such as Nucleo.

JW

[baby361200]

Thanks for your insight. I’ll look into the schematic and try with different pins, or switch to a Nucleo board if needed. Appreciate the advice!

[waclawek.jan]

Have you tried the experiment with reading GPIOA_IDR?

JW

[baby361200]

I’ve encountered a new issue while debugging using GPIO->IDR to directly read the encoder signals.

I’m using two separate RS422-to-TTL converter boards, and I connect their outputs to PA0 and PA1 respectively. However, I noticed that only the signal connected to PA0 responds correctly and follows the encoder changes.

The one connected to PA1 behaves abnormally — it either doesn’t respond correctly or gives unstable results.

Interestingly, when I connect the same signal (from the problematic converter) to PA0 instead of PA1, it works fine.

So it seems like the problem might be related specifically to PA1 not reacting properly.

Do you have any idea what could be causing this?

Thanks again!

[waclawek.jan]

That encoder appears to have a huge resolution, and probably holding it by hand causes enough instability of the signals.

At any case, if you see PA0/PA1 changing in IDR, the timer in encoder mode should count, too. If it does not, read out and check/post content of timer and GPIOA registers.

JW

[baby361200]

To verify whether the input signals are working correctly, I used the onboard GPIO LEDs to manually check the waveform behavior from each RS422-to-TTL output.

I've attached a video showing the test.

Based on the experiment, all signals behave as expected until I connect them to the TIM2 encoder input pin PA1. That’s when the abnormal behavior begins.

This suggests the issue may not be with the signal itself, but rather something related specifically to using PA1 as a TIM2 encoder input.

Let me know if you have any thoughts or further suggestions.
Thanks again!

[waclawek.jan]

> Can STM32 GPIO pins safely accept 5V TTL input signals directly?

Only those pins which are marked as 5-volt tolerant (FT) in the Pin assignment and description table in datasheet.

If you look at that table in the STM32F429 or STM32F446 datasheet, you should see that they have all pins 5-volt tolerant (FT) except PA4 and PA5, but check yourself.

JW

[baby361200]

So far, I've narrowed down the issue to the PA1 pin used for the TIM2 encoder input.

When I connect the encoder signal to PA0, everything behaves normally. But when I use PA1, the signal becomes unstable or doesn’t register properly.

I've verified that the input waveform is clean using an LED test, and the signal source is the same in both cases. This leads me to believe the problem is specifically related to PA1.

At this point, I’m honestly quite lost and exhausted after spending several days troubleshooting. I’m not sure what else could be wrong with this particular pin.

Could there be any other possible reasons that might cause this behavior with PA1 when used in encoder mode?

Any suggestions or guidance would be greatly appreciated.
Thanks again for your time and support.