Open dgangola opened 7 months ago
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?
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
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.
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.
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.
Are there any news to this problem? I have a very similar one with my btt skr mini e3 v2.0, but with all of the steppers, not just y and z.
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?