Teensy 4.0 Serial Working Differently on Different Devices

BlueTurtle

Active member
Hey everyone,

I'm trying to make the T4 work with TMC2130 Stepper Drivers so that I can use them without endstops. The following code works fine when I connect to my T4 with RPi but when I connect T4 to my Mac the T4 gives out wrong output from serial (Almost everything turns out to be 0 and stepper motor doesn't stop when it hits an obstacle. Everything works when my T4 is connected to Rpi). I'm wondering how I can fix this issue to continue my development from my laptop rather than RPi because it is too slow.

Board: My Custom board with T4 for controller
Rpi: Raspberry SC15184 Pi 4 Model B 2019 Quad Core 64 Bit WiFi Bluetooth (2GB), Arduino 1.8.10 with Teensyduino Addon
Macbook Pro, Catalina 10.15.3, Latest Teensyduino

Code:
#include <TMC2130Stepper.h>
#include <TMC2130Stepper_REGDEFS.h>
#include <MeanFilterLib.h>

// Motor Parameters           //  Parameters known to work for Z axis
#define MOTOR_STEPS 200.0     //  Steps per rev typically 200 (1.8°) to 400 (0.9°)
#define MICROSTEPS 16         //  [16]
#define DRIVER_CURRENT_mA 900 //  [900] Current in milliAmps  
#define MAX_SPEED_RPS  60     //  [60]
#define MIN_SPEED_RPS  1      //  [1]
#define INIT_SPEED_RPS 3      //  [3]   Final speed  target for homing
#define INIT_SPEED_ACTUAL 2   //  [2]   Initial speed of the stepper
#define SPEED_INCR_VAL 0.2    //  [0.2] Speed change per +,- inputs
#define ACCEL_RATE 0.1        //  [0.1] Speed change per DISPLAY_INTERVAL until target speed is reached
#define INIT_SGT_VALUE 1      //  [1]   Initial StallGuardTreshold Value

#define DISPLAY_INTERVAL 100  //  In milliSeconds. How often to display values


#define stepZ   32
#define csZ     31
#define enZ     30


uint32_t previousStep; // Holds the last time a step was made in milliSeconds.

char buff[100];
bool dirZ = 1;

// Stepper Driver Initialization
TMC2130Stepper driverZ = TMC2130Stepper(csZ);

bool vsense;
volatile uint16_t speed_rps = INIT_SPEED_RPS; // initial speed
int8_t sg_value = INIT_SGT_VALUE;             // initial stallGuard Value

float current_speed = INIT_SPEED_ACTUAL;
float target_speed = INIT_SPEED_RPS;

MeanFilter<long> meanFilter(10);


uint16_t rms_current(uint8_t CS, float Rsense = 0.11) {
  return (float)(CS + 1) / 32.0 * (vsense ? 0.180 : 0.325) / (Rsense + 0.02) / 1.41421 * 1000;
}

// used to get step interval from RPM
uint32_t step_interval_us(float rps) {
  uint32_t steps_per_second = ((MOTOR_STEPS * MICROSTEPS * rps));
  return (1000000 / steps_per_second);
}


// setup timer to be used in stepping with interrupts.
IntervalTimer stepTimer;

//timer interrupt function
void Step() {
  unsigned long currentMicros = micros();
  digitalWrite(stepZ, HIGH);

  if (currentMicros - previousStep >= 1) {
    previousStep = micros();

    digitalWrite(stepZ, LOW);
  }





}


void setup() {


  pinMode(enZ, OUTPUT);
  pinMode(stepZ, OUTPUT);
  pinMode(csZ, OUTPUT);


  digitalWrite(enZ, HIGH); //deactivate driver (LOW active)
  digitalWrite(stepZ, LOW);
  digitalWrite(csZ, HIGH);

  // menu
  Serial.begin(115200); //init serial port and set baudrate
  while (!Serial);
  Serial.println("\r\nTMC2130 StallGuard2 test program\r\n");
  delay(1);
  Serial.println("'+' = faster");
  delay(1);
  Serial.println("'-' = slower");
  delay(1);
  Serial.println("'1' = run");
  delay(1);
  Serial.println("'0' = pause");
  delay(1);
  Serial.println("'r' = reverse");
  delay(1);
  Serial.println("'i' = increase StallGuard Value");
  delay(1);
  Serial.println("'d' = decrease StallGuard Value");
  delay(1);
  Serial.println("Send '1' character to begin (\r\n");
  delay(1);

  while (Serial.available() == 0) // Wait for the serial input.
  {
  }

  //SPI.begin();

  driverZ.begin();
  driverZ.push();
  driverZ.toff(3);
  driverZ.tbl(1);
  driverZ.stealthChop(0);
  driverZ.hysteresis_start(4);
  driverZ.hysteresis_end(-2);
  driverZ.setCurrent(DRIVER_CURRENT_mA, 0.11, 0.5);

  driverZ.microsteps(MICROSTEPS);
  driverZ.coolstep_min_speed(0xFFFFF);
  driverZ.diag1_stall(1);
  driverZ.diag1_active_high(1);

  driverZ.THIGH(0);
  driverZ.semin(5);
  driverZ.semax(2);
  driverZ.sedn(0b01);
  driverZ.sg_stall_value(sg_value);

  //TMC2130 outputs on (LOW active)

  stepTimer.begin(Step, step_interval_us(current_speed));

  digitalWrite(enZ, LOW);
  vsense = driverZ.vsense();
}

void loop()
{
  static uint32_t last_time = 0;
  uint32_t ms = millis();
  stepTimer.update(step_interval_us(current_speed));


  while (Serial.available() > 0) {

    int8_t read_byte = Serial.read();

    if (read_byte == '0')      {
      digitalWrite( enZ, HIGH );
      current_speed = INIT_SPEED_ACTUAL;
    }

    else if (read_byte == '1') {
      digitalWrite( enZ,  LOW );
    }

    else if (read_byte == '+') {
      if (target_speed < MAX_SPEED_RPS) {
        target_speed += SPEED_INCR_VAL;
        Serial.print("Faster\r\n");
      }
    }

    else if (read_byte == '-') {
      if (target_speed > MIN_SPEED_RPS) {
        target_speed -= SPEED_INCR_VAL;
        Serial.print("Slower\r\n");
      }
    }

    else if (read_byte == 'r') { // reverse
      dirZ = !dirZ;
      driverZ.shaft_dir(dirZ);
      current_speed = INIT_SPEED_ACTUAL;
      if (dirZ == 1) {
        Serial.println("Up");
      } else {
        Serial.println("Down");
      }
    }

    else if (read_byte == 'i') { // increase stall value
      if (sg_value < 64) {
        sg_value++;
        driverZ.sg_stall_value(sg_value);
      }
    }

    else if (read_byte == 'd') {
      if (sg_value > -64) {
        sg_value--;
        driverZ.sg_stall_value(sg_value);
      }
    }
  }




  if ((ms - last_time) > DISPLAY_INTERVAL) //run every 0.01s
  {
    last_time = ms;

    uint32_t TSTEP = driverZ.TSTEP();

    if (TSTEP != 0xFFFFF) { // if driver is stepping

      noInterrupts();       // Disable intterupts to get accurate reading from TMC2130
      uint32_t drv_status = driverZ.DRV_STATUS();

      int mean = meanFilter.AddValue((drv_status & STALLGUARD_bm) >> STALLGUARD_bp);

      if (((drv_status & STALLGUARD_bm) >> STALLGUARD_bp) == 1) {
        Serial.println("STALL DETECTED");
        digitalWrite(enZ, HIGH);
      }

      sprintf(buff, "RPS:%2.1f SGT:%02d SGV:%04lu", current_speed, sg_value, (drv_status & SG_RESULT_bm) >> SG_RESULT_bp);
      Serial.print(buff);


      sprintf(buff, "TSTEP: %05lu", TSTEP);
      Serial.print(buff);


      sprintf(buff, "SG: %d I:04%lu \r\n", mean, (drv_status & CS_ACTUAL_bm) >> CS_ACTUAL_bp);
      Serial.print(buff);
    }

    if (fabs(current_speed - target_speed) >=  ACCEL_RATE) {
      if (current_speed < target_speed) {
        current_speed += ACCEL_RATE;
      }
      else {
        current_speed -= ACCEL_RATE;
      }
    }
    interrupts();         // Enable intterupts to generate accurate Steps. 
  }
}
 
Update!!!!
The same code is now working for my macbook pro as well but I would be really happy if we can figure out the underlying problem.
I deleted the latest Teensyduino, Installed Arduino 1.8.11 and installed the latest Teensyduino installer and it started to work.

######### Edit 1 #########
I shut down Arduino and opened back up. It's not working again...
######### Edit 2 #########
When I compile the code and load it from my raspberryPi and disconnect the USB from RPi and connect it to Mac it works fine. When I compile the code and load it from my macbook the
code doesn't work. By doesn't work I mean I can read the RPM and the directions etc. I can speed up the motor, slow it down, start and stop it but it reports incorrect values for stallguard parameters it reads from the TMC2130. Everything works fine on Rpi, and when the code is loaded from Rpi and T4 connected to Mac. Also I did one last test and when code is loaded from Mac and the USB is switched to Rpi everything works again.
 
Last edited:
Sounds like the Arduino install on the Mac is not building right for some reason. Local library copies in 'sketchbook' ?

What version was uninstalled on Mac re this note : "deleted the latest Teensyduino"?

1.8.13 is the latest IDE - and IDE 1.8.11 was okay - .10 and .12 had Mac issues in stability.

What shows in Verbose console output on the two builds when compared with regards to 'Libraries'? Are the displayed memory/flash used similar?
 
Sounds like the Arduino install on the Mac is not building right for some reason. Local library copies in 'sketchbook' ?

What version was uninstalled on Mac re this note : "deleted the latest Teensyduino"?

1.8.13 is the latest IDE - and IDE 1.8.11 was okay - .10 and .12 had Mac issues in stability.

What shows in Verbose console output on the two builds when compared with regards to 'Libraries'? Are the displayed memory/flash used similar?

Hmm.. I'll try to reinstall. By local library copies in sketchbook what do you mean? The latest teensyduino complete package from the teensy downloads page. Not the add on.
How do I check the verbose output?
 
File / Preferences :: has an option for Verbose compile output. That will show more complete build information and location of the libraries used.

If there is a copy of a library in the 'sketchbook' folder ( path seen on properties also ) that will show in the verbose output. If there is may not be the current version of the library to be used. In 'sketchbook'\libraries

Everything here is Windows - so if there is another Mac oddity to the IDE ...
 
Probably not the issue but latest MacOS is 10.15.6. Usually, the latest of everything is the best bet when something weird is happening, but, otherwise don't change anything:)
 
File / Preferences :: has an option for Verbose compile output. That will show more complete build information and location of the libraries used.

If there is a copy of a library in the 'sketchbook' folder ( path seen on properties also ) that will show in the verbose output. If there is may not be the current version of the library to be used. In 'sketchbook'\libraries

Everything here is Windows - so if there is another Mac oddity to the IDE ...

Okay I did that and there is something weird going on. I don't know if it affects anything but the dynamic available for everything seems like 1048576 bytes in Rpi but it is only 524288 bytes in Mac.

Here is the output from the Rpi:

Multiple libraries were found for "TMC2130Stepper.h"
Used: /home/pi/Arduino/libraries/TMC2130Stepper
Multiple libraries were found for "SPI.h"
Used: /home/pi/Desktop/arduino-1.8.10/hardware/teensy/avr/libraries/SPI
Multiple libraries were found for "MeanFilterLib.h"
Used: /home/pi/Arduino/libraries/MeanFilterLib
Using library TMC2130Stepper at version 2.5.1 in folder: /home/pi/Arduino/libraries/TMC2130Stepper
Using library SPI at version 1.0 in folder: /home/pi/Desktop/arduino-1.8.10/hardware/teensy/avr/libraries/SPI
Using library MeanFilterLib at version 1.0.0 in folder: /home/pi/Arduino/libraries/MeanFilterLib
/home/pi/Desktop/arduino-1.8.10/hardware/teensy/../tools/arm/bin/arm-none-eabi-size -A /tmp/arduino_build_234900/SensorlessHoming.ino.elf
Sketch uses 38608 bytes (1%) of program storage space. Maximum is 2031616 bytes.
Global variables use 45344 bytes (4%) of dynamic memory, leaving 1003232 bytes for local variables. Maximum is 1048576 bytes.


Here is the output from Mac
Using library TMC2130Stepper at version 2.5.1 in folder: /Users/mb/Documents/Arduino/libraries/TMC2130Stepper
Using library SPI at version 1.0 in folder: /Users/mb/Desktop/Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SPI
Using library MeanFilterLib at version 1.0.0 in folder: /Users/mb/Documents/Arduino/libraries/MeanFilterLib
/Users/mb/Desktop/Teensyduino.app/Contents/Java/hardware/teensy/../tools/arm/bin/arm-none-eabi-size -A /var/folders/_z/k74v63sx2f34ks50qjt42j6h0000gn/T/arduino_build_573774/SensorlessHoming.ino.elf
Sketch uses 39648 bytes (1%) of program storage space. Maximum is 2031616 bytes.
Global variables use 45748 bytes (8%) of dynamic memory, leaving 478540 bytes for local variables. Maximum is 524288 bytes.
 
File / Preferences :: has an option for Verbose compile output. That will show more complete build information and location of the libraries used.

If there is a copy of a library in the 'sketchbook' folder ( path seen on properties also ) that will show in the verbose output. If there is may not be the current version of the library to be used. In 'sketchbook'\libraries

Everything here is Windows - so if there is another Mac oddity to the IDE ...

Okay new update...

I get the same result depending on where I compile and load the code from.

When the code is loaded from Mac and serial monitor is opened from Mac or Rpi, I can control the motors but the T4 can send direction etc to the TMC2130 but it can't read back.

When I load the code from Rpi, both Mac and Rpi serial monitor works as expected. I can control the motors and the T4 can communicate with TMC2130 both ways without a problem.

As you suggested the displayed Memory/Flash usage is very similar but when compiled and loaded from macbook the flash memory is seen as half of what is available on Rpi. I'm really not sure why the half of dynamic memory is not being recognized by macbook. Does it have to do with 32 bit / 64 bit shift Catalina did?.
 
Okay I did that and there is something weird going on. I don't know if it affects anything but the dynamic available for everything seems like 1048576 bytes in Rpi but it is only 524288 bytes in Mac.

Here is the output from the Rpi:

Multiple libraries were found for "TMC2130Stepper.h"
Used: /home/pi/Arduino/libraries/TMC2130Stepper
Multiple libraries were found for "SPI.h"
Used: /home/pi/Desktop/arduino-1.8.10/hardware/teensy/avr/libraries/SPI
Multiple libraries were found for "MeanFilterLib.h"
Used: /home/pi/Arduino/libraries/MeanFilterLib
Using library TMC2130Stepper at version 2.5.1 in folder: /home/pi/Arduino/libraries/TMC2130Stepper
Using library SPI at version 1.0 in folder: /home/pi/Desktop/arduino-1.8.10/hardware/teensy/avr/libraries/SPI
Using library MeanFilterLib at version 1.0.0 in folder: /home/pi/Arduino/libraries/MeanFilterLib
/home/pi/Desktop/arduino-1.8.10/hardware/teensy/../tools/arm/bin/arm-none-eabi-size -A /tmp/arduino_build_234900/SensorlessHoming.ino.elf
Sketch uses 38608 bytes (1%) of program storage space. Maximum is 2031616 bytes.
Global variables use 45344 bytes (4%) of dynamic memory, leaving 1003232 bytes for local variables. Maximum is 1048576 bytes.


Here is the output from Mac
Using library TMC2130Stepper at version 2.5.1 in folder: /Users/mb/Documents/Arduino/libraries/TMC2130Stepper
Using library SPI at version 1.0 in folder: /Users/mb/Desktop/Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SPI
Using library MeanFilterLib at version 1.0.0 in folder: /Users/mb/Documents/Arduino/libraries/MeanFilterLib
/Users/mb/Desktop/Teensyduino.app/Contents/Java/hardware/teensy/../tools/arm/bin/arm-none-eabi-size -A /var/folders/_z/k74v63sx2f34ks50qjt42j6h0000gn/T/arduino_build_573774/SensorlessHoming.ino.elf
Sketch uses 39648 bytes (1%) of program storage space. Maximum is 2031616 bytes.
Global variables use 45748 bytes (8%) of dynamic memory, leaving 478540 bytes for local variables. Maximum is 524288 bytes.

The "Maximum is 1048576 bytes" versus "Maximum is 524288 bytes"
> suggests one is REALLY OLD - there was a point when ( IIRC ) T_4.0 built showing 1 MB and that confused folks as the upper 512KB was not for code. It was changed [ In TeensyDuino ] to 512 KB MAX some time back.
That would be the rPi if that is right.

If the IDE is in use - do Help / About and on the upper right corner the TeensyDuino version is noted. Output from rPi shows IDE 1.8.10 ? Current is 1.8.13 - not sure if that affects this Teensy Build issue.
> Though it does exalain the "Multiple libraries" text because that was broken then and showed that even when there was a single.

That shows the two are not running the same Teensy tools and Cores build files.

Between the two I'm not sure how to tell which is using an installed Teensy Library or an add in library stored in the sketchbook folder. Seems like SPI is the Teensy version and the other two are locally installed?
 
The "Maximum is 1048576 bytes" versus "Maximum is 524288 bytes"
> suggests one is REALLY OLD - there was a point when ( IIRC ) T_4.0 built showing 1 MB and that confused folks as the upper 512KB was not for code. It was changed [ In TeensyDuino ] to 512 KB MAX some time back.
That would be the rPi if that is right.

If the IDE is in use - do Help / About and on the upper right corner the TeensyDuino version is noted. Output from rPi shows IDE 1.8.10 ? Current is 1.8.13 - not sure if that affects this Teensy Build issue.
> Though it does exalain the "Multiple libraries" text because that was broken then and showed that even when there was a single.

That shows the two are not running the same Teensy tools and Cores build files.

Between the two I'm not sure how to tell which is using an installed Teensy Library or an add in library stored in the sketchbook folder. Seems like SPI is the Teensy version and the other two are locally installed?

Yes you are right. The old one is the rPi and the new one is Mac. However the rPi compiled code works as expected, at least in my case and the Mac is not. rPi Arduino version is 1.8.10 and Teensyduino add-on is 1.48.

Mac is running the latest stand alone Teensyduino available.
TMC2130 library makes use of SPI library so maybe there is an issue there?

I tried to copy and paste the SPI library in rPI that working sketch uses and placed in the libraries in the folder Mac uses to see if it makes any difference but it didn't.
 
Perhaps when the Rpi is updated to the latest it won't work either? Maybe more error checking or different defaults.

Why is SPI.begin() commented out? Where are SPI pins assigned?
 
TD 1.48 is early if not first 'post beta' release T_4.0. Some edits since then - and support for T_4.1 that uses same 1062 MCU, but nothing else in current version TD 1.53 showing as generally busted - though some tweaks pending.

It is interesting that it seems to work with that older version.

Assuming "Mac is running the latest stand alone Teensyduino available" is TD 1.53 - if is has issues to be addressed it would need to be in use to diagnose/repro.

Some folks ( @KurtE or Paul ) have ability to build rPi - but not probably those stepper motors.

Might be good to clean and refresh the Mac with new IDE 1.8.13 and with TD 1.53 repro sample and specify the library sources needed with a test - perhaps something will show - or somebody may have that hardware to see it.
 
@defragster and @BlueTurtle - Not sure what exactly is going on.

If I am understanding correctly you are having issues with USB Serial? That is to/from the Serial object and not one of the Hardware Serial objects (Serial1...SerialN) ?

And the code works with with code built using a real old version of Teensyduino, but not with the current one?

I was able to build your sketch (after installing libraries on a PC) and it does output stuff to Terminal window.

And I can probably be setup to build on RPI... I just setup an RPI4-8 yeterday with Ubuntu 20.04 and Ros2 on an SSD. I have not installed Arduino yet...

But my first guess is the changes to USB since the early release, in which Paul has increased the speed that the T4 and now T4.1 can output over USB Serial.

So maybe it is overwhelming whatever is running on the MAC? Or RPI who is processing the data?

As for Stepper motors... The only possible place I may have some steppers right now is with my Printrbot printer with the dead controller board (USB connector ripped off the board)...

So my question is, what is sending and receiving data on your host?
 
@defragster and @BlueTurtle - Not sure what exactly is going on.

If I am understanding correctly you are having issues with USB Serial? That is to/from the Serial object and not one of the Hardware Serial objects (Serial1...SerialN) ?

And the code works with with code built using a real old version of Teensyduino, but not with the current one?

I was able to build your sketch (after installing libraries on a PC) and it does output stuff to Terminal window.

And I can probably be setup to build on RPI... I just setup an RPI4-8 yeterday with Ubuntu 20.04 and Ros2 on an SSD. I have not installed Arduino yet...

But my first guess is the changes to USB since the early release, in which Paul has increased the speed that the T4 and now T4.1 can output over USB Serial.

So maybe it is overwhelming whatever is running on the MAC? Or RPI who is processing the data?

As for Stepper motors... The only possible place I may have some steppers right now is with my Printrbot printer with the dead controller board (USB connector ripped off the board)...

So my question is, what is sending and receiving data on your host?

At first I thought the problem was due to USB Serial but now I think it is something else. Same code compiled from rPi and Mac give the same results over USB Serial on all machines. By that I mean if the code is compiled from rPi and stepper is controlled over Serial Monitor on either rPi or Mac everything works fine. When the code is compiled from Mac, I get the same wrong results over USB even if I connect it to rPi or Mac.

The TMC2130 has a sensor-less homing feature called StallGuard. Using StallGuard one can figure out when the motor stalls and subsequently stop it if it stalls. TMC2130 can also work without a direction pin, which is what I'm using right now. I'm setting the direction stepper needs to go over SPI.

Ultimately what this sketch should be able to do is:
Start and Stop stepper movement
Speed up and slow down stepper movement
Change direction of the stepper over SPI
Read StallGuard feature values over SPI from TMC2130 and decide if it stalled and stop the motor if it stalled.

Now everything works fine when code is compiled from rPi. I can detect if the motor has stalled, read the Stall values and etc.

When code is compiled from Mac, I can start and stop stepper, speed up and slow down, change direction of stepper but I can't read any sensible data from TMC2130.

I will try to record a video soon so it is easier to understand what is going on.
 
@BlueTurtle Its looks like your using pin 31 for the SPI CS. Others can comment but I think SPI wants that on pin 10. It may work but not reliably?

One other thing. I had an issue a while ago with the TMC2130. I was using 20V for the steppers and there was some kind of timing issue when powering up between the 5V and 20V causing a buzz noise for a few seconds on startup. The TMC2130 eventually(maybe 3rd try while debugging) managed to short the 20V to the 5V rail destroying lots of stuff. Haven't used it since.
 
@BlueTurtle Its looks like your using pin 31 for the SPI CS. Others can comment but I think SPI wants that on pin 10. It may work but not reliably?

One other thing. I had an issue a while ago with the TMC2130. I was using 20V for the steppers and there was some kind of timing issue when powering up between the 5V and 20V causing a buzz noise for a few seconds on startup. The TMC2130 eventually(maybe 3rd try while debugging) managed to short the 20V to the 5V rail destroying lots of stuff. Haven't used it since.

I really don't know if it has reliability issues if the pin is changed. I can't change it now since I have made my own PCB and it is physically set there :rolleyes:...
I have placed diodes on the board that satisfies the power-up sequence requirements as well as flyback diodes on all steppers. I think it is something to do with the software because rPi works reliably. :confused:
 
Looks like your not using the TMC2130Stepper object that uses the SPI if that helps anything.

I instantiate TMC2130Stepper object here: TMC2130Stepper driverZ = TMC2130Stepper(csZ); and use dirZ throughout the program. Is there something I'm missing here?
 
I instantiate TMC2130Stepper object here: TMC2130Stepper driverZ = TMC2130Stepper(csZ); and use dirZ throughout the program. Is there something I'm missing here?

I was wrong in that post and can't modify it. I now think your using it correctly except maybe the wrong pin.
Try this in a google search: site: forum.pjrc.com T4 SPI CS

You could try slowing down the SPI.

Just watched the video explaining the problem. Nice
As far as the rPi vs Mac thing can't say. As a hacker I try lots of things that shouldn't help but often do like re-ordering the begins for different objects and even the order of the includes. I could see different machines doing things differently there.

I'd put a print statement in the setup Serial.println((char*)__FILE__); so you know which machine compiled it.

Before you mentioned moving some SPI files around. In almost every case you should try to use the default ones installed in Teensyduino. Anything in your documents/Arduino/library will override the teensy optimized ones.
 
I was wrong in that post and can't modify it. I now think your using it correctly except maybe the wrong pin.
Try this in a google search: site: forum.pjrc.com T4 SPI CS

You could try slowing down the SPI.

Just watched the video explaining the problem. Nice
As far as the rPi vs Mac thing can't say. As a hacker I try lots of things that shouldn't help but often do like re-ordering the begins for different objects and even the order of the includes. I could see different machines doing things differently there.

I'd put a print statement in the setup Serial.println((char*)__FILE__); so you know which machine compiled it.

Before you mentioned moving some SPI files around. In almost every case you should try to use the default ones installed in Teensyduino. Anything in your documents/Arduino/library will override the teensy optimized ones.

Okay got everything to work on my macbook. After seeing the code works fine in both Mac and rPi when compiled to rPi we narrowed the problem to software and not the usb serial communication. I have solved the problem by fiddling with the TMC2130 library. When we are reading back from TMC2130 it is possible to set the SPI speed. Contrary to your suggestion it worked when I speed up the SPI but I'm happy you suggested that because I probably wouldn't have thought that might be the problem... :D :D
Previously SPI was set up to 1MHz and maximum the TMC2130 supports is 4MHz. When I set the SPI speed to 4MHz everything started to work like the rPi version. Can someone shed light to why this might be happening though?
 
Okay got everything to work on my macbook. After seeing the code works fine in both Mac and rPi when compiled to rPi we narrowed the problem to software and not the usb serial communication. I have solved the problem by fiddling with the TMC2130 library. When we are reading back from TMC2130 it is possible to set the SPI speed. Contrary to your suggestion it worked when I speed up the SPI but I'm happy you suggested that because I probably wouldn't have thought that might be the problem... :D :D
Previously SPI was set up to 1MHz and maximum the TMC2130 supports is 4MHz. When I set the SPI speed to 4MHz everything started to work like the rPi version. Can someone shed light to why this might be happening though?

There may have been an update to SPI causing this - as the rPi is older TD and the macbook newer right?

Possibly a side effect of a change made for timing/behavior to fix another observed behavior.

Can you post a very simple sketch with only the needed hardware used that show the problem and solution for TMC2130 function?

There was at least one SPI change IIRC - but how that could affect this would be best understood by those who know ... and then get the same hardware to see the effect with a sketch.
 
...Previously SPI was set up to 1MHz and maximum the TMC2130 supports is 4MHz. When I set the SPI speed to 4MHz everything started to work like the rPi version. Can someone shed light to why this might be happening though?

Curious, 4MHz is the default for SPI if you don't specify it. This could be one of those who's called last mentioned.
 
Back
Top