terjeio / grblHAL

This repo has moved to a new home https://github.com/grblHAL
232 stars 90 forks source link

Getting TMC2209 working on SKR PRO #337

Open Creepop opened 2 years ago

Creepop commented 2 years ago

Hello everybody.

I have a SKR PRO board that I wanted to use for a small CNC router project. I've been trying to get the trinamic TMC2209 drivers working for the past few days to no avail. The first thing to fix is the if statement in the interrupt file in the software uart timer interrupt (the handler is not included for SKR PRO, just SKR 2). Secondly, I'm not sure if I am somehow special, but my board has an 8MHz crystal on it, yet the firmware forces HSE to be set to 25MHz. Ok, those two things are easy enough to fix and that is not a problem. However: The firmware does appear to be able to communicate with the drivers through UART. I'm getting the message: Warning: Could not communicate with stepper driver! Removing the requirement of the attempt succeeding in the trinamic_drivers_init() while loop, therefore causing it to attempt to communicate with all the stepper drivers, not just the first one, I see that all of them fail, outputting the same message 3 times. Tracing it further I noticed that in tmc_uart_read() it sometimes passes and reads the data properly, sometimes times out. Looking at the UART line on a scope confirms this, I can see 5ms gaps in the data transfer (reffering to the 5ms timeout period). I can also see that since the connection on the microcontroller side of things is through a 1K resistor and there is a 20k pulldown resistor on the TMC2209 module itself, the high voltage level when the microcontroller is in control of the UART line is lower than when the TMC2209 takes control of the line. I can use this to differentiate when one or the other device controls the UART line and this is apparent on the scope as well. However, it seems that the driver is not always responding, sometimes I can see communication from just the MCU. I haven't delved deep enough into the code just yet to know what data to expect to read going in either direction (or exactly how the single-wire UART on the TMC2209 works), so decoding the UART signals doesn't provide all that much value at this point in time. In the TMC2209_Init() function it returns true (1) if exactly 7 registers have been read (as far as I can tell). Placing a breakpoint at the end of this function, I can see that sometimes it fails the status register check, sometimes it passes and gets to the end of the function where it has managed to read a random number of registers (0-7). That is about as far as I've gotten. To rule out a hardware failure, I quickly flashed klipper (a 3D printer firmware for those unaware) and managed to confirm that klipper is able to comunicate with the drivers just fine with no hardware adjustments. I did use the direct path to the GPIO pins of the microcontroller (not through 1k resistor) for the klipper firmware, however I did also try that on GRBLHAL with no success.

Anyone has any ideas on what the cause might be and where to look? Tracing all of the trinamic code to figure out what does what and how would take days for me and at that point it makes more sense for to just use the drivers in standalone more. Might be able to figure out what is going on with some pointers though. Also, if there is something that needs testing on the SKR Pro, I would be happy to help.

terjeio commented 2 years ago

Try with this:

btt_skr_1.1.zip

Creepop commented 2 years ago

image

That seems to have done the trick. Thanks. Did you already have this prepared or was some of my rambling actually helpful?

terjeio commented 2 years ago

Did you already have this prepared or was some of my rambling actually helpful?

I have hardware UART mode working for my Nucleo-64 BOB so I knew that it was likely the low level driver code that was at fault. So I wired up my board with only one driver and checked signalling with my scope. Comparing hardware UART with the one generated by this code I saw that the initial state was incorrect, the UART line has to be driven high at startup or driver communication fails.

The first thing to fix is the if statement in the interrupt file in the software uart timer interrupt (the handler is not included for SKR PRO, just SKR 2).

I did not know about this so I moved the handler to the board code, will do so for the SKR2 as well. This comment was helpful for sorting that out.

terjeio commented 2 years ago

I have now committet an update with the final modifications, It will be helpful if you can test this and report back.

Creepop commented 2 years ago

Seems to be working. I haven't yet checked if the steppers are working fine, but I can confirm that they are being read without any issues, same as before. One thing I wanted to clarify though: do I have to configure something extra in the STM32CubeIDE project? When pulling a fresh project from github, the compiler is always complaining about any header include that points to a folder. It seems that it is looking for files in the path referenced to the current folder rather than the project root folder, meaning, I have to manually replace all "grbl/hal.h" with "../grbl/hal.h" (hal.h is just an example, it works this way for all includes that point inside of a folder). Also just to clarify: where does the 25MHz crystal requirement come from? I looked into the SKR PRO (v1.1) schematic on github and the schematic matches my board: it runs on an 8 MHz crystal. https://github.com/bigtreetech/BIGTREETECH-SKR-PRO-V1.1/blob/master/Schematic/SKR-PRO-V1.1%EF%BC%88SCH%EF%BC%89.pdf

terjeio commented 2 years ago

One thing I wanted to clarify though: do I have to configure something extra in the STM32CubeIDE project? When pulling a fresh project from github, the compiler is always complaining about any header include that points to a folder.

This is due to you choosing a different name for the project than the suggested one when importing. I will commit a fix for this later.

Also just to clarify: where does the 25MHz crystal requirement come from? I looked into the SKR PRO (v1.1) schematic on github and the schematic matches my board: it runs on an 8 MHz crystal.

Some has mentioned that a 25 MHz crystal has to be configured or USB will not work. I do not have a board to check with so cannot tell what is correct. Or perhaps there are two versions floating around? Does USB comms work for you when compiling for a 8 MHZ crystal?

Creepop commented 2 years ago

Some has mentioned that a 25 MHz crystal has to be configured or USB will not work. I do not have a board to check with so cannot tell what is correct. Or perhaps there are two versions floating around? Does USB comms work for you when compiling for a 8 MHZ crystal?

Do you happen to have a link for this? I have checked the schematic for the SKR PRO v1.2 aswell and that also indicates the crystal to be 8MHz. I would highly doubt that any atleast semi-reputable manufacturer (even a far east one) would have a significant change like the main clock crystal frequency changing be undocumented. That would break tons of code. If the HSE value doesn't match the crystal frequency then plenty of other timing critical things should break, including UART baudrate (assuming auto-baudrate isn't used), not just USB. And yes, USB works with HSE set to 8MHz. Haven't tested if it hangs or the computer just doesn't recognize the device (due to heavy baudrate mismatch on the USB data lines), but I can confirm that USB does not work with HSE set to 25MHz.

Regarding the project name: I pulled the repository in the workspace folder using git: git clone --recurse-submodules https://github.com/grblHAL/STM32F4xx.git And imported the project into the workspace without copying (since it is already in the workspace folder). Didn't change any names anywhere (wasn't aware that I can do that), so I'm not 100% sure what you mean.

terjeio commented 2 years ago

Do you happen to have a link for this?

Here is one - in my experience when the USB clock is not correct the port will not enumerate. Confusing...

And imported the project into the workspace without copying...

Ok, then it has the name you gave the project when initially importing it, or it lives in a differently named folder. If not GRBL Driver STM32F401 many files will not be found. There are folder specifications in the .cproject file that has GRBL Driver STM32F401 as part of the path, I have changed those to a variable reference instead. See this issue for a similar problem.

Try replacing the .cproject file with this:

cproject.zip

Creepop commented 2 years ago

I quickly read through the topic: the person also has TMC 2209 defined. As stated earlier, if the interrupt handler for TIM7 is not defined, the board hangs, so USB ends up not being able to enumerate. Since the author doesn't seem to have the board running yet, I think that this is at least a part of the problem. Anyway, the crystal value is clearly stated on the crystal itself, please have people just read the value off the crystal itself if there is confusion, that should clear it up.

Here is one - in my experience when the USB clock is not correct the port will not enumerate. Confusing...

What I believe happens here is that pull-ups get enabled on the MCU end, so the host tries to enumerate a newly detected device, but since the clocks are mismatched therefore the transfered data is a mess and always fails CRC and gets discarded, after 5 or 10 seconds (can't remember) windows just gives up. So it makes sense. This also happens if the device stops responding before enumeration finishes (the situation described in the previous paragraph).

All in all, so far this whole crystal situation seems dubious at best.

I will try the C project in the evening if I remember to.

terjeio commented 2 years ago

As stated earlier, if the interrupt handler for TIM7 is not defined, the board hangs, so USB ends up not being able to enumerate.

This should be fixed in the latest build. The main problem was to to get the the binary up and running via the bootloader. I guess it is now.

Anyway, the crystal value is clearly stated on the crystal itself, please have people just read the value off the crystal itself if there is confusion, that should clear it up.

This is not always possible since many are not marked at all or with cryptic letters.

olijouve commented 2 years ago

Hi @Creepop, glad to read that thread and to see your more skilled than me on that !

My board is a SKR Pro 1.2. You are definitely right for 8MHz crystal ! I visually checked it on my board and i took some pics: https://ibb.co/L9G5fxn https://ibb.co/C0p6nP9

One step further for my next tests !

As stated earlier, if the interrupt handler for TIM7 is not defined, the board hangs, so USB ends up not being able to enumerate. Since the author doesn't seem to have the board running yet, I think that this is at least a part of the problem.

I tried to understand but i cannot see what you meant saying "if the interrupt handler for TIM7 is not defined." Any direction to define it ?

terjeio commented 2 years ago

I tried to understand but i cannot see what you meant saying "if the interrupt handler for TIM7 is not defined." Any direction to define it ?

This should be fixed in the latest build. First step for you is to get communication up and running, disable Trinamic drivers until then.

olijouve commented 2 years ago

It's alive !

 GrblHAL 1.1f ['$' or '$HELP' for help]
[MSG:'$H'|'$X' to unlock]
error:9
G-code locked out during alarm or jog state.
error:18
[VER:1.1f.20211209:]
[OPT:VNMSL,35,1024,3,0]
Target buffer size found
[NEWOPT:ENUMS,RT+,TC,SED]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:STM32F407]
[DRIVER VERSION:211209]
[BOARD:BTT SKR PRO v1.1]
ok

Here are the flags used with a fresh clone of repository:

  -D BOARD_BTT_SKR_PRO_1_1=
  -D USB_SERIAL_CDC=1
  # Boot loader offset (32K)
  -D HSE_VALUE=8000000
  -D HAS_BOOTLOADER

EDIT: it also loads with -D TRINAMIC_ENABLE=2209 GRBL ouput one more line: [PLUGIN:Trinamic v0.07]

olijouve commented 2 years ago

image

That seems to have done the trick. Thanks. Did you already have this prepared or was some of my rambling actually helpful?

How do you get that output ?

terjeio commented 2 years ago

How do you get that output ?

See the plugin readme for settings and M-commands provided.

Start with enabling one motor with $338, e.g. $338=1 for the X-axis. If initialization of the TMC2209 goes well M122 will output the report.

olijouve commented 2 years ago

Thanks.

M122 returns error:9 G-code locked out during alarm or jog state.

It's very cold in my worshop where my CNC is, so for testing purpose i do my test at home with only one motor connected on X and anything else(no limit switch connected). Could it be a problem ?

terjeio commented 2 years ago

Could it be a problem ?

Yes, could be that the reset pin is read as asserted if not connected to ground. Try $14=7 to invert the inputs. If this does not help post the output from a ? real-time status request.

olijouve commented 2 years ago

M122 doesn't report expecting infos, but if i try a movement on X the motor moves ! M122 [MSG:Warning: Could not communicate with stepper driver!] ok <Idle|MPos:0.000,0.000,0.000|Bf:35,1023|FS:0,0|Pn:PXYZ|Ov:100,100,100> ok Starting stream [MSG:Pgm End] Stream completed in 0:01

Edit: I precise i did replaced Src/btt_skr_1.1.c with the one you shared 4 days ago.

Creepop commented 2 years ago

Pull the latest version from the repository again, it should be working. Just make sure to use 8MHz as the clock frequency (possibly comment out the part where doing so throws an error). Also: do you have the jumpers connected properly? Was Marlin able to communicate with the drivers?

Creepop commented 2 years ago

terjeio:

Regarding the cproject file: Thanks, it did the trick. Git automatically created the folder with the name of the repository (STM32F4xx), I'm guessing that was the issue. With the new cproject file, that is no longer a problem. I always pull projects directly into the workspace to be able to track any changes I make if necessary. Is there an issue with this workflow? Regarding this comment

As stated earlier, if the interrupt handler for TIM7 is not defined, the board hangs, so USB ends up not being able to enumerate.

The topic mentioned has the last comments 4 days ago so the author would have used the unfixed version. Therefore anything he did would result in crashed firmware as long as TMC2209 was enabled.

olijouve: First thing to check is whether you have power going to the stepper drivers (the motor power rail). I just build a totally unchanged code directly from the repository (only commenting this line from btt_skr_pro_v1_1_map.h): #error "This board has STM32F407 processor with a 25MHz crystal, select a corresponding build!" ,selected build configuration 12 (Release F407 8MHz), defined BOARD_BTT_SKR_PRO_1_1 and TRINAMIC_ENABLE as 2209. Doing only these steps, I can verify that the board is working properly. Haven't tested the sdcard bootloader though (as long as USB bootloader exists, I think having a seperate non-native bootloader on top of it is stupid and redundant). In case you can't get it working, I can try to share the built binary, if there is no hardware issue, that should be working. Be aware though that I don't use the SD card bootloader, you would have to use the USB bootloader (put a jumper between BOOT0 and 3V3 rail, you can see the markings on the bottom of the board, then plug in USB to give it power). The board should get recognized as DFU bootloader and then you can use STM32CubeProgrammer to flash the image. This would remove the SD card bootloader, but after you learn how to flash the board without it, it becomes unnecessary.

olijouve commented 2 years ago

The setup i've followed on my board is entirely describe here(with pictures): https://docs.v1engineering.com/electronics/skrpro/

My setup use Dual End Stops (with EXTRUDERS 0 and 1 ), so i do not use Sensorless homing and i bended the corresponding drivers pin as describe.

I guess Marlin(v1engineering preconfigured release) is able to talk with drivers as i had absolutely nothing to configure(2209 UART current...) and every thing moves nicely.

Does a correctly moving motor means that the firmware can communicate correctly with the drivers ? Because the last test i've done shows that the lonely X motor i used for testing is now moving correctly.

I only use the SD card bootloader and thanks to @terjeio flashed firmware now loads ok. Not as pratical as a USB flashing method for sure but for now i just prefer keeping it that simple.

olijouve commented 2 years ago

@Creepop, would you mind to share a picture of how you connected everything on your board ?

olijouve commented 2 years ago

I flashed back to Marlin to see what Marlin M122 is returning:

M122
axis:pwm_scale/curr_scale/mech_load|flags|warncount
        X   X2  Y   Y2  Z
Address     0   0   0   0   0
Enabled     false   false   false   false   false
Set current 900 900 900 900 900
RMS current 887 887 887 887 887
MAX current 1251    1251    1251    1251    1251
Run current 28/31   28/31   28/31   28/31   28/31
Hold current    22/31   22/31   22/31   22/31   22/31
CS actual   22/31   22/31   22/31   22/31   22/31
PWM scale
vsense      1=.18   1=.18   1=.18   1=.18   1=.18
stealthChop false   false   false   false   false
msteps      16  16  16  16  16
tstep       max max max max max
PWM thresh.
[mm/s]
OT prewarn  false   false   false   false   false
triggered
 OTP        false   false   false   false   false
pwm scale sum   25  25  25  25  25
pwm scale auto  0   0   0   0   0
pwm offset auto 36  36  36  36  36
pwm grad auto   14  14  14  14  14
off time    3   3   3   3   3
blank time  24  24  24  24  24
hysteresis
 -end       -1  -1  -1  -1  -1
 -start     1   1   1   1   1
Stallguard thrs 0   0   0   0   0
uStep count 40  8   40  40  8
DRVSTATUS   X   X2  Y   Y2  Z
sg_result   0   0   0   0   0
stst
olb     *   *   *   *   *
ola     *   *   *   *   *
s2gb
s2ga
otpw
ot
157C
150C
143C
120C
s2vsa
s2vsb
Driver registers:
        X   0x80:16:00:C0
        X2  0x80:16:00:C0
        Y   0x80:16:00:C0
        Y2  0x80:16:00:C0
        Z   0x80:16:00:C0
Testing X connection... OK
Testing X2 connection... OK
Testing Y connection... OK
Testing Y2 connection... OK
Testing Z connection... OK

M122 doc doesn't say much on output but at least i guess this output means that communication with drivers is ok. https://marlinfw.org/docs/hardware/tmc_drivers.html

So i have just built a fresh clone of grabHAL STM32F4xx, comment the #error for 25Mhz and flash the board again but i still got that communicartion issue with stepper drivers:

GrblHAL 1.1f ['$' or '$HELP' for help]
[MSG:Warning: Could not communicate with stepper driver!]
ok
[VER:1.1f.20211209:]
[OPT:VNMSL,35,1024,3,0]
...
[BOARD:BTT SKR PRO v1.1]
[PLUGIN:Trinamic v0.07]
ok
M122
[MSG:Warning: Could not communicate with stepper driver!]

Could it be a different pinout between SKR pro 1.1 and 1.2 ? It would be strange as it's announced as untouched in documentation.

I will try to activate M43 pin debug command in Marlin to see if i can get a pin report.

olijouve commented 2 years ago

Not sure if it could be helpfull:

M43
PIN: PA0  (A0)   M42 P35          E0_DIR_PIN                             protected
.                                 X2_DIR_PIN                             protected
PIN: PA1  (A1)   M42 P36          SERVO0_PIN                             Input  = 0
PIN: PA2  (A2)   M42 P37          <unused/unknown>                       Input  = 0
PIN: PA3  (A3)   M42 P38          E1_ENABLE_PIN                          protected
.                                 Y2_ENABLE_PIN                          protected
PIN: PA4  (A4)   M42 P39          <unused/unknown>                       Input  = 1
PIN: PA5  (A5)   M42 P40          <unused/unknown>                       Input  = 1
PIN: PA6  (A6)   M42 P41          <unused/unknown>                       Input  = 1
PIN: PA7  (A7)   M42 P42          <unused/unknown>                       Input  = 0
PIN: PA8         M42 P16          BTN_ENC                                Input  = 1
PIN: PA9         M42 P17          <unused/unknown>                       Alt Function: 7  - USART1..3
PIN: PA10        M42 P18          <unused/unknown>                       Alt Function: 7  - USART1..3
PIN: PA11        M42 P19          <unused/unknown>                       Alt Function: 10 - OTG
PIN: PA12        M42 P20          <unused/unknown>                       Alt Function: 10 - OTG
PIN: PA13        M42 P21          <unused/unknown>                       Alt Function: 0  - system (misc. I/O)
PIN: PA14        M42 P22          <unused/unknown>                       Alt Function: 0  - system (misc. I/O)
PIN: PA15        M42 P23          <unused/unknown>                       Alt Function: 0  - system (misc. I/O)
PIN: PB0  (A8)   M42 P43          HEATER_2_PIN                           Output = 0
.                                 SPINDLE_LASER_ENA_PIN                  Output = 0
PIN: PB1  (A9)   M42 P44          HEATER_0_PIN                           Output = 0
PIN: PB2         M42 P5           <unused/unknown>                       Input  = 0
PIN: PB3         M42 P28          E0_CS_PIN                              Alt Function: 0  - system (misc. I/O)
PIN: PB4         M42 P29          <unused/unknown>                       Alt Function: 0  - system (misc. I/O)
PIN: PB5         M42 P30          <unused/unknown>                       Input  = 1
PIN: PB6         M42 P31          <unused/unknown>                       Input  = 0
PIN: PB7         M42 P32          <unused/unknown>                       Input  = 0
PIN: PB8         M42 P33          <unused/unknown>                       Input  = 0
PIN: PB9         M42 P34          <unused/unknown>                       Input  = 0
PIN: PB10        M42 P6           X_MIN_PIN                              protected
.                                 X_DIAG_PIN                             protected
.                                 X_STOP_PIN                             protected
PIN: PB11        M42 P7           <unused/unknown>                       Input  = 0
PIN: PB12        M42 P8           SDSS                                   Output = 1
.                                 SS_PIN                                 Output = 1
PIN: PB13        M42 P9           DOGLCD_SCK                             Input  = 0
.                                 SCK_PIN                                Input  = 0
PIN: PB14        M42 P10          MISO_PIN                               Input  = 0
PIN: PB15        M42 P11          DOGLCD_MOSI                            Input  = 0
.                                 MOSI_PIN                               Input  = 0
PIN: PC0  (A10)  M42 P45          Z_ENABLE_PIN                           protected
PIN: PC1  (A11)  M42 P46          <unused/unknown>                       Input  = 0
PIN: PC2  (A12)  M42 P47          Z_DIR_PIN                              protected
PIN: PC3  (A13)  M42 P48          E0_ENABLE_PIN                          protected
.                                 X2_ENABLE_PIN                          protected
PIN: PC4  (A14)  M42 P49          <unused/unknown>                       Input  = 0
PIN: PC5  (A15)  M42 P50          <unused/unknown>                       Input  = 0
PIN: PC6         M42 P12          <unused/unknown>                       Input  = 0
PIN: PC7         M42 P13          <unused/unknown>                       Input  = 0
PIN: PC8         M42 P14          FAN_PIN                                protected
PIN: PC9         M42 P15          SERVO1_PIN                             Alt Function: 3  - TIM8..11 (probably PWM)
.                                 SPINDLE_LASER_PWM_PIN                  Alt Function: 3  - TIM8..11 (probably PWM)
PIN: PC10        M42 P24          <unused/unknown>                       Input  = 0
PIN: PC11        M42 P25          <unused/unknown>                       Input  = 0
PIN: PC12        M42 P26          <unused/unknown>                       Input  = 0
PIN: PC13        M42 P0           X_SERIAL_TX_PIN                        Output = 1
.                                 X_SERIAL_RX_PIN                        Output = 1
PIN: PC14        M42 P1           <unused/unknown>                       Input  = 0
PIN: PC15        M42 P2           <unused/unknown>                       Input  = 0
PIN: PD0         M42 P81          <unused/unknown>                       Input  = 0
PIN: PD1         M42 P82          Y2_SERIAL_TX_PIN                       Output = 1
.                                 Y2_SERIAL_RX_PIN                       Output = 1
.                                 E1_SERIAL_TX_PIN                       Output = 1
.                                 E1_SERIAL_RX_PIN                       Output = 1
PIN: PD2         M42 P27          <unused/unknown>                       Input  = 1
PIN: PD3         M42 P83          <unused/unknown>                       Input  = 0
PIN: PD4         M42 P84          X2_SERIAL_TX_PIN                       Output = 1
.                                 X2_SERIAL_RX_PIN                       Output = 1
.                                 E0_SERIAL_TX_PIN                       Output = 1
.                                 E0_SERIAL_RX_PIN                       Output = 1
PIN: PD5         M42 P85          <unused/unknown>                       Input  = 0
PIN: PD6         M42 P86          E2_SERIAL_TX_PIN                       Input  = 0
.                                 E2_SERIAL_RX_PIN                       Input  = 0
PIN: PD7         M42 P87          Y_ENABLE_PIN                           protected
PIN: PD8         M42 P73          <unused/unknown>                       Input  = 0
PIN: PD9         M42 P74          <unused/unknown>                       Input  = 0
PIN: PD10        M42 P75          LCD_PINS_RS                            Output = 0
PIN: PD11        M42 P76          LCD_PINS_ENABLE                        Output = 0
PIN: PD12        M42 P77          HEATER_BED_PIN                         Input  = 0
PIN: PD13        M42 P78          E2_STEP_PIN                            Input  = 0
PIN: PD14        M42 P79          HEATER_1_PIN                           Output = 0
PIN: PD15        M42 P80          E1_STEP_PIN                            protected
.                                 Y2_STEP_PIN                            protected
PIN: PE0         M42 P88          <unused/unknown>                       Input  = 0
PIN: PE1         M42 P89          Z_SERIAL_TX_PIN                        Input  = 1
.                                 Z_SERIAL_RX_PIN                        Input  = 1
PIN: PE2         M42 P59          <unused/unknown>                       Input  = 0
PIN: PE3         M42 P60          Y_SERIAL_TX_PIN                        Input  = 1
.                                 Y_SERIAL_RX_PIN                        Input  = 1
PIN: PE4         M42 P61          <unused/unknown>                       Input  = 0
PIN: PE5         M42 P62          FAN1_PIN                               protected
PIN: PE6         M42 P63          FAN2_PIN                               protected
PIN: PE7         M42 P64          E1_DIR_PIN                             protected
.                                 Y2_DIR_PIN                             protected
PIN: PE8         M42 P65          Y_DIR_PIN                              protected
PIN: PE9         M42 P66          X_STEP_PIN                             protected
PIN: PE10        M42 P67          FIL_RUNOUT2_PIN                        protected
.                                 Y_MAX_PIN                              protected
.                                 Y2_MIN_PIN                             protected
.                                 E1_DIAG_PIN                            protected
PIN: PE11        M42 P68          Y_STEP_PIN                             protected
PIN: PE12        M42 P69          Y_MIN_PIN                              protected
.                                 Y_DIAG_PIN                             protected
.                                 Y_STOP_PIN                             protected
PIN: PE13        M42 P70          Z_STEP_PIN                             protected
PIN: PE14        M42 P71          E0_STEP_PIN                            protected
.                                 X2_STEP_PIN                            protected
PIN: PE15        M42 P72          X_MAX_PIN                              protected
.                                 X2_MIN_PIN                             protected
.                                 E0_DIAG_PIN                            protected
PIN: PF0         M42 P90          E2_ENABLE_PIN                          Input  = 1
PIN: PF1         M42 P91          X_DIR_PIN                              protected
PIN: PF2         M42 P92          X_ENABLE_PIN                           protected
PIN: PF3  (A16)  M42 P51          <unused/unknown>                       Input  = 1
PIN: PF4  (A17)  M42 P52          <unused/unknown>                       Input  = 1
PIN: PF5  (A18)  M42 P53          <unused/unknown>                       Input  = 1
PIN: PF6  (A19)  M42 P54          <unused/unknown>                       Input  = 1
PIN: PF7  (A20)  M42 P55          <unused/unknown>                       Input  = 0
PIN: PF8  (A21)  M42 P56          <unused/unknown>                       Input  = 0
PIN: PF9  (A22)  M42 P57          <unused/unknown>                       Input  = 0
PIN: PF10 (A23)  M42 P58          <unused/unknown>                       Input  = 0
PIN: PF11        M42 P93          BTN_EN2                                Input  = 1
PIN: PF12        M42 P94          SD_DETECT_PIN                          Input  = 1
PIN: PF13        M42 P95          <unused/unknown>                       Input  = 0
PIN: PF14        M42 P96          ESP_WIFI_MODULE_GPIO0_PIN              Input  = 1
PIN: PF15        M42 P97          ESP_WIFI_MODULE_GPIO2_PIN              Input  = 1
PIN: PG0         M42 P98          ESP_WIFI_MODULE_RESET_PIN              Input  = 1
PIN: PG1         M42 P99          ESP_WIFI_MODULE_ENABLE_PIN             Input  = 1
PIN: PG2         M42 P100         LCD_PINS_D4                            Input  = 1
PIN: PG3         M42 P101         LCD_PINS_D5                            Input  = 0
PIN: PG4         M42 P102         BEEPER_PIN                             Input  = 0
PIN: PG5         M42 P103         FIL_RUNOUT3_PIN                        Input  = 1
.                                 E2_DIAG_PIN                            Input  = 1
PIN: PG6         M42 P104         LCD_PINS_D6                            Input  = 0
PIN: PG7         M42 P105         LCD_PINS_D7                            Input  = 0
PIN: PG8         M42 P106         Z_MIN_PIN                              protected
.                                 Z_DIAG_PIN                             protected
.                                 Z_STOP_PIN                             protected
PIN: PG9         M42 P107         E2_DIR_PIN                             Input  = 0
PIN: PG10        M42 P108         BTN_EN1                                Input  = 1
PIN: PG11        M42 P109         <unused/unknown>                       Input  = 0
PIN: PG12        M42 P110         E2_CS_PIN                              Input  = 0
PIN: PG13        M42 P111         <unused/unknown>                       Input  = 0
PIN: PG14        M42 P112         <unused/unknown>                       Input  = 0
PIN: PG15        M42 P113         E1_CS_PIN                              Input  = 0
PIN: PH0         M42 P3           <unused/unknown>                       Input  = 0
PIN: PH1         M42 P4           <unused/unknown>                       Input  = 0

Seeing at Marlin sources, the pinout for 1.1 and 1.2 are the same, https://github.com/MarlinFirmware/Marlin/blob/ee26fd0e0559d7f2d86b11b5552eaf9c9ff3174c/Marlin/src/pins/stm32f4/pins_BTT_SKR_PRO_common.h

terjeio commented 2 years ago

@olijouve What is your $338 setting value? If not 1 (only X enabled) can you try with that? You have to reset the board for it to take effect. Still same error on M122?

I have made a small blunder with M122I that can be used to reset the drivers, it will not work after a failure. With that fixed we could add a debug message to see where initialization fails.

olijouve commented 2 years ago

@terjeio, yes $338=1 and $14=7 still have same error after reboot:

$338 $338=1 ok $14 $14=7 ok M122 [MSG:Warning: Could not communicate with stepper driver!] ok

Creepop commented 2 years ago

The UART jumpers are set properly in the images shown, the only difference is that I'm powering the board from USB, not the input power rail (don't even have that connected right now). Just 24V on the motor input and USB cable. image

Here is the firmware file I used (regenerated it for the bootloader, hopefully that doesn't affect anything): https://drive.google.com/file/d/125cMdk0ibwENKthEeoRcAcPqEFC8xEPT/view?usp=sharing

If this doesn't work, then you can try to change the UART pin numbers. If you look at the schematic, you will find that all UART pins are connected to the MCU through a 1k resistor as well as directly, you can try the direct path (grblHAL uses the pin number that are connected through the 1k resistors by default). I run the direct path on klipper and that is also working normally. Not quite sure what else could be different. I have a v1.2 of the board on hand as well, but it is on a working printer that I don't wish to mess around with unless necessary.

olijouve commented 2 years ago

@Creepop, I just reconnected my board just like yours, removed Power VCC to USB(with jumper),remove the 2 jumpers between Z and E0, also 24V on motors and i tried your firmware but changed nothing on M122 / driver communication. I removed every drivers but X, i swaped driver in case of deffective one... not better.

I have compared schematics of v1.1 and v1.2 but i can't see any difference on drivers pinout. https://teamgloomy.github.io/skr_pro_pins.html One difference on UART port on the right is it run on 5V in v1.1 and on 3.3V in v1.2... but i'm not sure it could be related...

EDIT : I also tried to unbend the sensorless homing pin

Creepop commented 2 years ago

The only changes between V1.1 and V1.2 I was able to spot in the schematic (entierly possible that I didn't look hard enough) is the introduction of D23 in V1.2 so I highly doubt that it has anything to do with the board revision. Sensorless homing should also have nothing to with this. Did you try to flash the firmware I posted earlier?

olijouve commented 2 years ago

Yes i did flashed you firmware but same result. [MSG:Warning: Could not communicate with stepper driver!]

I'll try to connect the board to my cnc this week end, maybe more chances with more motors connected and limit switchs...

Creepop commented 2 years ago

No, none of that should matter in any way (I also don't have the board connected to anything at the moment). At this point the only thing I can suggest is to try the direct path as stated above (not sure if you tried it already) image

Taking Z driver as an example, the UART line is connected to PE0 through a 1k resistor, but to PE1 directly. Based on your Marlin output, Marlin also uses the direct path unlike GRBLHAL. You can try to change the pin map so that the UART lines use the same pins as Marlin (the direct path), maybe that can help. Aside from the, if you don't have access to a logic analyser or an oscilloscope then you will just have to wait for terjeio to sprikle some debug statements around the code to try and figure out what fails. We know that the code works (I've tested that personally), the hardware works (Marlin works for you), not quite sure what else can go wrong without measurment tools to help.

olijouve commented 2 years ago

@Creepop, you're a freaking genious ! You were right !!

I changed STM32F4xx/Inc/btt_skr_pro_v1_1_map.h

#if TRINAMIC_UART_ENABLE

//#define MOTOR_UARTX_PORT            GPIOE
//#define MOTOR_UARTX_PIN             4
//#define MOTOR_UARTY_PORT            GPIOE
//#define MOTOR_UARTY_PIN             2
//#define MOTOR_UARTZ_PORT            GPIOE
//#define MOTOR_UARTZ_PIN             0

#define MOTOR_UARTX_PORT            GPIOC
#define MOTOR_UARTX_PIN             13
#define MOTOR_UARTY_PORT            GPIOE
#define MOTOR_UARTY_PIN             3
#define MOTOR_UARTZ_PORT            GPIOE
#define MOTOR_UARTZ_PIN             1

And now, after reconfiguring $338 and reseting the driver i get TRINAMIC report !!

$338=7
ok
M122I
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        true    true    true
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            1       1       1
hysteresis
-end                 -1      -1      -1
-start                1       1       1
Stallguard thrs       0       0       0
DRIVER STATUS:
stallguard
sg_result             0       0       0
fsactive
stst                  *       *       *
olb
ola
s2gb
s2ga
otpw
ot
STATUS REGISTERS:
 X = 0xC0:07:00:00
 Y = 0xC0:07:00:00
 Z = 0xC0:07:00:00

So I guess we will need a dedicated map file for v1.2. I now have to find where to update correct values for X_GANGED and Y_GANGED drivers as i can't see it in map.h

Many thanks to both of you for your time, patience... and skills !

terjeio commented 2 years ago

Good catch!

I now have to find where to update correct values for X_GANGED and Y_GANGED drivers as i can't see it in map.h

Ganging/auto squaring is defined in my_machine.h, pins are defined for motors M3_xx - M5_xx in the map file. Motors are allocated to axis and function automagically by a bit of preprocessor code.

Creepop commented 2 years ago

If this is the case, @terjeio, I don't see a good reason against setting the direct path in the default pin map, both variants work just fine on the V1.1 board. Good to know that it is working for you, olijouve.

terjeio commented 2 years ago

I have just commited an update with direct patch in the pin map and SKR 1.2 added as a synomym for SKR 1.1 (they use the same map file for now).

Note that I have added separate Startup folders for F407 and F446, I do not know how that will affect PIO builds - perhaps those not needed has to be deleted to avoid duplicate symbols? In Eclipse I can configure which folder to use for which build, but I have not found compiler (or assembler flags as the startup file is assembler code) controlling it.

dresco commented 2 years ago

Note that I have added separate Startup folders for F407 and F446, I do not know how that will affect PIO builds

Seems to do the right thing automatically. Is building the startup file for the selected processor out of it's own CMSIS framework folder..

The only one that doesn't build out of the box is the skr pro 1.1 - failing with "This board has STM32F407 processor with a 8MHz crystal, select a corresponding build!".

Was the consensus that it should be changed to 8MHz in platformio.ini?

olijouve commented 2 years ago

Was the consensus that it should be changed to 8MHz in platformio.ini?

@dresco, yes crystal is definitely oscillating at 8Mhz.

Lines 24 to 26 in STM32F4xx/Inc/btt_skr_pro_v1_1_map.h sould be changed to:

#if !defined(STM32F407xx) || HSE_VALUE != 8000000
#error "This board has STM32F407 processor with a 8MHz crystal, select a corresponding build!"
#endif
dresco commented 2 years ago

I was going to propose just changing the platformio.ini entry for the SKR 1.1;

   -D BOARD_BTT_SKR_PRO_1_1=
   # 8MHz crystal
-  -D HSE_VALUE=25000000
+  -D HSE_VALUE=8000000
terjeio commented 2 years ago

Lines 24 to 26 in STM32F4xx/Inc/btt_skr_pro_v1_1_map.h sould be changed ...

It has already been changed in the latest commit.

I was going to propose just changing the platformio.ini entry for the SKR 1.1;

I have not updated this, are there other changes pending as well?

dresco commented 2 years ago

I have not updated this, are there other changes pending as well?

I think just this?

diff --git a/platformio.ini b/platformio.ini
index d91a84b..f7d6163 100644
--- a/platformio.ini
+++ b/platformio.ini
@@ -57,7 +57,8 @@ build_flags =
   # You also need to uncomment FatFS and sdcard in lib_deps (see below)
   #-D SDCARD_ENABLE=1
   # Set to 1 or 2 (see Inc/my_machine.h)
-  #-D SPINDLE_HUANYANG=1
+  #-D HUANYANG_ENABLE=1
+  #-D SPINDLE_RPM_CONTROLLED
 lib_deps =
   bluetooth
   grbl
@@ -103,7 +104,7 @@ build_flags = ${common.build_flags}
   # See Inc/my_machine.h for options
   -D BOARD_BTT_SKR_PRO_1_1=
   # 8MHz crystal
-  -D HSE_VALUE=25000000
+  -D HSE_VALUE=8000000
   # Boot loader offset (32K)
   -D VECT_TAB_OFFSET=0x8000
 lib_deps = ${common.lib_deps}
olijouve commented 2 years ago

For SKR PRO v1.2 i had to add -D HAS_BOOTLOADER in place of -D VECT_TAB_OFFSET=0x8000 but maybe it has same effect.

Here are my build flags that work well for sdcard bootloader and usb serial communication: -D BOARD_BTT_SKR_PRO_1_1=1 -D USB_SERIAL_CDC=1 -D HSE_VALUE=8000000 -D HAS_BOOTLOADER -D TRINAMIC_ENABLE=2209