Why the maximum value of Tim4Encoder is 127 rather than 32767?

[SYoun.1]

int16_t GetTim4Encoder(){
    Tim4Encoder = __HAL_TIM_GET_COUNTER(&htim4);
    //__HAL_TIM_SET_COUNTER(&htim4,0);
    return Tim4Encoder;
}

[turboscrew]

That's 'counter period'-field in CubeMX.

[SYoun.1]

Counter period was 65535 from the beginning.

[turboscrew]

The counter counts from zero to ARR and then wraps back to zero. If you turn the decoder in other direction, if first wraps to ARR and then goes to zero.

When you use integers, you just interpret the value such that it's -ARR/2 to ARR/2. It's easy, if your counter is 16-bit and you use int16 as the data type. It automatically matches. That's the beauty of 2's complement. If your ARR is 0x7F, the counter increments to 0x7F (127) and then goes to zero.

[Tesla DeLorean]

Then something amiss with your printing routine or the encoder/settings. The ARR / Period value should be constraining the wrap point of the counter.

//sizeof(TxMessages) has a problem

Perhaps use strlen() when appropriate, and NUL terminate the strings.

Consider itoa() to convert integers to strings.

Show the initialization code. Ideally make a clear, simple, complete implementation of the test code, and post that. Would save a look of time trying to understand what exactly is broken, without needing to guess at what you have done.

Not sure it has yet been established which "STM32" is involved, the make/model of encoder, or how it is attached to anything.

#UphillSkiing