Y & Z TMC2209s not being properly init'ed on BTT SKR Mini E3 V2.0

[dgangola]

The X stepper runs as expected.
Y & Z, however run at about 1/4 of the proper speed, and distance.
If I flash the stock firmware, and run it, and then flash grblHAL, without removing power, the steppers will all work as expected. After removing power, Y and Z revert to moving slowly.
I have verified that the step pulses and enable signals are getting to the '2209s, they're just moving slower.
I find myself wondering if that X '2209 is getting written three times, and the others not at all?

[terjeio]

Odd, I have a F411 based machine here that uses 2209s and that works so the Trinamic code should be ok.
Is the M122 command returning the same values for all drivers?

[dgangola]

Well, yeah, you COULD say that...

M122
ok
[MSG:Warning: Could not communicate with stepper driver!]

This is a fresh build from the web builder, downloaded today 2024-04-7 18:11 UTC

[dgangola]

Not bad code at all, but it seems to be a "feature" in the 'F103. The minimal web searching I have done does not support this, but on the 'F103, and at least on USART4, (and at least on this board) the USART_SR_RXNEIE bit is reset with each interrupt. Re-enabling it after each RX interrupt resolves the problem.

I have not seen in example code for the 'F103 the need to do this. Is it just the 'F103RCT6, or limited to USART4? The "fix" is pretty innocuous, so it should not pose a problem if it is included in a case where it is not needed.

The failure caused tmc_uart_read() to fail on the first call. NONE of the steppers were initialized. Why X seemed normal, and Y and Z were odd, I do not know.

At the end of the RX section in UART1_IRQHandler() in serial.c:

    if(UART1->SR & USART_SR_RXNE) {
        ...
#ifdef BOARD_BTT_SKR_MINI_E3_V20    // restricting to just this board
        UART1->CR1 |= USART_CR1_RXNEIE;
#endif
    }

The steppers are running at equal rates, and M122 returns better-looking data:

ok
M122
[TRINAMIC]
                      X       Y       Z
Driver          TMC2209 TMC2209 TMC2209
Set current         500     500     500
RMS current         489     489     489
Peak current        691     691     691
Run current       15/31   15/31   15/31
Hold current       7/31    7/31    7/31
CS actual          7/31    7/31    7/31
PWM scale             9       9       9
vsense          1=0.180 1=0.180 1=0.180
stealthChop       false   false   false
msteps               16      16      16
tstep           1048575 1048575 1048575
pwm
threshold             0       0       0
[mm/s]                0       0       0
OT prewarn        false   false   false
OT prewarn has
been triggered    false   false   false
off time              3       3       3
blank time            0       0       0
hysteresis
-end                 -1      -1      -1
-start                1       1       1
Stallguard thrs       0       0       0
DRIVER STATUS:
stallguard     
sg_result             0       0       2
fsactive                               
stst                  *       *       *
olb                           *        
ola                           *        
s2gb                                   
s2ga                                   
otpw                                   
ot                                     
STATUS REGISTERS:
 X = 0x80:07:00:00
 Y = 0x80:07:00:C0
 Z = 0x80:07:00:00
ok

However, the steppers are quite noisy, even at idle.
I'll test this in a K40 laser, and put together a pull request, although it hardly seems warranted.

[terjeio]

Odd, there is nothing in the errata about this. Prehaps the MCU is a clone/fake?
Anyway, I have just commited an update to the driver that allows the use uf UART4 instead of USART3, can you try that?
Change this line rom 31 to 4 to switch. Or do I have to change the Web Builder code for you to try it?
Note that I have not tested UART4 comms since I do not have a board with the pins broken out.

[dgangola]

Sorry, no. It appears to be the same problem, head in rxbuf1 never advances beyond 1. Same in both cases.

Curiously, the definitions for SERIAL_PORT and SERIAL1_PORT in the map .h don't seem to propagate throughout the project. I had to set the definitions in project properties.

I tried, very quickly, setting SERIAL1_PORT to 1, and as you might expect, it does not work. No data appears in the buffer. I'm running a fever, so this is it for today.