Marlin: [2.0.x] [FR] Implement SPI in a Library format for LPC HAL

[psavva]

Dear Marlin Team,

I would like to request support for the TMC2130 drivers, which is implemented by @teemuatlut on his Marlin branch.

To do so, we need to have a SPI Library for the LPC MCU.

The include should work as per the other SPI Libraries, and must follow the same interface as the SPI libraries for AVR/Due/Teensy.

Once done, we would hopefully wait for a pull request from @teemuatlut on the TMC implementation using the SPI Interface

[tcm0116]

If the TMC2130 driver utilizes the Arduino TwoWire class to perform the SPI communications, then the TwoWire class I wrote in the LPC1768 HAL in my branch just might do the trick.

https://github.com/tcm0116/Marlin/tree/2.0.x-TwoWire

[teemuatlut]

No it uses the standard SPI library that is included with many of the Arduino framework compatible cores.
Also the TMC library cannot use the functions that are inside Marlin only. Thus the need for an SPI library.

[Bob-the-Kuhn]

I've written a cheap & dirty SPI.h for the LPC1768 but Platformio won't connect to the https://github.com/teemuatlut/TMC2130Stepper.git library.

When compiling for the Arduino boards we can connect properly to the https://github.com/teemuatlut/TMC2130Stepper.git library.

I've seen this before with the ARM tool chain in Platformio. The GIT method of providing a library just doesn't work. The only method I'm aware of that works is to register the TMC2130Stepper library within Platformio.

@teemuatlut - can you register your TMC2130Stepper library?

It's a fairly straight forward process. My only stumbling point when I did it was providing the proper link to the library.json file. You can use https://github.com/MarlinFirmware/U8glib-HAL as an example. To register this library I entered the following command in a Platformio terminal window:
platformio lib register https://raw.githubusercontent.com/MarlinFirmware/U8glib-HAL/master/library.json

The following are links to creating & registering a library.
http://docs.platformio.org/en/latest/librarymanager/creating.html
http://docs.platformio.org/en/latest/userguide/lib/cmd_register.html

[teemuatlut]

I don't understand why I'd need to register when the PIO library manager already finds my lib.
This is maybe my 20th time trying the PlatformIO IDE (or Atom) and it seems to just get worse and worse every time. Constant restarts, lockups and error messages.

Teensy35 finds the library and builds OK. It's not the ARM toolchain.
The reason the LPC1768 platform can't find the TMC2130Stepper library is because the library dependency is given as a git link. And I really don't have any idea why it's been given like that in the first place. Add the dependency and it'll work:

[env:LPC1768]
lib_deps        = CMSIS-LPC1768
  U8glib-HAL
  TMC2130Stepper
  Or maybe just add ${common.lib_deps}   ?

Or at least you'll get to the next problem...

[psavva]

I find fully deleting Atom and reinstalling does the trick for me. We really should find a user friendly alternative to PlatformIO

[Bob-the-Kuhn]

Yes, PlatformIO has it's fair share of "quirks".

@teemuatlut - thanks for pointing me to TMC2130Stepper. That's exactly what was needed.

Now to work through all my logic errors and compile errors.

[tcm0116]

I did some messing around, and I got the TMC2130Stepper library to compile with Marlin 2.0. Here's a link to my branch if anyone wants to see what I did:

https://github.com/tcm0116/Marlin/tree/2.0.x-tmc2130

I did have to modify TMC2130Stepper.h from the TMC2130Stepper library in order to get it to compile:

- //#if defined(ARDUINO) && ARDUINO >= 100
  #include <Arduino.h>
- //#endif

Please note that I didn't test anything as I don't have any TMC2130 steppers. However, I was curious to see if I could get it to compile. Maybe someone can take this and see if it works.

[Bob-the-Kuhn]

Here's another attempt at providing a functional LPC1768 TMC2130. Definitely not ready for prime time.
https://www.dropbox.com/s/p7xkwxzpvoxma5v/TMC2130%202017-11-09.zip?dl=0

It uses a soft SPI. You can set the SCK, MOSI & MISO pins in the file LPC1768_TMC2130.cpp.

I did verify that the SPI pins wiggle appropriately. Looks like it sends a 6F 00 00 00 00 every 5 seconds. The SPI runs about 1.2-1.3MHz.

I also had to modify the TMC2130 library. I used SPI.h to get all the needed items linked/defined. Unfortunately the LPC1768 SPI.h gets included in lots of places so I initially had lots of "TMC2310 SPI duplicate definition" errors. To get around that I added a define to TMC2130Stepper.cpp.

7    #else
+      #define INSIDE_TMC2130STEPPER_CPP
8      #include <SPI.h>

I also couldn't test it because I don't have a TMC2130.

It would be nice if this one could also be tested.

---

@teemuatlut - looks like there needs to be a change to the TMC2130 library to allow the non-Arduino systems to hook in. Suggestions?

[Bob-the-Kuhn]

@tcm0116 - I couldn't get your branch to compile for the LPC1768 even after I applied a few of the fixes from my work.

I didn't find a file Arduino.h in your branch. The closest I found was the lower case "a" one in HAL_LPC1768/include. Perhaps you had a custom one that filled in all the missing items?

[tcm0116]

@Bob-the-Kuhn hmmm. I renamed arduino.h to Arduino.h and updated my branch, but I don't think that'll fix it. I wonder if it's because I have the Arduino IDE installed on my Mac and PlatformIO is somehow finding Arduino.h from there...

[tig33r]

Here's another attempt at providing a functional LPC1768 TMC2130. Definitely not ready for prime time.
https://www.dropbox.com/s/p7xkwxzpvoxma5v/TMC2130%202017-11-09.zip?dl=0

Excuse me @Bob-the-Kuhn for stupid question but how to compile it? There is not platformio.ini file...

I can't compile @tcm0116 fork 2.0.x-tmc2130 too.

[psavva]

Hi @tig33t. I can see the platformio.ini file... It's there.. It's in the root folder.

[tig33r]

LOL my archive wasn't download completely. I'm kinda retard cause I didn't notice that.

[psavva]

I'm also busy downloading it now on my laptop to try and compile :)
I'll make a separate branch for this on my account.

My drivers don't have the headers on them yet, so I'll have to solder the headers on in December (going to Mexico for another 2 weeks)

[psavva]

@Bob-the-Kuhn , I tried compiling the branch you supplied, I get this error:

.
.
.
platformio.ini
README.md
You can focus the GitHub tab with Ctrl+8
58.5 s
platformio run --environment LPC1768
void SilentStepStick2130(uint16_t mA);
^~~~~~~~
compilation terminated due to -fmax-errors=5.
In file included from .piolibdeps\TMC2130Stepper\src\source\TMC2130Stepper_CHOPCONF.cpp:1:0:
.piolibdeps\TMC2130Stepper\src/TMC2130Stepper.h:10:7: error: 'uint32_t' does not name a type
const uint32_t TMC2130Stepper_version = 0x10100; // v1.1.0
^~~~~~~~

.piolibdeps\TMC2130Stepper\src/TMC2130Stepper.h:14:26: error: expected ')' before 'pinEN'
TMC2130Stepper(uint8_t pinEN, uint8_t pinDIR, uint8_t pinStep, uint8_t pinCS);
^~~~~
.piolibdeps\TMC2130Stepper\src/TMC2130Stepper.h:17:20: error: 'uint16_t' has not been declared
void rms_current(uint16_t mA, float multiplier=0.5, float RS=0.11);
^~~~~~~~
.piolibdeps\TMC2130Stepper\src/TMC2130Stepper.h:18:3: error: 'uint16_t' does not name a type
uint16_t rms_current();
^~~~~~~~
.piolibdeps\TMC2130Stepper\src/TMC2130Stepper.h:19:28: error: 'uint16_t' has not been declared
void SilentStepStick2130(uint16_t mA);
^~~~~~~~
compilation terminated due to -fmax-errors=5.
Linter
Severity    Provider    Description Line 
PIO Build (LPC1768)
git+
TMC2130_LPC1768161 files

[psavva]

Maybe this will help resolve some of the compile issues we see?
https://github.com/MarlinFirmware/Marlin/pull/8452

[thinkyhead]

//#if defined(ARDUINO) && ARDUINO >= 100

I think we can probably lose that at this point in history. Marlin won't even try to build on Arduino before version 1.6.8. There might be better ways to query the build environment now too. (#if PLATFORMIO?)

because I have the Arduino IDE installed on my Mac and PlatformIO is somehow finding Arduino.h

PlatformIO will only look where you tell it to. As far as I know it doesn't include any "provisional" search paths (such as the default Arduino Sketchbook folder). I don't use PlatformIO from within Atom, but only from within Sublime Text 3 (via Deviot), and PlatformIO definitely lives within its own sandbox under that arrangement.

[tcm0116]

PlatformIO will only look where you tell it to.

What's strange is that PIO will include files in Marlin when compiling external libraries. In my experience, libraries are usually compiled in their own sandbox with their open dependencies, and then the dependent project will then use the artifacts provided by the library. In this case, the dependency can depend on the dependent, which makes my brain hurt.

[psavva]

Any suggestions on how to fix the compilation on PlatformIO, I would like to test, and give Bob feedback if/how it works out

[tig33r]

Are latest changes #8464 in bugfix2.0 enough for proper tmc2130 work?

[psavva]

They is how Bob had it in the dropbox link. Ie, removed the git link and instead included only the TMC Library, similar so to what is done... It seems the TMC Library it's still expecting the header from Arduino, which doesn't seem to work...

Can someone else try to compile using PlatformIO to confirm this behaviour?

[tcm0116]

@tig33r #8464 only fixes compilation for AVR in PIO. Per my comments in
that PR, pretty much none of the external dependencies will compile on
LPC1768 due to their dependencies on Arduino.h.

[tig33r]

Regarding @Bob-the-Kuhn last files I have exactly same error as @psavva

I dont know is it matters but in TMC2130Stepper.h in two first lines teemault probably have mismatched definitions, should be TMC2130Stepper_h instead TMC2310Stepper_h

[teemuatlut]

I dont know is it matters but in TMC2130Stepper.h in two first lines teemault probably have mismatched definitions, should be TMC2130Stepper_h instead TMC2310Stepper_h

Yeah that's a typo but it doesn't really affect anything as it's only an include guard.

[Bob-the-Kuhn]

I was able to re-produce the compile error. It is caused by using the standard TMC2130 library rather than the modified one that was in the dropbox link.

Here's a ZIP with all the modified & new files.
The two LPCxx ones go into the HAL_LPC1768 directory
SPI.h goes into the HAL directory
The TMCxx ones replace the ones in the library.

Don't forget to do a clean after modifying the library. PlatformIO won't pick up the changes until after a clean is done.

LPC1768_TMC2130.zip

[tig33r]

Now firmware is compiling successfully and motors are working however I didn't print anything yet.

My settings:

in lpc1768_tmc2130.cpp:

  #define TMC2130_SCK_PIN P2_12
  #define TMC2130_MISO_PIN P4_28
  #define TMC2130_MOSI_PIN P1_23
  #define TMC2130_CS P2_11
  #define TMC2130_CS_ACTIVE HIGH

added #define X_CS_PIN P2_11 in pins_mks_sbase.h

defined HAVE_TMC2130 and X_IS_TMC2130 in Configuration_adv.h

cable connections:

SDO -> p4_28
CS -> p2_11
SCK -> p2_12
SOI -> p1_23

As i have hypercube evolution (corexy) cables for both stepsticks are connected to same motherboard's pins.

[psavva]

I'll be back home after a 2 week visit to Mexico.
I'll start testing this again when I get back.

[psavva]

I managed to finally solder the headers. Hope this looks ok. I'm planning to test it asap with the changes by Bob-the-Kuhn.

@Bob-the-Kuhn
If it works, what do you need to get it mainstream?

[tig33r]

Try tcm build

[teemuatlut]

Maybe now is a good time to tell that I've got a solution of my own that I like more but differs a bit from the one given here. But it's on my other computer and I won't be able to upload it until Wednesday.

[Bob-the-Kuhn]

@psavva - see issue #8334. Looks like tcm0116's comment on Nov 9 will work with the current TMC2130.

[tig33r]

Tried his branch and it is compiling succesfull but motors does not work.

[psavva]

Ok then.. :). I guess I'll have to wait until Wednesday. I'm looking forward to it.

[psavva]

Thanks @teemuatlut

[vilsed]

Hello.

I'm getting compile errors using Bob-the-Kuhns TMC2130 library patches.

What gives?

`Compiling .pioenvs\LPC1768\lib\TMC2130Stepper_ID1493\source\TMC2130Stepper_GCONF.o
.piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper_COOLCONF.cpp:16:6: error: prototype for 'void TMC2130Stepper::sgt(int8_t)' does
not match any in class 'TMC2130Stepper'
void TMC2130Stepper::sgt( int8_t B ) { MOD_REG(COOLCONF, SGT); }
^~~~~~
In file included from .piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper_COOLCONF.cpp:1:0:
.piolibdeps\TMC2130Stepper_ID1493\src/TMC2130Stepper.h:167:11: error: candidates are: uint8_t TMC2130Stepper::sgt()

uint8_t sgt();
^~~
.piolibdeps\TMC2130Stepper_ID1493\src/TMC2130Stepper.h:160:8: error: void TMC2130Stepper::sgt(uint8_t)
void sgt( uint8_t B);
^~~
.piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper_COOLCONF.cpp:27:8: error: prototype for 'int8_t TMC2130Stepper::sgt()' does not
match any in class 'TMC2130Stepper'
int8_t TMC2130Stepper::sgt() {
^~~~
In file included from .piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper_COOLCONF.cpp:1:0:
.piolibdeps\TMC2130Stepper_ID1493\src/TMC2130Stepper.h:167:11: error: candidates are: uint8_t TMC2130Stepper::sgt()
uint8_t sgt();
^
compilation terminated due to -fmax-errors=5.
* [.pioenvs\LPC1768\lib\TMC2130Stepper_ID1493\source\TMC2130Stepper_COOLCONF.o] Error 1
[ERROR] Took 281.17 seconds`

[teemuatlut]

https://github.com/MarlinFirmware/Marlin/compare/bugfix-2.0.x...teemuatlut:LPC_TMC2130

Basically all it does is redirect calls to the class member functions to the ones we already have.
I'd rather not see multiple implementations of SPI communication for a platform. I also think the actual implementations should live in the class, contrary to how it is on my branch here. Further, I think the whole SPI implementation should be moved to frameworks/CMSIS/LPC1768/lib/, assuming that files inside aren't compiled for other platforms. This would get us quite close to an actual SPI library for LPC. But the LPC HAL isn't my main focus so I don't want to mess with it too much alone.

[vilsed]

Still getting the same compile errors...

[psavva]

I'll compile it tonight to see if i can replicate your issue.

On Thu, 28 Dec 2017, 12:03 vilsed, [e-mail] wrote:

Still getting the same compile errors...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/8334#issuecomment-354263121,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABYypkJuiquY16e1Zy8NNXj93ym19KfKks5tE2dpgaJpZM4QWzGh
.

[vilsed]

Thank you. Will be waiting for feedback

[psavva]

@teemuatlut

I had enabled

define HAVE_TMCDRIVER

as well as

define HAVE_TMC2130

together with X stepper driver for both...

I have several issues when trying to compile:
1) TMC26XX is not included in the dependencies for the LPC Build in PlatformIO, which it is referenced in stepper_indirection.cpp
I have have included:
https://github.com/trinamic/TMC26XStepper.git

2) Upon including the TMC26XX library, I had an issue where "boolean" was not recognised, so I changed that all to "bool" instead in the TMC26XX library.

3) Upon the change of boolean -> bool, I again faced compile issues due to the setCurrent function signature not matching in the library vs the implementation.
ie: in TMC26XStepper.cpp, it's defined as:
void TMC26XStepper::setCurrent(unsigned int current)
in the implementation it's called like this: setCurrent(st.getCurrent(), R_SENSE, HOLD_MULTIPLIER)

I'm sure that the wrong setCurrent is being used here, as it should have been that of your library, and not of the TMC26XX library. Hence: the definition in your library:
void TMC2130Stepper::setCurrent(uint16_t mA, float R, float multiplier)

It became apparent that I should NOT enable both HAVE_TMCDRIVER if i'm using the TMC2130 Driver...
I simply undid all my changes above, and only enabled the TMC2130 Driver (with HAVE_TMCDRIVER).

I was able to Compile Successfully after this....

I think a Sanity Check is in order here :) We should not enable both libraries...

@vilsed , Please Advise on your configuration, and steps you are taking to compile this for the LPC1768?

As I am able to compile @teemuatlut branch just fine, I would expect your would be able to do so too...
Some Notes:
in configuration.h you must change the Motherboard:
#define MOTHERBOARD BOARD_RAMPS_14_RE_ARM_EFB

Don't Forget the EFB Part at the end, some sanity checks only say you must select BOARD_RAMPS_14_RE_ARM which is not entirely correct, if you try to compile with PlatformIO, without changing the MB.

in configuration_adv.h, you must change only #define HAVE_TMC2130, together with the the axis you are using: Example: #define X_IS_TMC2130

and Compile in PlatformIO using the PIO Build(LPC1768) at the bottom left hand corner.
Note: Don't bother using the build button, as you will notice it picks up the mega board instead!

[tig33r]

Is stepper working good? I compiled succesfully but motors did not work. Mks sbase here with spi on J8 connector.

[psavva]

I'll have to test it tomorrow. I still need to build my harness to try...

On Thu, 28 Dec 2017, 23:37 tig33r, [e-mail] wrote:

Is stepper working good? I compiled succesfully but motors did not work.
Mks sbase here with spi on J8 connector.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/8334#issuecomment-354361747,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABYypkE5b3gAis8qPYOqnfC47wkIP-pGks5tFAoxgaJpZM4QWzGh
.

[vilsed]

@psavva My setup is Re-ARM (LPC1768) with Ramps 1.4 EFB on a delta printer. I'm already past the hurdles of having correct pins definition enabled, I have built 2.0 previously for that board using generic A4988 drivers. Besides getting compile errors while having enabled features like babystepping, filament change and a few others (which I frankly can't remember), and having some weird action going on with SPI in general (poor RRD full graphic controller update rates while printing from SD card), I had the printer up and running. Decided to upgrade to TMC drivers and there comes the problems :)

From the beginning I had enabled only HAVE_TMC2130, so I did not have the errors you mentioned. Although today there were other problems with missing classes in TMC2130Stepper.h (Bob_the_Kuhn updated TMC2130 library, not stock arduino one). Somehow managed to fix all those up and I'm still back at missing classes in TMC2130Stepper.h for TMC2130Stepper_COOLCONF.cpp, as I had in the beginning.

I'm a mechanical engineer by trade, just getting my toes wet with coding now (besides commenting and uncommenting lines in Configuration.h :) ) so please, bear with me :)

Hope to have some time tomorrow to try and compile a fresh copy of teemuatlut branch. I may have messed up something unknowingly...

[psavva]

This is the branch you can test:
https://github.com/teemuatlut/Marlin/tree/LPC_TMC2130?files=1

[vilsed]

PlatformIO updated today, and this branch doesn't compile at all. Although main 2.0 branch does try to compile. At least as much as it did yesterday.

`Error: Traceback (most recent call last):
File "c:\users\vilius.platformio\penv\lib\site-packages\platformio__main__.py", line 120, in main
cli(None, None, None)
File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py", line 700, in __call__
return self.main(args, *kwargs)
File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py", line 680, in main

rv = self.invoke(ctx)

File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py", line 1027, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py", line 873, in invoke
return ctx.invoke(self.callback, *ctx.params)
File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py", line 508, in invoke
return callback(args, *kwargs)
File "c:\users\vilius.platformio\penv\lib\site-packages\click\decorators.py", line 16, in new_func
return f(get_current_context(), *args, *kwargs)
File "c:\users\vilius.platformio\penv\lib\site-packages\platformio\commands\run.py", line 102, in cli
for k, v in config.items(section):
File "c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py", line 53, in items
items.append((option, self.get(section, option)))
File "c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py", line 60, in get
return self.VARTPL_RE.sub(self._re_sub_handler, value)
File "c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py", line 66, in _re_sub_handler
return self.get(section, option)
File "c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py", line 57, in get
value = ConfigParser.get(self, section, option, **kwargs)
File "C:\Users\Vilius.platformio\python27\Lib\ConfigParser.py", line 618, in get
raise NoOptionError(option, section)
NoOptionError: No option 'build_flags' in section: 'common'
`

[psavva]

There is probably some problem with your PlatformIO installation...

Try delete it totally, and reinstall atom and PlatformIO from scratch. I
build the branch just fine. I will test the Re-Arm with the drivers
installed today.

On Fri, 29 Dec 2017, 11:52 vilsed, [e-mail] wrote:

PlatformIO updated today, and this branch doesn't compile at all. Although
main 2.0 branch does try to compile. At least as much as it did yesterday.

`Error: Traceback (most recent call last):
File "c:\users\vilius.platformio\penv\lib\site-packages\platformio_main_.py",
line 120, in main
cli(None, None, None)
File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py",
line 700, in call
return self.main(args, *kwargs)
File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py",
line 680, in main

rv = self.invoke(ctx)

File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py",
line 1027, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py",
line 873, in invoke
return ctx.invoke(self.callback, *ctx.params)
File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py",
line 508, in invoke
return callback(args, *kwargs)
File
"c:\users\vilius.platformio\penv\lib\site-packages\click\decorators.py",
line 16, in new_func
return f(get_current_context(), *args, *kwargs)
File
"c:\users\vilius.platformio\penv\lib\site-packages\platformio\commands\run.py",
line 102, in cli
for k, v in config.items(section):
File
"c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py",
line 53, in items
items.append((option, self.get(section, option)))
File
"c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py",
line 60, in get
return self.VARTPL_RE.sub(self._re_sub_handler, value)
File
"c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py",
line 66, in _re_sub_handler
return self.get(section, option)
File
"c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py",
line 57, in get
value = ConfigParser.get(self, section, option, **kwargs)
File "C:\Users\Vilius.platformio\python27\Lib\ConfigParser.py", line 618,
in get
raise NoOptionError(option, section)
NoOptionError: No option 'build_flags' in section: 'common'
`

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/8334#issuecomment-354423993,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABYypncnqPXAcJ0KSL-FSpRb9fOmOW9lks5tFLZSgaJpZM4QWzGh
.

[vilsed]

Somehow I managed to download a wrong Marlin fork. Figured it out. It compiled successfully, will try uploading to the board this evening.

[psavva]

I am now trying to figure out which pins I should be using on the Ramps board for the SP.

#ifndef SCK_PIN
#define SCK_PIN P0_15
#endif
#ifndef MISO_PIN
#define MISO_PIN P0_17
#endif
#ifndef MOSI_PIN
#define MOSI_PIN P0_18
#endif
#ifndef SS_PIN
#define SS_PIN P1_23
#endif

How do I now figure out which Port/PIN maps to which PIN on the Ramps board?
How do I map this?

[psavva]

I found that Panucatt has the Mapping on their Schematic. I'm using this as a basis.
The current configuration actually maps to the Hardware SPI pins, which is used by the LCD.

I was under the impression that different Pins should be used for the Software SPI, as not to conflict with the LCD SPI?

I think I'm missing something here... Can someone guide me as to how this should be done?

Do I understand correctly on the Re-ARM that the Software SPI will always be used, Ignoring the fact that the hardware SPI is defined on these pins?
Or should I define any new pins for the SPI?

[vilsed]

@psavva I'm currently trying to figure this out too. As I understand, SPI is a parallel interface, so we should be able to use the same pins as LCD is using (0.18, 0.15 and 0.17). Could be wrong though

[psavva]

@vilsed As far as I can tell we will always use Software SPI for the LPC and MKS_SBASE, no matter what...
ie: pins.h -> HAL_spi_pins.h -> HAL_LPC1768/spi_pins.h -> Which contains an if statement, that will always define LPC_SOFTWARE_SPI for the LPC chipset...
Hence that it's not possible to initialize the Hardware SPI for the LCD, and Software SPI on different ports to use with the Stepper Drivers + Others.

I guess something is wrong with the Hardware SPI on the LPC, which is maybe why we always override it with a software SPI?

I think you are right though, We should be able to modify the PIN header on the LCD Adaptor, as to make those pins available for the next SPI modules, such as these TMC Drivers...

I'm really not sure as to why the software spi is always used in this way.. Maybe @Bob-the-Kuhn or @thinkyhead can advise?

[p3p]

The shared SPI on the Re-ARMs controller extension ports would be fine if the RRD Graphical LCD actually followed the SPI specification (it receives data even when not enabled), as it is we do our best to work around the problems (display corruption when accessing sd card) in software but it''s impossible to mitigate entirely. The pins are set up to make sure things mostly work out of the box as it would take a ribbon cable modification to move the lcd to other pins, (with a 20x4 display this is not optional as the extension ports do not have the appropriate pins connected, we had to move those signals to Ethernet pins). Panucatt decided it was more important to reserve pins for Ethernet than to be fully RAMPS compatible more than likely because the design was intended for smoothieware.

[Bob-the-Kuhn]

From the pins_RAMPS_RE_ARM.h file (the RAMPs pin number is a comment)

  //#define MISO_PIN            P0_17  // (50)  system defined J3-10 & AUX-3
  //#define MOSI_PIN            P0_18  // (51)  system defined J3-10 & AUX-3
  //#define SCK_PIN             P0_15  // (52)  system defined J3-9 & AUX-3
  //#define SS_PIN              P1_23  // (53)  system defined J3-5 & AUX-3 - sometimes called SDSS

SPI is a serial interface.

The hardware SPI on the RE-ARM board is normally disabled because the same SPI pins run both the LCD and the SD card on the RepRap Full Graphics board when using the standard LCD adapter. Basically two SPI interfaces are needed. Using only software SPIs means they can use the same pins. The LPC1768 hardware SPI simply doesn't share pins.

[psavva]

@Bob-the-Kuhn the pins will finally be defined in
https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/HAL/HAL_LPC1768/spi_pins.h

If the LCD doesn't respect the fact that if the SS is disabled, it should ignore data, how does it work today on the LPC chipset? I understand that the software SPI will allow us to use multiple SPI devices without the limitations of the LPC Hardware SPI, however, will the LCD still not be corrupted when accessing the SPI on another device?

Should we not have 2 separate SPI interfaces, using different pins? Ie: one for the LCD, and one for everything else?

[vilsed]

I've connected the drivers to the SPI header on the Re-ARM itself. Communication seems to be working (crap on the LCD), although M122 is pushing "X/Y/Z/E current decreased to [lower and lower value]". Before I had "driver error" message on LCD and printer shutdowns immediately after boot. Had to disable #define STOP_ON_ERROR

EDIT: Reported current is in tens of amps, witch could not be right. Also it threw out a couple of over temperature warnings, although drivers are stone cold

EDIT: It appears that just after boot the current is reduced down to 0 and after that it rolls over to 65486 and goes down from there. Motors aren't running. Just humming and spazing periodically. Disabling LDC/SD support and removing LCD adapter did nothing. M122, M906, M911 aren't working.

[Bob-the-Kuhn]

Two separate SPI interfaces is how it's done on a mega2560 board.

The LPC1768 has fewer pins than the 2560. One of the Re-ARM compromises was to combine the SPI pins when using the standard LCD adapter board.

Two separate SPIs could be used on the Re-ARM system but that would require some type of custom cabling or a new LCD adapter board.

I'd dearly love to use the hardware SPI. The RepRap Full Graphics display is finicky about it's baud rate and duty cycle. The hardware SPI would make that so much easier than with a software SPI.

[psavva]

@Bob-the-Kuhn Could we not use the standard cable as it is now, and utilise the hardware SPI for the LCD alone? Or do you mean to say that the hardware SPI cannot be used due to the SD card using the same pins on the RRD Full graphics smart controller, and the LPC SPI simply doesn't support it?

@vilsed could you send us a photo of your cabling ?

[Bob-the-Kuhn]

On the LPC1768 we MINIMIZE the RRDFG's LCD garbage when in the PRINT SD menu by:
1) using the SDCARD_SORT_ALPHA option which keeps a copy of the directory in RAM
2) going to the RAM for directory info when possible
3) redrawing the display immediately after an SD card access.

Sometimes you'll see garbage on power up when the SD card is being accessed.

[vilsed]

@psavva Sure. It's nearly impossible to understand a thing in this mess though. Basically SDO (blue wire), SDI (yellow wire) and SCK (red wire) pins are connected in parallel for all drivers and go to P0.18, P0.17 and P0.15 pins respectively. CS pins go with individual wires to P1.0, P1.1, P1.8 and P1.4, as per pins.h file.

https://photos.app.goo.gl/fGIk2P69jzRm70dx2

[p3p]

@psavva The issue is that there is no centralised interface to SPI, originally I had both the sdcard and lcd running on hardware SPI but it required modification to all areas of marlin that used SPI to redirect through an API in the HAL, this is how it should be done but it isn't easy to implement and maintain the 8bit AVR performance also any library that uses SPI would ignore our interface, so the current design is a compromise that means we can't use the hardware. I really want to find the time to implement the HALs multi-channel SPI interface but its not happening anytime soon I don't think.

[Bob-the-Kuhn]

The RRDFG LCD section ALWAYS responds to the SCK & MOSI pins. That's just the way it is.

If there were an attractive alternative to the standard LCD adapter then switching to the hardware SPI would be the way to go.

As long as the application only uses SPIs for the LCD's display and the LCD's SD card then the current setup is OK. Definitely not elegant.

FYI - the LPC1768's second hardware SPI is dedicated to the Re-ARM's on-board SD card.

[tcm0116]

I've seen people add a buffer between the control board and RRDFGD that
will disconnect the SPI pins to the LCD when the CS is disabled. That could
be an option for someone wanting to share the hardware SPI between the LCD
and other devices, such as the TMC2130 drivers, but it would require some
custom cabling and additional components.

[Bob-the-Kuhn]

@p3p - Chris, in your vision. does the SPI API actually control the select line or does the application?

In some of the U8G LCD drivers they have a start transmission & end transmission message they send to the com driver and the com driver controls the select. I like that system - especially if we ever have visions of an RTOS.

[p3p]

@Bob-the-Kuhn I made it optional as some devices have really odd timing requirements for the cs line, if you manual enabled the cs it had to be manually disabled, otherwise it was done automatically (also with block transmissions it makes sense, with byte not so much), so it acted like a start/end transmission really.

[psavva]

So it means that we will have the exact same problem when transmitting data the TMC drivers. Ie, we'll have garbage on the LCD. There is really no elegant solution other than a custom cable to utilise a second software SPI for the SD card and other peripherals. It however does mean that we would need to be able to define a second set of software SPI pins. It would also mean that each SPI device should be configurable to which SPI to use... Ie: LCD on SPI1, SD Card and TMC on SPI2

[vilsed]

@psavva Yes, that is exactly what is happening. Although all what that garbage is, is two lines on the LCD. Same as it is while reading from an SD card. The whole screen fills with garbage only once, while booting up.

All in all my situation seems very bizarre to me. It seems that the LPC is talking to TMCs (garbage lines on the screen and "current decreased" messages being pumped over COM), but not really. Tomorrow will try to test the setup with an ATmega, I'm starting to suspect bad drivers, although they did work in simple step/dir mode.

As for the overcrowding on SPI bus, I would be willing to give up LCD and SD support, if that meant that TMC drivers worked. At least for now.

[tig33r]

I gave up with tmc controlled by Marlin. Right now I am using arduino nano to control tmc and it working well. In addition I can use it with smoothieware too.

[vilsed]

It's a shame, really. Re-ARM was supposed to be a plug and play replacement for 2560. Guess nothing is ever simple...

EDIT. I might have found my problem. My drivers are configured to work in standalone mode (SPI jumper closed https://github.com/watterott/SilentStepStick/blob/master/hardware/SilentStepStick-TMC2130_v10.pdf), i.e. SPI pins work like simple configuration pins. It's always simple things like that

[psavva]

Here is an interesting read.
https://www.dorkbotpdx.org/blog/paul/better_spi_bus_design_in_3_steps

If any of the electronic engineers know how we can practically solve this issue with a simple fix using a tri-state buffer, please shout out.

I think that it's probably the best solution if there is some small fix on the RRD board itself by implementing the solution as per the article.

[vilsed]

Played around with 2130's a bit. With ATmega they work just fine. M122 gives me all the relevant infos, I can change the drive current and all that. So we can rule out bad drivers/bad wiring harness.

Once more, to summarize my current setup: Re-ARM, RAMPS 1.4, no SD, no LCD (both physically and disabled in marlin), SDO, SDI and SCK lines to P0.18, P0.17 and P0.15 respectively, X_CS, Y_CS, Z_CS and E0_CS to P1.0, P1.1, P1.8 and P1.4. I noticed that these CS pins were being used for ethernet too, although disabling defines for ENET changed nothing.

Anyhow, Happy new year! :)

[psavva]

I tried your exact setup, and cannot get my board to boot once HAVE_TMC2130 is defined.

If I undefined it, all is good and the board boots, of course without the stepper driver...

Once I enable the 2130 define, the LED1 on the Ramps is solid. Not flashing. I cannot access the serial console either...

May I please ask you to zip up your changes to @teemuatlut branch fir the LPC chipset?

[psavva]

After going a little back in history on the comments, I noticed that @vilsed had disabled STOP_ON_ERROR.
After disabling this, I have also managed to avoid the board resetting, but of course since there is some error, there is absolutely no feedback from M122 which is supposed to give me some debug information.

I think it's either some bug with communicating with the SPI, or similar...

My setup is exactly the same as that of @vilsed

Re-ARM, RAMPS 1.4, no SD, no LCD (both physically and disabled in marlin),
SDOP0.18
SDIP0.17
SCK P0.15
X_CS -> P1.0
I only tested this with 1 driver.

@teemuatlut do you think you'd be able to give advise on how to debug, and further understand what may need to be changed to get the TMC2130 working?

Due to the fact that the halt happens even before I'm able to connect via the serial console, I cannot simply see the error.

[psavva]

I disabled the KILL in tmc_util and re-enabled the STOP_ON_KILL in efforts to get the logs :)

@teemuatlut, Hope this helps to figure out what's going on here....

This is the report from the Serial Monitor:
19:22:03.590 : Printer reset detected - initalizing
19:22:03.590 : -start 8
19:22:03.591 : Stallguard thrs 0
19:22:03.591 : DRVSTATUS X
19:22:03.591 : stallguard X
19:22:03.591 : sg_result 1023
19:22:03.591 : fsactive X
19:22:03.591 : stst X
19:22:03.591 : olb X
19:22:03.591 : ola X
19:22:03.591 : s2gb X
19:22:03.591 : s2ga X
19:22:03.591 : otpw X
19:22:03.591 : ot X
19:22:03.591 : Driver registers:
19:22:03.591 : X = 0x1515:1515:1515:1515
19:22:03.591 : X current decreased to 600
19:22:03.597 : X driver error detected:
19:22:03.599 : overtemperature
19:22:03.601 : short to ground (coil A)
19:22:03.601 : short to ground (coil B)
19:22:03.601 : X
19:22:03.603 : Enabled false
19:22:03.605 : Set current 600
19:22:03.605 : RMS current 581
19:22:03.607 : MAX current 819.210000
19:22:03.609 : Run current 18/31
19:22:03.611 : Hold current 9/31
19:22:03.611 : CS actual 31/31
19:22:03.614 : PWM scale 255
19:22:03.614 : vsense 1=.18
19:22:03.616 : stealthChop true
19:22:03.618 : msteps 0
19:22:03.618 : tstep 4294967295
19:22:03.620 : pwm
19:22:03.620 : threshold 98
19:22:03.622 : [mm/s] 0.000000
19:22:03.622 : OT prewarn true
19:22:03.624 : OT prewarn has
19:22:03.624 : been triggered true
19:22:03.624 : off time 15
19:22:03.626 : blank time 54
19:22:03.628 : hysterisis
19:22:03.628 : -end 12
19:22:03.628 : -start 8
19:22:03.631 : Stallguard thrs 0
19:22:03.631 : DRVSTATUS X
19:22:03.633 : stallguard X
19:22:03.633 : sg_result 1023
19:22:03.636 : fsactive X
19:22:03.636 : stst X
19:22:03.636 : olb X
19:22:03.638 : ola X
19:22:03.638 : s2gb X
19:22:03.638 : s2ga X
19:22:03.642 : otpw X
19:22:03.642 : ot X
19:22:03.644 : Driver registers:
19:22:03.646 : X = 0x1515:1515:1515:1515
19:22:03.649 : X current decreased to 550
19:22:03.729 : N1 M11034
19:22:03.729 : N2 M11536
19:22:03.729 : N4 M11435
19:22:03.731 : N5 M111 S698
19:22:03.734 : N6 T060
19:22:03.734 : N7 M2022
19:22:03.735 : ok
19:22:03.737 : N8 M8019
19:22:03.753 : FIRMWARE_NAME:Marlin bugfix-2.0.x (Github) SOURCE_CODE_URL:https://github.com/MarlinFi_XON_XOFF0
19:22:03.754 : N10 M220 S10080
19:22:03.755 : Cap:EEPROM0
19:22:03.755 : Cap:VOLUMETRIC1
19:22:03.759 : Cap:AUTOREPORT_TEMP1
19:22:03.761 : Cap:PROGRESS0
19:22:03.761 : Cap:PRINT_JOB1
19:22:03.763 : Cap:AUTOLEVEL0
19:22:03.763 : Cap:Z_PROBE0
19:22:03.765 : Cap:LEVELING_DATA0
19:22:03.767 : Cap:BUILD_PERCENT0
19:22:03.769 : Cap:SOFTWARE_POWER0
19:22:03.769 : Cap:TOGGLE_LIGHTS0
19:22:03.771 : Cap:CASE_LIGHT_BRIGHTNESS0
19:22:03.774 : Cap:EMERGENCY_PARSER0
19:22:03.774 : ok
19:22:03.774 : N11 M221 S10080
19:22:03.780 : N12 M111 S684
19:22:03.783 : X:0.000000 Y:0.000000 Z:0.000000 E:0.000000 Count X:0 Y:0 Z:0
19:22:03.783 : ok
19:22:03.783 : N13 T0*8
19:22:03.785 : echo:DEBUG:INFO,ERRORS
19:22:03.785 : ok
19:22:03.787 : echo:Active Extruder: 0
19:22:03.787 : ok
19:22:03.787 : ok
19:22:03.787 : ok
19:22:03.794 : ok
19:22:03.794 : ok
19:22:03.794 : echo:DEBUG:INFO,ERRORS
19:22:03.794 : ok
19:22:03.795 : echo:Active Extruder: 0
19:22:03.795 : ok
19:22:04.095 : X driver error detected:
19:22:04.097 : overtemperature
19:22:04.099 : short to ground (coil A)
19:22:04.099 : short to ground (coil B)
19:22:04.099 : X
19:22:04.099 : Enabled false
19:22:04.101 : Set current 550
19:22:04.103 : RMS current 520
19:22:04.106 : MAX current 733.200000
19:22:04.106 : Run current 16/31
19:22:04.108 : Hold current 8/31
19:22:04.111 : CS actual 31/31
19:22:04.111 : PWM scale 255
19:22:04.114 : vsense 1=.18
19:22:04.114 : stealthChop true
19:22:04.115 : msteps 0
19:22:04.115 : tstep 4294967295
19:22:04.117 : pwm
19:22:04.117 : threshold 98
19:22:04.120 : [mm/s] 0.000000
19:22:04.120 : OT prewarn true
19:22:04.122 : OT prewarn has
19:22:04.126 : been triggered true
19:22:04.126 : off time 15
19:22:04.128 : blank time 54
19:22:04.128 : hysterisis
19:22:04.130 : -end 12
19:22:04.130 : -start 8
19:22:04.132 : Stallguard thrs 0
19:22:04.132 : DRVSTATUS X
19:22:04.135 : stallguard X
19:22:04.137 : sg_result 1023
19:22:04.137 : fsactive X
19:22:04.137 : stst X
19:22:04.139 : olb X
19:22:04.139 : ola X
19:22:04.139 : s2gb X
19:22:04.139 : s2ga X
19:22:04.141 : otpw X
19:22:04.141 : ot X
19:22:04.143 : Driver registers:
19:22:04.145 : X = 0x1515:1515:1515:1515
19:22:04.148 : X current decreased to 500
19:22:04.594 : X driver error detected:
19:22:04.596 : overtemperature
19:22:04.599 : short to ground (coil A)
19:22:04.599 : short to ground (coil B)
19:22:04.599 : X
19:22:04.601 : Enabled false
19:22:04.601 : Set current 500
19:22:04.604 : RMS current 489
19:22:04.606 : MAX current 689.490000
19:22:04.608 : Run current 15/31
19:22:04.608 : Hold current 7/31
19:22:04.610 : CS actual 31/31
19:22:04.612 : PWM scale 255
19:22:04.612 : vsense 1=.18
19:22:04.615 : stealthChop true
19:22:04.615 : msteps 0
19:22:04.617 : tstep 4294967295
19:22:04.617 : pwm
19:22:04.617 : threshold 98
19:22:04.622 : [mm/s] 0.000000
19:22:04.624 : OT prewarn true
19:22:04.626 : OT prewarn has
19:22:04.626 : been triggered true
19:22:04.626 : off time 15
19:22:04.628 : blank time 54
19:22:04.631 : hysterisis
19:22:04.631 : -end 12
19:22:04.631 : -start 8
19:22:04.633 : Stallguard thrs 0
19:22:04.633 : DRVSTATUS X
19:22:04.635 : stallguard X
19:22:04.635 : sg_result 1023
19:22:04.637 : fsactive X
19:22:04.637 : stst X
19:22:04.638 : olb X
19:22:04.640 : ola X
19:22:04.640 : s2gb X
19:22:04.640 : s2ga X
19:22:04.642 : otpw X
19:22:04.642 : ot X
19:22:04.644 : Driver registers:
19:22:04.646 : X = 0x1515:1515:1515:1515
19:22:04.648 : X current decreased to 450
19:22:05.095 : X driver error detected:
19:22:05.097 : overtemperature
19:22:05.099 : short to ground (coil A)
19:22:05.100 : short to ground (coil B)
19:22:05.100 : X
19:22:05.100 : Enabled false
19:22:05.102 : Set current 450
19:22:05.104 : RMS current 428
19:22:05.106 : MAX current 603.480000
19:22:05.106 : Run current 13/31
19:22:05.108 : Hold current 6/31
19:22:05.111 : CS actual 31/31
19:22:05.111 : PWM scale 255
19:22:05.113 : vsense 1=.18
19:22:05.113 : stealthChop true
19:22:05.117 : msteps 0
19:22:05.118 : tstep 4294967295
19:22:05.120 : pwm
19:22:05.120 : threshold 98
19:22:05.122 : [mm/s] 0.000000
19:22:05.122 : OT prewarn true
19:22:05.124 : OT prewarn has
19:22:05.124 : been triggered true
19:22:05.124 : off time 15
19:22:05.127 : blank time 54
19:22:05.129 : hysterisis
19:22:05.129 : -end 12
19:22:05.129 : -start 8
19:22:05.129 : Stallguard thrs 0
19:22:05.131 : DRVSTATUS X
19:22:05.131 : stallguard X
19:22:05.133 : sg_result 1023
19:22:05.138 : fsactive X
19:22:05.138 : stst X
19:22:05.138 : olb X
19:22:05.138 : ola X
19:22:05.140 : s2gb X
19:22:05.140 : s2ga X
19:22:05.140 : otpw X
19:22:05.143 : ot X
19:22:05.143 : Driver registers:
19:22:05.145 : X = 0x1515:1515:1515:1515
19:22:05.147 : X current decreased to 400
19:22:05.593 : X driver error detected:
19:22:05.597 : overtemperature
19:22:05.599 : short to ground (coil A)
19:22:05.600 : short to ground (coil B)
19:22:05.600 : X
19:22:05.602 : Enabled false
19:22:05.602 : Set current 400
19:22:05.604 : RMS current 397
19:22:05.606 : MAX current 559.770000
19:22:05.608 : Run current 12/31
19:22:05.608 : Hold current 6/31
19:22:05.610 : CS actual 31/31
19:22:05.612 : PWM scale 255
19:22:05.612 : vsense 1=.18
19:22:05.615 : stealthChop true
19:22:05.615 : msteps 0
19:22:05.620 : tstep 4294967295
19:22:05.620 : pwm
19:22:05.620 : threshold 98
19:22:05.622 : [mm/s] 0.000000
19:22:05.624 : OT prewarn true
19:22:05.626 : OT prewarn has
19:22:05.626 : been triggered true
19:22:05.628 : off time 15
19:22:05.628 : blank time 54
19:22:05.631 : hysterisis
19:22:05.631 : -end 12
19:22:05.631 : -start 8
19:22:05.634 : Stallguard thrs 0
19:22:05.634 : DRVSTATUS X
19:22:05.636 : stallguard X
19:22:05.636 : sg_result 1023
19:22:05.638 : fsactive X
19:22:05.638 : stst X
19:22:05.638 : olb X
19:22:05.640 : ola X
19:22:05.640 : s2gb X
19:22:05.640 : s2ga X
19:22:05.642 : otpw X
19:22:05.642 : ot X
19:22:05.644 : Driver registers:
19:22:05.646 : X = 0x1515:1515:1515:1515
19:22:05.649 : X current decreased to 350
19:22:06.095 : X driver error detected:
19:22:06.097 : overtemperature
19:22:06.100 : short to ground (coil A)
19:22:06.100 : short to ground (coil B)
19:22:06.100 : X
19:22:06.100 : Enabled false
19:22:06.102 : Set current 350
19:22:06.104 : RMS current 336
19:22:06.106 : MAX current 473.760000
19:22:06.106 : Run current 10/31
19:22:06.108 : Hold current 5/31
19:22:06.110 : CS actual 31/31
19:22:06.110 : PWM scale 255
19:22:06.113 : vsense 1=.18
19:22:06.115 : stealthChop true
19:22:06.115 : msteps 0
19:22:06.117 : tstep 4294967295
19:22:06.117 : pwm
19:22:06.117 : threshold 98
19:22:06.119 : [mm/s] 0.000000
19:22:06.121 : OT prewarn true
19:22:06.123 : OT prewarn has
19:22:06.123 : been triggered true
19:22:06.125 : off time 15
19:22:06.125 : blank time 54
19:22:06.127 : hysterisis
19:22:06.127 : -end 12
19:22:06.130 : -start 8
19:22:06.130 : Stallguard thrs 0
19:22:06.132 : DRVSTATUS X
19:22:06.132 : stallguard X
19:22:06.134 : sg_result 1023
19:22:06.138 : fsactive X
19:22:06.138 : stst X
19:22:06.138 : olb X
19:22:06.138 : ola X
19:22:06.140 : s2gb X
19:22:06.140 : s2ga X
19:22:06.140 : otpw X
19:22:06.142 : ot X
19:22:06.142 : Driver registers:
19:22:06.144 : X = 0x1515:1515:1515:1515
19:22:06.149 : X current decreased to 300
19:22:06.596 : X driver error detected:

[teemuatlut]

All the TMC gcodes (M122, M906, M912, etc) are broken atm for 2.0.x branch. There was a compiler condition oversight (typo) when I ported the last TMC update to the new hierarchy layout from 1.1.x. I made a fix last week but because of new years and me being out of town, I haven't yet made a PR.

Also that's not a valid hex value! Not sure what's going on there.

[vilsed]

@teemuatlut Tried compiling your last week fixed branch, got my ubiquitous COOLCONF compile error. Ported the changes you made to the last branch on my hard drive that compiled successfully. Now TMC Mcodes do work, but somehow drivers don't want to enable. Tried homing, moving axis by Gcode, M17, M18, M84 with no luck. Setting drivers current with M906 seems to work, at least I see changes in M122, so the drivers should be good. Also as per M122 set microsteps are wrong (256 instead of 16). Posting M122 report, maybe you'll be able to see something that I don't.

@psavva Have you had such a condition?

21:14:21.271 : X Y Z E0
21:14:21.275 : Enabled false false false false
21:14:21.277 : Set current 600 600 600 800
21:14:21.280 : RMS current 1049 1049 1049 1436
21:14:21.285 : MAX current 1479.090000 1479.090000 1479.090000 2024.760000
21:14:21.288 : Run current 18/31 18/31 18/31 25/31
21:14:21.292 : Hold current 9/31 9/31 9/31 12/31
21:14:21.295 : CS actual 15/31 15/31 15/31 15/31
21:14:21.297 : PWM scale 0 0 0 0
21:14:21.300 : vsense 0=.325 0=.325 0=.325 0=.325
21:14:21.303 : stealthChop false false false false
21:14:21.305 : msteps 256 256 256 256
21:14:21.309 : tstep 1179648 1179648 1179648 1179648
21:14:21.310 : pwm
21:14:21.311 : threshold 79 79 79 53
21:14:21.316 : [mm/s] 1601.265869 1601.265869 1601.265869 825.879761
21:14:21.319 : OT prewarn false false false false
21:14:21.320 : OT prewarn has
21:14:21.322 : been triggered false false false false
21:14:21.324 : off time 0 0 0 0
21:14:21.326 : blank time 16 16 16 16
21:14:21.327 : hysterisis
21:14:21.329 : -end -3 -3 -3 -3
21:14:21.331 : -start 1 1 1 1
21:14:21.333 : Stallguard thrs 0 0 0 0
21:14:21.335 : DRVSTATUS X Y Z E0
21:14:21.336 : stallguard
21:14:21.338 : sg_result 0 0 0 0
21:14:21.339 : fsactive
21:14:21.340 : stst
21:14:21.341 : olb
21:14:21.341 : ola
21:14:21.342 : s2gb
21:14:21.343 : s2ga
21:14:21.344 : otpw
21:14:21.345 : ot
21:14:21.346 : Driver registers:
21:14:21.348 : X = 0x00:615:00:00
21:14:21.350 : Y = 0x00:615:00:00
21:14:21.351 : Z = 0x00:615:00:00
21:14:21.353 : E0 = 0x00:615:00:00

[teemuatlut]

I can start working on the LPC and DUE platforms for TMC when I find the time.
For now the output look really off. The driver registers are reporting non valid HEX values and max current is a floating value. This is not correct.

Some of the values are reported correctly because they are read from the shadow registers held by the library. No communication to the driver happens then.

What is the COOLCONF error?

[vilsed]

It's alright, we all spend as much time as we can spare for this :)

Building your current branch gives me this:

`.piolibdeps\TMC2130Stepper\src\source\TMC2130Stepper_COOLCONF.cpp:16:6: error: prototype for 'void TMC2130Stepper::sgt(int8_t)' does not mat

ch any in class 'TMC2130Stepper'
void TMC2130Stepper::sgt( int8_t B ) { MOD_REG(COOLCONF, SGT); }
^~~~
In file included from .piolibdeps\TMC2130Stepper\src\source\TMC2130Stepper_COOLCONF.cpp:1:0:
.piolibdeps\TMC2130Stepper\src/TMC2130Stepper.h:167:11: error: candidates are: uint8_t TMC2130Stepper::sgt()
uint8_t sgt();
^
.piolibdeps\TMC2130Stepper\src/TMC2130Stepper.h:160:8: error: void TMC2130Stepper::sgt(uint8_t)
void sgt( uint8_t B);
^~~
.piolibdeps\TMC2130Stepper\src\source\TMC2130Stepper_COOLCONF.cpp:27:8: error: prototype for 'int8_t TMC2130Stepper::sgt()' does not match a
ny in class 'TMC2130Stepper'
int8_t TMC2130Stepper::sgt() {
^~~~
In file included from .piolibdeps\TMC2130Stepper\src\source\TMC2130Stepper_COOLCONF.cpp:1:0:
.piolibdeps\TMC2130Stepper\src/TMC2130Stepper.h:167:11: error: candidates are: uint8_t TMC2130Stepper::sgt()
uint8_t sgt();
^
compilation terminated due to -fmax-errors=5.
.piolibdeps\TMC2130Stepper\src\source\TMC2130Stepper.cpp: In member function 'void TMC2130Stepper::begin()':
.piolibdeps\TMC2130Stepper\src\source\TMC2130Stepper.cpp:37:18: error: 'OUTPUT' was not declared in this scope
pinMode(_pinEN, OUTPUT);
^~
.piolibdeps\TMC2130Stepper\src\source\TMC2130Stepper.cpp:37:24: error: 'pinMode' was not declared in this scope
pinMode(_pinEN, OUTPUT);
^
.piolibdeps\TMC2130Stepper\src\source\TMC2130Stepper.cpp:41:23: error: 'HIGH' was not declared in this scope
digitalWrite(_pinEN, HIGH); //deactivate driver (LOW active)
^~
.piolibdeps\TMC2130Stepper\src\source\TMC2130Stepper.cpp:41:27: error: 'digitalWrite' was not declared in this scope
digitalWrite(_pinEN, HIGH); //deactivate driver (LOW active)
^
.piolibdeps\TMC2130Stepper\src\source\TMC2130Stepper.cpp:42:24: error: 'LOW' was not declared in this scope
digitalWrite(_pinDIR, LOW); //LOW or HIGH
^
compilation terminated due to -fmax-errors=5.
* [.pioenvs\LPC1768\libcac\TMC2130Stepper\source\TMC2130Stepper_COOLCONF.o] Error 1
* [.pioenvs\LPC1768\libcac\TMC2130Stepper\source\TMC2130Stepper.o] Error 1`

[teemuatlut]

I think you might be running a modified and out dated version of the library. Remove the TMC2130Stepper folder from .libdeps folder and let PIO download it again.

I had an idea that might be worth exploring but I can't do it myself just yet. We might be running the SPI too fast. By default this is setting 0, quoted at "aroud 5MHz". AVR SPI is ran at 2MHz by the TMC library.

There's also an interface mismatch where spiSend, which is used by my LPC SPI class method transfer, doesn't return anything. My assumption was to use spiSend and then spiRec to get the return value. This is not going to work. I will need to make some things not static or more likely more them over to the LPC SPI class and have the Marlin SPI functions direct to those.

[vilsed]

I did modify the library. Patched it up with Bob-the-Kuhns files from Nov 19. Compiling with stock library gives me this:

`|-- v2.0.2
Compiling .pioenvs\LPC1768\lib602\TMC2130Stepper_ID1493\source\SW_SPI.o
Compiling .pioenvs\LPC1768\lib602\TMC2130Stepper_ID1493\source\TMC2130Stepper.o

Compiling .pioenvs\LPC1768\lib602\TMC2130Stepper_ID1493\source\TMC2130Stepper_CHOPCONF.o
Compiling .pioenvs\LPC1768\lib602\TMC2130Stepper_ID1493\source\TMC2130Stepper_COOLCONF.o
.piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper.cpp: In member function 'void TMC2130Stepper::send2130(uint8_t, uint32_t*)':
.piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper.cpp:9:18: error: 'SPI' was not declared in this scope

define TMC_SPI SPI

^
.piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper.cpp:69:2: note: in expansion of macro 'TMC_SPI'
TMC_SPI.begin();
^~~
.piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper.cpp:71:52: error: 'MSBFIRST' was not declared in this scope
TMC_SPI.beginTransaction(SPISettings(16000000/8, MSBFIRST, SPI_MODE3));
^~~~
.piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper.cpp:71:62: error: 'SPI_MODE3' was not declared in this scope
TMC_SPI.beginTransaction(SPISettings(16000000/8, MSBFIRST, SPI_MODE3));
^~~~~
.piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper.cpp:71:71: error: 'SPISettings' was not declared in this scope
TMC_SPI.beginTransaction(SPISettings(16000000/8, MSBFIRST, SPI_MODE3));
^
Compiling .pioenvs\LPC1768\lib602\TMC2130Stepper_ID1493\source\TMC2130Stepper_DRV_STATUS.o
* [.pioenvs\LPC1768\lib602\TMC2130Stepper_ID1493\source\TMC2130Stepper.o] Error 1
[ERROR] Took 41.86 seconds`

[teemuatlut]

https://github.com/teemuatlut/Marlin/tree/LPC_TMC2130

If someone wants to give it a try. I am able to initialize and move a TMC2130 powered stepper with that it. The latest version (2.1.0) of the library from github is required and there is no release tag yet.

I would expect Bob's proper SPI implementation to replace the placeholder here as this is not actually even used when TMC_USE_SW_SPI is enabled.

[vilsed]

Awesome! Will try it tonight

[psavva]

I will also give it a go. Anything specific you want to test or should I just try making sure that it works on general with SPI?

[teemuatlut]

I'd just like to know it works for someone else too and not just me. Start with one stepper and move on from there.
There are at least two problems that I'm aware of right now. The TMC specific commands don't work on 2.0.x right now and the LPC core doesn't seem handle printing HEX values.

[Bob-the-Kuhn]

The printf command prints hex on the LPC1768.

[Roxy-3D]

The printf command prints hex on the LPC1768.

But if I remember right... You are only allowed to have one % in the format string, right? So you can't do something like:

  printf("%x:%x \n", addr, data);

[teemuatlut]

The printf command prints hex on the LPC1768.

It needs to work through MYSERIAL.print(val, HEX).

[tig33r]

MKS Sbase here:

Motors are working when I do one change in stepper_indirection.cpp (for software tmc software spi definition in conf adv):

define _TMC2130_DEFINE(ST) TMC2130Stepper stepper##ST(ST##_ENABLE_PIN, ST##_DIR_PIN, ST##_STEP_PIN, ST##_CS_PIN, P2_12, P1_23, P1_22)

As you know or not this board has broken hardware spi and sd card for example is working on software spi on (a custom cable is needed.):

#define SCK_PIN P1_22 // J8-2 (moved from EXP2 P0.7)
#define MISO_PIN P1_23 // J8-3 (moved from EXP2 P0.8)
#define MOSI_PIN P2_12 // J8-4 (moved from EXP2 P0.5)

I did not print anything yet, just moving motors from menu. Definitely need some adjustments for pins. Maybe @Bob-the-Kuhn can do shit with this case cause probably software spi changes was by him. Anyway we are almost done with tmc2130 on LPC176X! ;)

Awesome job guys!

[teemuatlut]

Getting the TMC2130 working on LPC was me and a weekend. If you define the TMC_USE_SW_SPI then it will use an implementation internal to the library and the transfer code was taken from Arduino's wiring_shift.c, modified originally by guys at Ultimachine for their Archim2 board.

You can define the pins at your pins_ file so there's no need to edit stepper_indirection.h. See the Re-ARM file for an example.

[tig33r]

Yeah I know but faster option was to edit stepper_indirection.cpp :)

Ofc working with defined parameters in pins_ file. I will test your solution more and give you more detailed feedback.

[Bob-the-Kuhn]

It needs to work through MYSERIAL.print(val, HEX).

On the LPC1768 I tried to just add HEX versions but I got a "can't overload" error.

I can change the decimal printout to HEX but I can't have both at the same time.

If you can point me to where the MYSERIAL.print(val, HEX) works I can see if I can do something similar

[p3p]

But if I remember right... You are only allowed to have one % in the format string, right? So you can't do...

@Roxy-3D not sure where you have picked that up from, (special cut down version maybe?), format strings don't have that limitation, they can be very complex which is why printf / sprintf take quite so much space to link in.

http://www.cplusplus.com/reference/cstdio/printf/

[teemuatlut]

I know it works on AVR and DUE but perhaps the LPC core can provide some guidance.

[p3p]

@Bob-the-Kuhn looks like I just ignored the number base parameter on the HalSerial class print methods (who needed it anyway :wink: )

https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/HAL/HAL_LPC1768/serial.h#L152
would need some logic to change the token character depending on it I guess.

[Bob-the-Kuhn]

I tried the following. Either works as desired by themselves but you can't have both at the same time. I get a "can't overload" error when compiling with both enabled.

void print(char value, int = BYTE)             { printf("%c" , value); }
void print(char value, int = HEX)              { printf("%2X" , value); }

I always made the same changes in serial.h and HardwareSerial.cpp.

Hmmm ... I never touched HardwareSerial.h. Something to try tomorrow.

[p3p]

You can't function overload on a default parameter value, you would need to change them something like:

  void print(int value, int nbase = 10) {
    if(nbase == 16) printf("%2X", value);
    else printf("%d");
  }

then update the ln methods to pass through

  void println(int value, int nbase = 10) {
    print(value, nbase);
    println();
  }

[vilsed]

Busy week this one... The new branch compiled with no problems, although SPI communication seems to be down still. No response from motors, M122, M906 spit nothing back out through serial. Tried with all four drivers first, then with only one, nothing. It took me some time to realize that teemuatlut moved the SW SPI pins, but replugging did not help either. @psavva Have you tried your setup yet? I'm starting to expect bad drivers again... :/

[tig33r]

Same situation. Motors are working but no feedback from serial.

[teemuatlut]

If you compiled without any errors, you're working with an outdated repo. There were some recent changes that fixed the TMC commands on 2.0.x branch and they were just merged. I also rebased my branch today to the latest bugfix-2.0.x and you SHOULD have an error about an undefined MYSERIAL. I'm pushing a fix as soon as I confirm that the steppers are moving and serial commands go through.

Edit: Stepper and commands both work. Please update the fork to the latest commit 516cae631ca4cd4bb30a19b7736ad368b7b48807 (Update to new serial naming scheme)

[tig33r]

Compiled newest version and error at start. Driver error. Printer halted. Please restart.

Connecting...
echo:SD init fail
Printer is now online.
echo:SD init fail
X driver error detected:
X Y
Enabled false false
Set current 1200 1200
RMS current 1160 1160
MAX current 1635.600000 1635.600000
Run current 20/31 20/31
Hold current 10/31 10/31
CS actual 0/31 0/31
PWM scale 0 0
vsense 0=.325 0=.325
stealthChop false false
msteps 256 256
tstep 0 0
pwm
threshold 0 0
[mm/s] - -
OT prewarn false false
OT prewarn has
been triggered false false
off time 0 0
blank time 16 16
hysterisis
-end -3 -3
-start 1 1
Stallguard thrs 0 0
DRVSTATUS X Y
stallguard
sg_result 0 0
fsactive
stst
olb
ola
s2gb
s2ga
otpw
ot
Driver registers:
X = 0x 0 0: 0 0: 0 0: 0 0
Y = 0x 0 0: 0 0: 0 0: 0 0
Error:Printer halted. kill() called!
[ERROR] Error:Printer halted. kill() called!

[teemuatlut]

Check your wiring.
And attach your configs (both + pins) and preferably an image of your wiring setup.

[psavva]

@tig33r @vilsed I managed to get it compiling, and M122 returning parameters...
No Driver Error
No Printer Halted :)

Just as a sidenote there is currently no drivers connected. The board is currently not in my printer.

17:06:16.058 : N22 M122 S081
17:06:16.058 : ok
17:06:18.724 : N23 M122 S181
17:06:18.727 : axis:pwm_scale |status_response|
17:06:18.727 : ok
17:06:21.072 : N24 M122*20
17:06:21.073 : X Y Z E0
17:06:21.076 : Enabled false false false false
17:06:21.078 : Set current 800 800 800 800
17:06:21.088 : RMS current
17:06:21.110 : MAX current 2024.760000 2024.760000 2024.760000 2024.760000
17:06:21.113 : Run current 25/31 25/31 25/31 25/31
17:06:21.116 : Hold current 12/31 12/31 12/31 12/31
17:06:21.134 : CS actual 0/31 0/31 0/31 0/31
17:06:21.151 : PWM scale 0 0 0 0
17:06:21.161 : vsense 0=.325 0=.325 0=.325 0=.325
17:06:21.170 : stealthChop false false false false
17:06:21.187 : msteps 256 256 256 256
17:06:21.204 : tstep 0 0 0 0
17:06:21.204 : pwm
17:06:21.206 : threshold 0 0 0 0
17:06:21.207 : [mm/s] - - - -
17:06:21.217 : OT prewarn false false false false
17:06:21.218 : OT prewarn has
17:06:21.221 : been triggered false false false false
17:06:21.238 : off time 0 0 0 0
17:06:21.255 : blank time 16 16 16 16
17:06:21.256 : hysterisis
17:06:21.272 : -end -3 -3 -3 -3
17:06:21.288 : -start 1 1 1 1
17:06:21.290 : Stallguard thrs 0 0 0 0
17:06:21.292 : DRVSTATUS X Y Z E0
17:06:21.301 : stallguard
17:06:21.318 : sg_result 0 0 0 0
17:06:21.326 : fsactive
17:06:21.334 : stst
17:06:21.342 : olb
17:06:21.349 : ola
17:06:21.358 : s2gb
17:06:21.366 : s2ga
17:06:21.374 : otpw
17:06:21.382 : ot
17:06:21.392 : Driver registers: X = 0x 0 0: 0 0: 0 0: 0 0
17:06:21.400 : Y = 0x 0 0: 0 0: 0 0: 0 0
17:06:21.408 : Z = 0x 0 0: 0 0: 0 0: 0 0
17:06:21.417 : E0 = 0x 0 0: 0 0: 0 0: 0 0
17:06:21.417 : ok

[tig33r]

I just remove and download clean new files. Now it is working with tmc software spi, seems like smth was fucked up with my local repo. Working means right now my printer is printing (aproximatelly from ~1h) without problems. Next point will be to check hardware spi but i have to wait till print end. Thanks a lot for your support.

Edit: working also with hardware spi

[vilsed]

Hello all.

With vanilla configuration files, having only TMC related stuff enabled, I can compile successfully. But when I add printer specific parameters (DELTA settings) and not much else, I get compile errors. What the heck?

Also attaching my configuration files.

configuration.zip

EDIT: The branch I found to compile successfully to begin with is https://github.com/MarlinFirmware/Marlin/commit/516cae631ca4cd4bb30a19b7736ad368b7b48807

`In file included from Marlin\src\HAL\HAL_LPC1768../../inc/../HAL/HAL_LPC1768/HAL.h:66:0,
from Marlin\src\HAL\HAL_LPC1768../../inc/../HAL/HAL.h:47,
from Marlin\src\HAL\HAL_LPC1768../../inc/MarlinConfig.h:28,
from Marlin\src\HAL\HAL_LPC1768\persistent_store_impl.cpp:24:

Marlin\src\HAL\HAL_LPC1768../../inc/../HAL/HAL_LPC1768/HardwareSerial.h:80:16: error: expected unqualified-id before numeric constant

define BYTE 0

^
frameworks\CMSIS\LPC1768\lib/chanfs/integer.h:22:23: note: in expansion of macro 'BYTE'
typedef unsigned char BYTE;
^~~~
Marlin\src\HAL\HAL_LPC1768../../inc/../HAL/HAL_LPC1768/HardwareSerial.h:80:16: error: expected unqualified-id before numeric constant

define BYTE 0

^
frameworks\CMSIS\LPC1768\lib/chanfs/diskio.h:20:9: note: in expansion of macro 'BYTE'
typedef BYTE DSTATUS;
^~
In file included from Marlin\src\HAL\HAL_LPC1768\persistent_store_impl.cpp:30:0:
frameworks\CMSIS\LPC1768\lib/chanfs/diskio.h:47:1: error: 'DSTATUS' does not name a type
DSTATUS disk_initialize (BYTE pdrv);
^~~
frameworks\CMSIS\LPC1768\lib/chanfs/diskio.h:48:1: error: 'DSTATUS' does not name a type
DSTATUS disk_status (BYTE pdrv);
^~~
frameworks\CMSIS\LPC1768\lib/chanfs/diskio.h:49:25: error: expected ')' before 'pdrv'
DRESULT disk_read (BYTE pdrv, BYTE* buff, DWORD sector, UINT count);
^~
compilation terminated due to -fmax-errors=5.
Compiling .pioenvs\LPC1768\src\src\HAL\HAL_STM32F1\HAL_Servo_Stm32f1.o
* [.pioenvs\LPC1768\src\src\HAL\HAL_LPC1768\persistent_store_impl.o] Error 1
[ERROR] Took 43.31 seconds
`

[tcm0116]

This should be fixed in the current bugfix-2.0.x branch.

[vilsed]

Current bugfix-2.0.x branch, updated TMC2130Stepper library to 2.1.1, getting this error.

If I understand correctly, TMC2130Stepper.cpp doesn't see that I have SW SPI enabled and skips that function entirely.

.piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper.cpp: In member function 'void TMC2130Stepper::send2130(uint8_t, uint32_t)':
.piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper.cpp:96:3: error: 'SPI' was not declared in this scope
SPI.begin();
^~~
.piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper.cpp:97:58: error: 'SPI_MODE3' was not declared in this scope
SPI.beginTransaction(SPISettings(16000000/8, MSBFIRST, SPI_MODE3));
^~~~~
.piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper.cpp:97:67: error: 'SPISettings' was not declared in this scope
SPI.beginTransaction(SPISettings(16000000/8, MSBFIRST, SPI_MODE3));
^
** [.pioenvs\LPC1768\lib351\TMC2130Stepper_ID1493\source\TMC2130Stepper.o] Error 1
[ERROR] Took 13.63 seconds

[teemuatlut]

TMC2130 is not yet supported with LPC. You need to use my pull request branch or wait for Travis to pass so it can be merged.

[vilsed]

How's that you just copy/paste files that you've already tried and nothing worked, and now it all compiles and runs? :D Is it always like that with coding?

Jokes aside, SPI still doesn't work for me. Neither SW nor HW. M122 gives empty driver registers. Wiring is correct. Will try the drivers with a m2560 once more, just to be sure. It would be odd that ALL FOUR drivers died simultaneously, even though they're cheapos from AliExpress...

[teemuatlut]

Did you make the necessary changes to the drivers?

[vilsed]

Yes, I have enabled SPI by removing the jumper. I don't know of any other necessary changes. Again, they did work just fine with a m2560. Printed a benchie.

[psavva]

@vilsed, are you powering the re-arm via the 12v connector from a PSU? Or are you just powering it off the USB cable? The drivers need power from the main power plug you normally use on a printer installed...

[psavva]

You can try using my branch
https://github.com/psavva/Marlin?files=1
Just ensure you disable PINS_DEBUGGING as they is a bug.
The branch is called tmc_debug

Don't further that your wiring will need to be mapped as per the re-arm pins file, and the spi pins as per the tmc sw spi definition

[vilsed]

@psavva I'm powering everything trough the power connector on the RAMPS. I have USB power disabled on the re-ARM. I can rule out this power delivery issue completely, because the TMCs worked perfectly on the exact same RAMPS board, with exactly the same SPI wiring loom, exactly the same everything, but m2560 in place of re-ARM. So that's bizzare. I will try your branch later today.

My wiring is allready as per pins_RE_ARM file. Actually I tried that and hardware SPI pins (aux 3 connector on the RAMPS), no difference.

BUT. This time M122 does recognize if the drivers are enabled or disabled, it does properly read set current and so on. It's just that drive registers read 0xFF:FF:FF:FF

[psavva]

Double check the pins because they have changed. All the SPI pins are
configured to use the Ethernet Pins on the re-arm. All the CS Pins are
configured to use J5 on the re-arm

On Fri, Jan 19, 2018, 13:40 vilsed [e-mail] wrote:

@psavva https://github.com/psavva I'm powering everything trough the
power connector on the RAMPS. I have USB power disabled on the re-ARM. I
can rule out this power delivery issue completely, because the TMCs worked
perfectly on the exact same RAMPS board, with exactly the same SPI wiring
loom, exactly the same everything, but m2560 in place of re-ARM. So that's
bizzare. I will try your branch later today.

My wiring is allready as per pins_RE_ARM file. Actually I tried that and
hardware SPI pins (aux 3 connector on the RAMPS), no difference.

BUT. This time M122 does recognize if the drivers are enabled or disabled,
it does properly read set current and so on. It's just that drive registers
read 0xFF:FF:FF:FF

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/8334#issuecomment-358942665,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABYyplLdGvwNtW6vl8fvfJalg7eC_HnYks5tMH8cgaJpZM4QWzGh
.

[vilsed]

@psavva Yes, I'm well aware of that. Complied your branch successfully. Did not immediately work. Figured I could try switching MISO and MOSI pins around, just for shits and giggles. And lo and behold, it works. Ech... I'm an idiot

[psavva]

:) Seems we both made the exact same mistake :)
By any chance, South African? Ech...

[vilsed]

No, Lithuania :} It seems that we have a similar expression :)

I always assumed that MISO is SDI. Both have an "I". Made sense. Turns out it's not the case.

In any case, launching a test print right away. Thank you all for great support, guys! There's a reason I love Marlin over everything else so much :)

One note, though. P1_30 pin is also used for RRDGLCD beeper. Get's annoying quite quickly. Moved Z_CS to P1_15

[teemuatlut]

It's all very logical once you spell them out.
MOSI = Master Out Slave In
MISO = Master In Slave Out
SDI = Slave Data In
SDO = Slave Data Out

[vilsed]

That's one lesson I'll remember for the rest of my life :) Thank you

[psavva]

I can confirm my tmc drivers also work with tmc sw spi enabled.

I'm closing this issue :)

Thank you all very much for working on this!