Pin Mapping for SKR boards, trinamic stepper drivers, and such

[raininja]

Hello @terjeio , thanks for your work here. I'm attempting to add support for the BigTreeTech SKR 1.4 board, and I'm a bit stuck on the pin assignments for spindle and coolant.

1. I'm thinking to use the Heated Bed output as it's a PWM controlled spindle. Is this appropriate?
2. I've noticed some code relating to coolant, I'm wondering if this can be made conditional?
3. The codebase at present only supports the TMC2180 stepper driver. I would like to expand this to the TMC2208.

Any guidance from any parties is welcomed.

[zmrdko]

Thanks a lot!! I have one more question: I use BIGTREETECH TMC2209 v1.2 stepper drivers which are quite popular now and have an option for sensorless homing (stallguard feature). The question is, if its reasonable to use it (if it would not false trigger under load during milling operation). The sensitivity would have to be quite high.

But the main thing is, what is required to make it work. From what I understand SKR 1.4 Turbo features both UART and SPI interfaces for stepper drivers.

[terjeio]

But the main thing is, what is required to make it work.

Support code and testing. There is code available for TMC2130, that "only" needs driver support for SPI transfers. It is possible that the TMC2209 has a similar protocol as TMC2130 so the code for that could be used as a starting point.

[zmrdko]

I just went through the tmc2209 datasheet, and it says it supports only uart mode. So that is a no go.

[terjeio]

So that is a no go.

Why? The board has wiring for UART mode so it is a matter of providing low level datagram transfer in the driver for that.

[zmrdko]

Well, that is kind of above my skill level, so I am lost..

[raininja]

@raininja how did it go? @zmrdko Mixed results. After finally achieving a build in MCUXpresso by disabling the sdcard functionality, I became a bit discouraged . . .

my attempts are described in the list to follow:

• sdcard is broken, linking issues (probably PEBKAC)
• platformio build, as I I would rather use mbedOS and flash over usb
• TMC2208 drivers I'll give it some attention for the next few days

Why? The board has wiring for UART mode so it is a matter of providing low level datagram transfer in the driver for that.

so, there is a well-known library here that is quite complete, seems like a valid starting point/reference?

I am currently trying to compile grblHAL for SKR 1.4 TURBO (LPC1769).

I'm working with the 1.4 right now but I just replaced the fan0 mosfet and fixed my turbo, so I can try this, assuming it builds properly in platformio

[raininja]

ugh! a little insight here, hopefully, @terjeio ??

Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
Target: arm-none-eabi
Configured with: /Host/Work/arm-none-eabi-gcc-8.2.1-1.4/gcc/configure --prefix=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc --infodir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/info --mandir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/man --htmldir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/html --pdfdir=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/share/doc/pdf --build=x86_64-unknown-linux-gnu --host=x86_64-w64-mingw32 --target=arm-none-eabi --with-pkgversion='GNU MCU Eclipse ARM Embedded GCC\x2C 64-bit' --enable-languages=c,c++ --enable-mingw-wildcard --enable-plugins --enable-lto --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/Host/Work/arm-none-eabi-gcc-8.2.1-1.4/install/win64/arm-none-eabi-gcc/arm-none-eabi --with-multilib-list=rmprofile --disable-rpath --disable-build-format-warnings --with-system-zlib
Thread model: single
gcc version 8.2.1 20181213 (release) [gcc-8-branch revision 267074] (GNU MCU Eclipse ARM Embedded GCC, 64-bit)
COLLECT_GCC_OPTIONS='-o' '.pio\build\LPC1769\src\driver.o' '-c' '-Os' '-ffunction-sections' '-fdata-sections' '-Wall' '-mthumb' '-nostdlib' '-mcpu=cortex-m3' '-v' '-D' 'F_CPU=96000000L' '-D' 'PLATFORMIO=50003' '-D' 'CHIP_LPC175X_6X' '-D' 'CORE_M3' '-D' '__LPC17XX__' '-D' '__USE_CMSIS=CMSIS_CORE_LPC17xx' '-I' 'include' '-I' 'src' '-I' 'src\sdcard' '-I' 'src\grbl-lpc' '-I' 'src\grbl' '-I' '.pio\libdeps\LPC1769\usbd' '-I' '.pio\libdeps\LPC1769\inc' '-I' 'src\lpc17xx' '-I' 'src\FatFs' '-I' 'externals\lpc_chip_175x_6x\inc' '-I' 'externals\lpc_chip_175x_6x\inc\usbd' '-mfloat-abi=soft' '-march=armv7-m'
 c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../libexec/gcc/arm-none-eabi/8.2.1/cc1.exe -quiet -v -I include -I src -I src\sdcard -I src\grbl-lpc 
-I src\grbl -I .pio\libdeps\LPC1769\usbd -I .pio\libdeps\LPC1769\inc -I src\lpc17xx -I src\FatFs -I externals\lpc_chip_175x_6x\inc -I externals\lpc_chip_175x_6x\inc\usbd -imultilib thumb/v7-m/nofp -iprefix c:\users\denkijin\.platformio\packages\toolchain-gccarmnoneeabi@1.80201.190214\bin\../lib/gcc/arm-none-eabi/8.2.1/ -isysroot c:\users\denkijin\.platformio\packages\toolchain-gccarmnoneeabi@1.80201.190214\bin\../arm-none-eabi -D__USES_INITFINI__ -D F_CPU=96000000L -D PLATFORMIO=50003 -D CHIP_LPC175X_6X -D CORE_M3 -D __LPC17XX__ -D __USE_CMSIS=CMSIS_CORE_LPC17xx src\driver.c -quiet -dumpbase driver.c -mthumb -mcpu=cortex-m3 -mfloat-abi=soft -march=armv7-m -auxbase-strip .pio\build\LPC1769\src\driver.o -Os -Wall -version -ffunction-sections -fdata-sections -o C:\Users\denkijin\AppData\Local\Temp\ccWR6Kdz.s

here is the failure

c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: .pio\build\LPC1769\src\driver.o: 
in function `settings_changed':
driver.c:(.text.settings_changed+0xe): undefined reference to `Chip_Clock_GetPCLKDiv'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: driver.c:(.text.settings_changed+0x2dc): undefined reference to `SystemCoreClock'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: .pio\build\LPC1769\src\driver.o: 
in function `driver_setup':
driver.c:(.text.driver_setup+0x50): undefined reference to `Chip_Clock_GetPCLKDiv'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: driver.c:(.text.driver_setup+0x94): undefined reference to `Chip_TIMER_Init'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: driver.c:(.text.driver_setup+0xaa): undefined reference to `Chip_Clock_GetPCLKDiv'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: driver.c:(.text.driver_setup+0xe6): undefined reference to `sdcard_init'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: driver.c:(.text.driver_setup+0x16c): undefined reference to `SystemCoreClock'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: .pio\build\LPC1769\src\driver.o: 
in function `driver_init':
driver.c:(.text.driver_init+0x2): undefined reference to `SystemCoreClockUpdate'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: driver.c:(.text.driver_init+0x6): undefined reference to `Chip_SetupXtalClocking'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: driver.c:(.text.driver_init+0x1c): undefined reference to `SystemCoreClockUpdate'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: driver.c:(.text.driver_init+0x22): undefined reference to `Chip_Clock_EnablePeriphClock'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: driver.c:(.text.driver_init+0x28): undefined reference to `Chip_Clock_EnablePeriphClock'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: driver.c:(.text.driver_init+0x64): undefined reference to `Chip_Clock_GetPCLKDiv'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: driver.c:(.text.driver_init+0x128): undefined reference to `SystemCoreClock'

EDIT: void SystemCoreClockUpdate(void); is in chip.h which shows up in the platformio deps folder!

c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: .pio\build\LPC1769\src\eeprom.o: 
in function `I2C_EEPROM.constprop.0':
eeprom.c:(.text.I2C_EEPROM.constprop.0+0x42): undefined reference to `Chip_I2C_MasterTransfer'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: .pio\build\LPC1769\src\eeprom.o: 
in function `eepromInit':
eeprom.c:(.text.eepromInit+0xc): undefined reference to `Chip_IOCON_PinMuxSet'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: eeprom.c:(.text.eepromInit+0x18): undefined reference to `Chip_IOCON_PinMuxSet'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: eeprom.c:(.text.eepromInit+0x2e): undefined reference to `Chip_I2C_Init'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: eeprom.c:(.text.eepromInit+0x36): undefined reference to `Chip_I2C_SetClockRate'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: eeprom.c:(.text.eepromInit+0x50): undefined reference to `Chip_I2C_EventHandlerPolling'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: eeprom.c:(.text.eepromInit+0x42): undefined reference to `Chip_I2C_SetMasterEventHandler'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: .pio\build\LPC1769\src\serial.o: 
in function `serialInit':
serial.c:(.text.serialInit+0xa): undefined reference to `Chip_IOCON_SetPinMuxing'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: serial.c:(.text.serialInit+0x10): undefined reference to `Chip_UART_Init'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: serial.c:(.text.serialInit+0x1a): undefined reference to `Chip_UART_SetBaud'
c:/users/denkijin/.platformio/packages/toolchain-gccarmnoneeabi@1.80201.190214/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: serial.c:(.text.serialInit+0x28): undefined reference to `Chip_UART_TXEnable'
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\LPC1769\firmware.elf] Error 1

[raininja]

so the environment knows where the symbol is as you can see in the frame center right

[terjeio]

I have some code changes for the LPC176x driver nearly ready - among them moving the library code and the USB blob into the main project. No more external dependencies. That could help?

TMC2209 support via a plugin is on my todo list, will look into that when I get my Nucleo-64 breakout board. It should not be too hard to add driver level code for UART communication to the LPC176x when that is done.

[zmrdko]

@terjeio Thanks for your effort! Since you mentioned nucleo board, I have come across GRBL Advanced version of GRBL, which works on STM32 F411RE/F446RE boards. And I am wondering, if you could point out in what aspects is your grblHAL better. I understand the grblHAL is made for wide range of boards/chips.

Its awesome, that with SKR turbo board and grblHAL you can make high performance CNC controller for cheap. I appreciate that a lot!

Thanks!!

[terjeio]

And I am wondering, if you could point out in what aspects is your grblHAL better.

Hard to tell, that depends on your requirements. For many an 8-bit controller with legacy grbl will work just fine...

IMO the main difference bewteen grblHAL and other ports is the architecture. The grblHAL core is completely hardware agnostic and shared beteween all the supported processors. A central part of that is using function pointers extensively to "hook" in code to make everything work. In addition to the basic stuff handled by a processor specific driver it is possible to add functionality, also user provided, without changing much code. Extending grblHAL is thus fairly easy as the different plugins available shows.

grblHAL has a larger set of g-code commands implemented too, but perhaps not something most users would need. Oh, and many compile time options has been moved to $-settings making grblHAL easier to configure.

[phil-barrett]

Adding to Terje's comments.

Moving things to run-time configuration is hugely beneficial to the average user. The ability to configure input switches ($14) is a perfect example.

While a lot of people tune out when they hear the word "architecture", the benefits are hard to overstate. With the driver approach, new processors, especially in the same family, can be easily added. The move from F103 to F411 took a couple of days. Plugins come along for the ride. This means that as new processors become available, grblHAL can be there quickly. One of the things that made grbl classic (aka legacy grbl aka gnea/grbl) so successful was that it wasn't locked to a specific board design. grblHAL's architecture extends that concept. For the user that has a specific board, that may not matter much. They just care that their board is supported.

And while I am at it, I posit that the Nucleo board is not the mass market vehicle for any flavor of grbl. It is fine for us early adopters but getting CNC machine builders to move beyond grbl classic is going to take a more consumer oriented product.

[zmrdko]

@terjeio thanks for explaining - I can understand now and I agree. I would like to ask, if its possible to make TMC5160 drivers to work (they require SPI interface). I think it would be beneficial for many people, because these stepper drivers are powerful and affordable. I got 5pcs for $50.

[terjeio]

I would like to ask, if its possible to make TMC5160 drivers to work

It is - I am currently working on TMC2130 support, initial version for the SKR boards is already uploaded to the test branch. If TMC5160 is similar to TMC2130 protocol wise then adding that should not be too much work.

[zmrdko]

Thats great! I have SKR 1.4 turbo and TMC5160 drivers and I am down to help with testing. Let me know if I can help with something. I can get some 2130 for testing as well.

[terjeio]

I have a SKR v1.3 on loan so can test TMC2130 myself - if you can test TMC5160 when I have code ready that would be nice.

I am porting the old (WinForm) code for the ioSender Trinamic tuner tab to WPF, when this is done I then I'll consider adding TMC5160 support.

[terjeio]

Test brach updated with initial TMC5160 support for SKR v1.x - with a lot of luck basic funtionality should work. Note that I have not tested the code at all, only that it compiles.

[zmrdko]

@terjeio I have compiled from test branch, but the board is not being detected now. Maybe I did something wrong - can you please provide bin file for LPC1769? Thanks

[terjeio]

Oops, my bad. I forgot to enable the SPI driver for TMC5160, I have just updated the test branch with a fix.

You can also find a bootloader .bin-file and an updated ioSender here. Plugin documentation has also been updated with some useful information.

After enabling driver(s) you can check if they respond by issuing a M122 from a terminal. If status registers at the end of this report are all FF or 00 then communication is not working.

[zmrdko]

I can connect now, but i am getting error 9 (G-code lock). When I try reset and unlock I get error 18.

i have connected 3 tmc5160, 3 stepper motors and 3 endstops.

[terjeio]

Error 18 is reset pin asserted. Grounding it or inverting it helps?

[zmrdko]

Oh I forgot. we went through this before. Sorry. Its unlocked now, but it says:

M122 error:20 (Unsupported command)

[terjeio]

What is in your $I output?

[zmrdko]

$I [VER:1.1f.20210103:] [OPT:VNMSL,35,1024,3,0] [NEWOPT:ENUMS,RT+,TC] [FIRMWARE:grblHAL] [NVS STORAGE:*FLASH] [DRIVER:LCP1769] [DRIVER VERSION:201216] [BOARD:BTT SKR V1.4 Turbo] [PLUGIN:TMC5160 v0.01] ok

[terjeio]

Ok, good. Have you enabled drivers with $338? Try with $338=1 to enable X-axis as a start .

[zmrdko]

Set $338=1 and now M122 says: [TRINAMIC] but X axis is not moving

its moving in cncjs, but not in real life

[terjeio]

M122 only says [TRINAMIC]?

Here is what I get with no motor connected:

[TRINAMIC]
                      X
Set current         500
RMS current         979
Peak current       1384
Run current       31/31
Hold current      15/31
CS actual         31/31
vsense          1=0.180
stealthChop        true
msteps                0
tstep           1048575
pwm
threshold             0
[mm/s]                -
OT prewarn         true
OT prewarn has
been triggered     true
off time             15
blank time            3
hysteresis
-end                 12
-start                8
Stallguard thrs       0
DRIVER STATUS:
stallguard
sg_result          1023
stst                  *
fsactive              *
olb                   *
ola                   *
s2gb                  *
s2ga                  *
otpw                  *
ot                    *
STATUS REGISTERS:
 X = 0xFF:FF:FF:FF
ok

[zmrdko]

What do you use to interface with grbl?

[zmrdko]

Looks like M122 causes my connection to hang and freeze. Terminal would not respond after M122. What is more, I am not able to reconnect to COM port, I have to physically disconnect the board an then it responds until M122 again.

[terjeio]

New version uploaded, I hope this is better.

I have had some strange issues with the SKR board, SPI comms with the X-axis does not work reliably and X-enable is always low, Y-axis seems to be ok. I have not tested Z. This with TMC2130.

I have found some minor issues when working on this, will commit changes to the test branch later.

[zmrdko]

Now with your new bin i get: Unknown USB Device (Device Descriptor Request Failed)

[terjeio]

I just uploaded another one, I had a hang with the bootloader version earlier when enabling pullup for the MISO pin.

[zmrdko]

Alrighty, we have stats now:

M122 [TRINAMIC] X Set current 500 RMS current 979 Peak current 1384 Run current 31/31 Hold current 15/31 CS actual 31/31 vsense 1=0.180 stealthChop true msteps 0 tstep 1048575 pwm threshold 0 [mm/s] - OT prewarn true OT prewarn has been triggered true off time 15 blank time 3 hysteresis -end 12 -start 8 Stallguard thrs 0 DRIVER STATUS: stallguard sg_result 1023 stst fsactive olb ola s2gb s2ga otpw ot STATUS REGISTERS: X = 0xFF:FF:FF:FF ok

but no movement

[terjeio]

STATUS REGISTERS:
X = 0xFF:FF:FF:FF

0xFF:FF:FF:FF means no response (as does 0x00:00:00:00), can you enable and check the other axes? Do you have a scope or logic analyzer available?

I am wondering if the bootloader leaves pin states in a mess. My code is assuming bootup state. I just checked the X-enable pin and X-driver comms when flashing via J-link and everything is working now it seems.

[terjeio]

Have you moved/added jumpers for SPI comms? Drivers are configured for SPI mode (if that is an option)?

[zmrdko]

Yes they are in SPI mode. I have st link v2 available and multimeter if that helps.

[terjeio]

Programming with ST-link/NXP IDE is preferable - then it will be possible to debug. Multimeter is not of much help.

Did you test without the drivers inserted or no motor power? Then 0xFFFFFFFF is the expected driver status response. If you ground the MISO pin with no drivers then the response should change to 0x00000000.

I can see signals on SCK, CS and MOSI when compiling with TMC5160 enabed, and I get the correct response when I ground the MISO pin - so IMO you should be able to get something back from the drivers...

[zmrdko]

Programming with ST-link/NXP IDE is preferable - then it will be possible to debug. Multimeter is not of much help.

If you tell me what to do, I can try.

Did you test without the drivers inserted or no motor power? Then 0xFFFFFFFF is the expected driver status response. If you ground the MISO pin with no drivers then the response should change to 0x00000000.

When grounded: STATUS REGISTERS: X = 0x00:00:00:00

I can see signals on SCK, CS and MOSI when compiling with TMC5160 enabed, and I get the correct response when I ground the MISO pin - so IMO you should be able to get something back from the drivers...

Powered on and drivers in.

STATUS REGISTERS: X = 0xFF:FF:FF:FF

[terjeio]

Ok, thanks. This means that the MISO pin is read. The multimeter can be of use when debugging - this to check the chip select (CS) signals when stopped at a breakpoint. I'll commit the latest changes to the test branch for that. Tomorrow? It is late here.

[zmrdko]

Alright! Tomorrow. GN

[terjeio]

The test branch has been updated. First ting to try is to remove all drivers and short MOSI and MISO for one (they are connected in parallell). Then edit btt_skr_1.x.c:

Change #define spi_get_byte() sw_spi_xfer(0) to #define spi_get_byte() sw_spi_xfer(0x55)

A M122 will now report driver status as 0x55555555 if the MOSI signal is correct.

I this is correct then revert the edit and set breakpoints at line 58 and 60 to check the chip select (CS) lines. Set the breakponts after the controller has started, and issue M122, or rather M911 as M122 reads four registers per motor, M911 reads only one.

https://github.com/terjeio/grblHAL/blob/f1c2390a2692965faef3289e5197558e332296d1/drivers/LPC1769/src/btt_skr_1.x.c#L54-L61

When a breakpoint is hit hover over the axis variable in line 58 to see which motor is selected. When stopped at line 58 the corresponding CS line should be 3.3V, at line 60 0V. axis value for X is 0, Y is 1...

[zmrdko]

@terjeio can you please hit me on discord? username zmrdko531

[zmrdko]

I have successfully imported new test branch and compiled bin.

did you mean to short MISO and MOSI like this?

[zmrdko]

with compiled bin, windows does not show the board (not even unknown hardware)

[terjeio]

can you please hit me on discord

Never used that - I am on skype and Teams, at least I have used Teams for meetings I have been invited to

did you mean to short MISO and MOSI like this?

Yes - I think so. I shorted jumper pins for E1.

with compiled bin, windows does not show the board (not even unknown hardware)

Did you compile the debug version?

[zmrdko]

@terjeio I wrote you on skype

[danielzanco]

Hello! How its going this proyect. I have an skr 1.3 and tmc2130, it is safe to try? Or is better to not bothe at this time?. I think this is a game changer if it works.

[terjeio]

How its going this proyect.

I guess I will upload a new version to the test branch today. Tests with skr1.3 and TMC5160 completed an hour ago, TMC2130 tested with a different driver but both share the same plugin code so that should work too.

I have not completed/verified sensorless homing as I do not have a machine available for that.

[terjeio]

The test branch has now been updated. TMC2130 or TMC5160 drivers can now be enabled for the SKR v1.3 and v1.4 boards. Note that v1.4 has not been tested by me.

I will upload an update for ioSender as well, this has improved Trinamic support. This may take a few days.

[danielzanco]

Thanks, I will try to test it in the week, I will tell you.