Marlin: [2.0.x, 32-bit] Problems initializing TMC2130, microstepping incorrect.
Our prototype printers that are using Archim boards no longer work after an upgrade to the latest Marlin and the new TMCStepper library. The motors runs very slowly, leading us to believe that microstepping is set incorrectly. Interestingly, our Mini 2 which uses an Einsy board works fine.
When I do a M122, it shows the microstepping to be 256, while in Configuration_adv.h it is set to 16. Here is the output of M122:
ok P15 B4
X Y Z E E1
Enabled false false false false false
Set current 950 950 960 960 960
RMS current 923 923 923 923 923
MAX current 1301 1301 1301 1301 1301
Run current 17/31 17/31 17/31 17/31 17/31
Hold current 8/31 8/31 8/31 8/31 8/31
CS actual 0/31 0/31 0/31 0/31 0/31
PWM scale 0 0 0 0 0
vsense 0=.325 0=.325 0=.325 0=.325 0=.325
stealthChop false false false false false
msteps 256 256 256 256 256
tstep 0 0 0 0 0
pwm
threshold 109 109 527 62 62
[mm/s] 1160.55 1160.55 48.01 485.79 485.79
OT prewarn false false false false false
OT prewarn has
been triggered false false false false false
off time 0 0 0 0 0
blank time 16 16 16 16 16
hysteresis
-end -3 -3 -3 -3 -3
-start 1 1 1 1 1
Stallguard thrs 6 5 0 0 0
DRVSTATUS X Y Z E E1
stallguard
sg_result 0 0 0 0 0
fsactive
stst
olb
ola
s2gb
s2ga
otpw
ot
Driver registers:
X 0x00:00:00:00
Y 0x00:00:00:00
Z 0x00:00:00:00
E 0x00:00:00:00
E1 0x00:00:00:00
ok P15 B4
However, I am a bit suspicious that SPI configuration is not working, as the output of this command never seems to change.
marcio-ao
All 55 comments
It looks like even after a M17 (enable steppers), M122 still shows the stepper as disabled.
marcio-ao
on 4 Oct 2018
I also have problems using the TMC2130 on my STM32F7 board and the latest Marlin (using hardware SPI). The stepper also right now seem to run too slow (I need to adjust the steps / mm by *16) and the sensorless homing seems not to work.
Haven't had anymore time to look further into the problem though.
hasenbanck
on 4 Oct 2018
@hasenbanck: Okay, I changed the title to reflect the fact that it may not be related to TMC_USE_SW_SPI. Could you maybe run M122 and post your output?
marcio-ao
on 4 Oct 2018
Sure, here you go. I configured 16 microsteps without interpolation:
>>> M122
SENDING:M122
X Y Z E
Enabled false false false false
Set current 600 600 600 600
RMS current 596 596 596 596
MAX current 840 840 840 840
Run current 20/31 20/31 20/31 20/31
Hold current 10/31 10/31 10/31 10/31
CS actual 10/31 10/31 10/31 10/31
PWM scale 1 1 1 1
vsense 1=.18 1=.18 1=.18 1=.18
stealthChop true true true true
msteps 16 16 16 16
tstep 1048575 1048575 1048575 1048575
pwm
threshold 0 0 0 0
[mm/s] - - - -
OT prewarn false false false false
OT prewarn has
been triggered false false false false
off time 3 3 3 3
blank time 24 24 24 24
hysteresis
-end 2 2 2 2
-start 3 3 3 3
Stallguard thrs 0 0 0 0
DRVSTATUS X Y Z E
stallguard
sg_result 0 0 0 0
fsactive
stst X X X X
olb
ola
s2gb
s2ga
otpw
ot
Driver registers:
X 0x80:0A:00:00
Y 0x80:0A:00:00
Z 0x80:0A:00:00
E 0x80:0A:00:00
@hasenbanck: In your case, it appears you are getting values back from the driver.
marcio-ao
on 4 Oct 2018
Yeah, seems like it. But I think we have at least one problem in common (incorrect microstepping).
hasenbanck
on 4 Oct 2018
Microstepping reported as 256 is likely an issue where the SPI response was 00:00:00:00, which is then interpreted as such.
It's entirely possible the SW SPI implementation got broken somehow. Though I didn't really change anything in it from library to library.
teemuatlut
on 4 Oct 2018
@teemuatlut: That's what I suspect for my case, that the SPI response is all zero. It looks like @hasenbanck may have a different problem. The plot thickens...
marcio-ao
on 4 Oct 2018
@teemuatlut: I put some print statements in "TMC2130Stepper.cpp" and everything is coming back zero:
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
X Y Z E E1
Enabled Soft SPI Read:4, 0
Soft SPI Read:108, 0
false Soft SPI Read:4, 0
Soft SPI Read:108, 0
false Soft SPI Read:4, 0
Soft SPI Read:108, 0
false Soft SPI Read:4, 0
Soft SPI Read:108, 0
false Soft SPI Read:4, 0
Soft SPI Read:108, 0
false
Set current 950 950 960 960 960
RMS current Soft SPI Read:108, 0
923 Soft SPI Read:108, 0
923 Soft SPI Read:108, 0
923 Soft SPI Read:108, 0
923 Soft SPI Read:108, 0
923
MAX current Soft SPI Read:108, 0
1301 Soft SPI Read:108, 0
1301 Soft SPI Read:108, 0
1301 Soft SPI Read:108, 0
1301 Soft SPI Read:108, 0
1301
Run current 17/31 17/31 17/31 17/31 17/31
Hold current 8/31 8/31 8/31 8/31 8/31
CS actual Soft SPI Read:111, 0
0/31 Soft SPI Read:111, 0
0/31 Soft SPI Read:111, 0
0/31 Soft SPI Read:111, 0
0/31 Soft SPI Read:111, 0
0/31
PWM scale Soft SPI Read:113, 0
0 Soft SPI Read:113, 0
0 Soft SPI Read:113, 0
0 Soft SPI Read:113, 0
0 Soft SPI Read:113, 0
0
vsense Soft SPI Read:108, 0
0=.325 Soft SPI Read:108, 0
0=.325 Soft SPI Read:108, 0
0=.325 Soft SPI Read:108, 0
0=.325 Soft SPI Read:108, 0
0=.325
stealthChop Soft SPI Read:0, 0
false Soft SPI Read:0, 0
false Soft SPI Read:0, 0
false Soft SPI Read:0, 0
false Soft SPI Read:0, 0
false
msteps Soft SPI Read:108, 0
256 Soft SPI Read:108, 0
256 Soft SPI Read:108, 0
256 Soft SPI Read:108, 0
256 Soft SPI Read:108, 0
256
tstep Soft SPI Read:18, 0
0 Soft SPI Read:18, 0
0 Soft SPI Read:18, 0
0 Soft SPI Read:18, 0
0 Soft SPI Read:18, 0
0
pwm
threshold 109 109 527 62 62
[mm/s] Soft SPI Read:108, 0
1160.55 Soft SPI Read:108, 0
1160.55 Soft SPI Read:108, 0
48.01 Soft SPI Read:108, 0
485.79 Soft SPI Read:108, 0
485.79
OT prewarn Soft SPI Read:111, 0
false Soft SPI Read:111, 0
false Soft SPI Read:111, 0
false Soft SPI Read:111, 0
false Soft SPI Read:111, 0
false
OT prewarn has
been triggered false false false false false
off time Soft SPI Read:108, 0
0 Soft SPI Read:108, 0
0 Soft SPI Read:108, 0
0 Soft SPI Read:108, 0
0 Soft SPI Read:108, 0
0
blank time Soft SPI Read:108, 0
16 Soft SPI Read:108, 0
16 Soft SPI Read:108, 0
16 Soft SPI Read:108, 0
16 Soft SPI Read:108, 0
16
hysteresis
-end Soft SPI Read:108, 0
-3 Soft SPI Read:108, 0
-3 Soft SPI Read:108, 0
-3 Soft SPI Read:108, 0
-3 Soft SPI Read:108, 0
-3
-start Soft SPI Read:108, 0
1 Soft SPI Read:108, 0
1 Soft SPI Read:108, 0
1 Soft SPI Read:108, 0
1 Soft SPI Read:108, 0
1
Stallguard thrs 6 5 0 0 0
DRVSTATUS X Y Z E E1
stallguard Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
sg_result Soft SPI Read:111, 0
0 Soft SPI Read:111, 0
0 Soft SPI Read:111, 0
0 Soft SPI Read:111, 0
0 Soft SPI Read:111, 0
0
fsactive Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
stst Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
olb Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
ola Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
s2gb Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
s2ga Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
otpw Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
ot Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Driver registers:
X 0xSoft SPI Read:111, 0
00:00:00:00
Y 0xSoft SPI Read:111, 0
00:00:00:00
Z 0xSoft SPI Read:111, 0
00:00:00:00
E 0xSoft SPI Read:111, 0
00:00:00:00
E1 0xSoft SPI Read:111, 0
00:00:00:00
ok P15 B4
Soft SPI Read:111, 0
Soft SPI Read:111, 0
Soft SPI Read:111, 0
I also printed out the "mosi_pin", "miso_pin" and "sck_pin" in SW_SPIClass and they matched the numbers in pins_ARCHIM2 (28, 26, 27). So, I'm fairly stumped at this point.
marcio-ao
on 4 Oct 2018
I tried to pinpoint down the problem on my side. As it seems we have two problems as of right now:
- @marcio-ao and @hasenbanck (me) having the problem that the stepper are *16 times too slow
- @marcio-ao having the problem with setting up the TCM2130 stepper
Maybe I and @marcio-ao face different problems with similar symptoms.
On my side the setup process seems to work. I can set stealthchop etc and it makes a audible difference. Also sensorless homing seems to work, but I need to use more force to trigger it, and when increasing the step my mm by factor of 16, I can't create enough force to trigger it anymore.
I also thought that maybe I myself created the problem on my side with fcf6d127fd644aeb754724adcb296b94de1b2ba3 , but reverting that change didn't fix the problem (and I'm also pretty sure that the implementation is correct).
I will try to debug the problem further.
hasenbanck
on 5 Oct 2018
Okay, I tested, if I have the same problems with the commit BEFORE c3229e1b3461b6da8373e7a24a7eeb131912a15b . I rebased the current STM32 HAL against the commit 2abf3d258d119e337b1fadefb1085e7b667d7686 (since it was included after the TMC library change).
In this configuration the stepper are working fine with the correct steps/mm settings.
So the breaking change for me must have happened after 2abf3d258d119e337b1fadefb1085e7b667d7686
hasenbanck
on 5 Oct 2018
Okay, so some good (and bad) news. This morning I pulled the latest upstream changes and the good news is that SPI is working for me again. I now get plausible output from the M122 command:
X Y Z E E1
Enabled true false true false false
Set current 950 950 960 960 960
RMS current 923 923 923 923 923
MAX current 1301 1301 1301 1301 1301
Run current 17/31 17/31 17/31 17/31 17/31
Hold current 8/31 8/31 8/31 8/31 8/31
CS actual 8/31 8/31 8/31 8/31 8/31
PWM scale 30 0 29 0 0
vsense 0=.325 0=.325 0=.325 0=.325 0=.325
stealthChop true true true true true
msteps 16 16 16 16 16
tstep 1048575 1048575 1048575 1048575 1048575
pwm
threshold 109 109 527 62 62
[mm/s] 72.53 72.53 3.00 30.36 30.36
OT prewarn false false false false false
OT prewarn has
been triggered false false false false false
off time 3 3 3 3 3
blank time 24 24 24 24 24
hysteresis
-end 2 2 2 2 2
-start 3 3 3 3 3
Stallguard thrs 6 5 0 0 0
DRVSTATUS X Y Z E E1
stallguard
sg_result 0 0 0 0 0
fsactive
stst X X X X X
olb X
ola
s2gb
s2ga
otpw
ot
Driver registers:
X 0xC0:08:00:00
Y 0x80:08:00:00
Z 0x80:08:00:00
E 0x80:08:00:00
E1 0x80:08:00:00
However, just like @hasenbanck, my stepper seems to be operating at 256 microsteps even thought M122 reports otherwise. So the good news, is that now there is just one problem rather than two :)
marcio-ao
on 5 Oct 2018
Try using my personal vanilla branch:
https://github.com/teemuatlut/Marlin/tree/0ce562c1ddeda2be4f906442767a2618b0490916
It includes a raw debugging command for M122.
https://github.com/teemuatlut/Marlin/commit/e67ac7cd2510c41614e971178175eab2534cc690
Also a quick fix for the current compile issue but that's just for your convenience.
As per the datasheet, bit 24..27 should say 0b0100 = 0x4.
teemuatlut
on 5 Oct 2018
So I just grepped "X_MICROSTEPS" in the bugfix-2.0.x branch, and aside it being in the configuration files, it is referenced nowhere else. I believe that might be the problem?
marcio-ao
on 5 Oct 2018
The wonderful thing about preprocessor macros and string concatenation is not being able to find the strings you're looking for because they are formed as ST##_MICROSTEPS =)
teemuatlut
on 5 Oct 2018
@teemuatlut: Ahhhh. Those macros made a fool out of me again :) I'll put some print statements in tmc_init and see if the values are getting to the right place.
Is there anyway to change the TMC2130 microstepping outside of the initialization? I noticed that M350 does not exist in my build.
marcio-ao
on 5 Oct 2018
No, I'd consider microstep settings to be of type "set it and forget it" and thus in my mind belong in the configuration files rather than to a gcode command.
teemuatlut
on 5 Oct 2018
@teemuatlut : On the Archim board, it is impossible to see print statements at initialization since the serial connection drops every time you restart the board. Frustrating.
marcio-ao
on 5 Oct 2018
I added the following code to my LCD code so I could trigger it manually after startup:
SERIAL_ECHOLNPAIR("Starting to set microsteps to ", 16);
stepperX.microsteps(16);
SERIAL_ECHOLNPAIR("Done setting microsteps to ", 16);
I also modified byte SW_SPIClass::transfer(uint8_t ulVal, uint8_t ulBitOrder) with the following:
SERIAL_ECHOPAIR("SPI Tranfer: out = ", ulVal);
SERIAL_ECHOLNPAIR(", in = ", value);
And now I see the following when I trigger the microstepping command:
Starting to set microsteps to 16
SPI Tranfer: out = 236, in = 248
SPI Tranfer: out = 64, in = 128
SPI Tranfer: out = 1, in = 8
SPI Tranfer: out = 5, in = 0
SPI Tranfer: out = 35, in = 0
Done setting microsteps to 16
According to the datasheet, the first byte of the SPI transmission is supposed to be the address of the register. 236 is 0xEC, while I think the register we are trying to access is CHOPCONF, which has a value of 0x6C.
marcio-ao
on 5 Oct 2018
Oh, duh. The high order bit is the R/W flag. So it looks like the following bit string is being sent:
11101100 01000000 00000001 00000101 00100011
1 - Write bit
1101100 - CHOPCONF register, 0x6C
0 - reserve, should be 0
1 - diss2g, Short to GND protection is disabled
0 - dedge, disabled
0 - intpol, disabled
0000 - native 256 microstepping
...
marcio-ao
on 5 Oct 2018
The values don't make sense. When the microstepping is set to 16, mres should be set to 4, binary 0100 rather than 0000 as it is being set.
marcio-ao
on 5 Oct 2018
Can you give me the raw M122 output?
Also worth checking the shadow register. Need to modify the library for that.
teemuatlut
on 5 Oct 2018
I would need to compile new FW without my debugging statements, because the interspersed "SPI Transfer" messages are making it illegible.
However, I think regardless, the bit sequence being sent by "stepperX.microstepping(16)" appears to be incorrect after the address byte.
marcio-ao
on 5 Oct 2018
Anyhow, the comment a few comments above will show you the M122 output (https://github.com/MarlinFirmware/Marlin/issues/12005#issuecomment-427405147)
marcio-ao
on 5 Oct 2018
I'd like to know the chopconf shadow register and the raw response when reading it.
teemuatlut
on 5 Oct 2018
If you know exactly what you are looking for and are able to read in between the lines, you might be able to pick it out of this log.
marcio-ao
on 5 Oct 2018
Also worth checking the shadow register. Need to modify the library for that.
How do I do that?
marcio-ao
on 5 Oct 2018
Okay, I modified my SPI debugging statments so they only run when stepperX.microstepping(16) is called. So here is the M122 right after the printer is started, then I trigger an extra call to stepperX.microstepping(16), then I run M122 again:
echo:TMC2130 StallGuard threshold:
echo: M914 X6 Y5
echo:Linear Advance:
echo: M900 T0 K0.00
M900 T1 K0.00
echo:Filament load/unload lengths:
echo: M603 T0 L40.00 U80.00
echo: M603 T1 L40.00 U80.00
ok P15 B4
Starting USB host
USB host initialized
X Y Z E E1
Enabled false false true false false
Set current 950 950 960 960 960
RMS current 923 923 923 923 923
MAX current 1301 1301 1301 1301 1301
Run current 17/31 17/31 17/31 17/31 17/31
Hold current 8/31 8/31 8/31 8/31 8/31
CS actual 8/31 8/31 8/31 8/31 8/31
PWM scale 0 0 29 0 0
vsense 0=.325 0=.325 0=.325 0=.325 0=.325
stealthChop true true true true true
msteps 16 16 16 16 16
tstep 1048575 1048575 1048575 1048575 1048575
pwm
threshold 109 109 527 62 62
[mm/s] 72.53 72.53 3.00 30.36 30.36
OT prewarn false false false false false
OT prewarn has
been triggered false false false false false
off time 3 3 3 3 3
blank time 24 24 24 24 24
hysteresis
-end 2 2 2 2 2
-start 3 3 3 3 3
Stallguard thrs 6 5 0 0 0
DRVSTATUS X Y Z E E1
stallguard
sg_result 0 0 0 0 0
fsactive
stst X X X X X
olb
ola
s2gb
s2ga
otpw
ot
Driver registers:
X 0x80:08:00:00
Y 0x80:08:00:00
Z 0x80:08:00:00
E 0x80:08:00:00
E1 0x80:08:00:00
ok P15 B4
Starting to set microsteps to 16
SPI Tranfer: out = 236, in = 248
SPI Tranfer: out = 64, in = 128
SPI Tranfer: out = 1, in = 8
SPI Tranfer: out = 5, in = 0
SPI Tranfer: out = 35, in = 0
Done setting microsteps to 16
X Y Z E E1
Enabled false false true false false
Set current 950 950 960 960 960
RMS current 923 923 923 923 923
MAX current 1301 1301 1301 1301 1301
Run current 17/31 17/31 17/31 17/31 17/31
Hold current 8/31 8/31 8/31 8/31 8/31
CS actual 8/31 8/31 8/31 8/31 8/31
PWM scale 0 0 29 0 0
vsense 0=.325 0=.325 0=.325 0=.325 0=.325
stealthChop true true true true true
msteps 16 16 16 16 16
tstep 1048575 1048575 1048575 1048575 1048575
pwm
threshold 109 109 527 62 62
[mm/s] 72.53 72.53 3.00 30.36 30.36
OT prewarn false false false false false
OT prewarn has
been triggered false false false false false
off time 3 3 3 3 3
blank time 24 24 24 24 24
hysteresis
-end 2 2 2 2 2
-start 3 3 3 3 3
Stallguard thrs 6 5 0 0 0
DRVSTATUS X Y Z E E1
stallguard
sg_result 0 0 0 0 0
fsactive
stst X X X X X
olb
ola
s2gb
s2ga
otpw
ot
Driver registers:
X 0x80:08:00:00
Y 0x80:08:00:00
Z 0x80:08:00:00
E 0x80:08:00:00
E1 0x80:08:00:00
ok P15 B4
SERIAL_PRINT("stepperX = 0x");
SERIAL_PRINTLN(stepperX.CHOPCONF_register.sr, HEX);
You need to remove protected: from class TMC2130Stepper to compile.
teemuatlut
on 5 Oct 2018
SERIAL_PRINT doesn't exist for me, so I used SERIAL_ECHOLNPAIR, so the register values below are decimal and need to be converted to hex.
I show the original M122, then I called stepperX.microstepping(16) followed by stepperX.microstepping(8)
X Y Z E E1
Enabled false false true false false
Set current 950 950 960 960 960
RMS current 923 923 923 923 923
MAX current 1301 1301 1301 1301 1301
Run current 17/31 17/31 17/31 17/31 17/31
Hold current 8/31 8/31 8/31 8/31 8/31
CS actual 8/31 8/31 8/31 8/31 8/31
PWM scale 0 0 29 0 0
vsense 0=.325 0=.325 0=.325 0=.325 0=.325
stealthChop true true true true true
msteps 16 16 16 16 16
tstep 1048575 1048575 1048575 1048575 1048575
pwm
threshold 109 109 527 62 62
[mm/s] 72.53 72.53 3.00 30.36 30.36
OT prewarn false false false false false
OT prewarn has
been triggered false false false false false
off time 3 3 3 3 3
blank time 24 24 24 24 24
hysteresis
-end 2 2 2 2 2
-start 3 3 3 3 3
Stallguard thrs 6 5 0 0 0
DRVSTATUS X Y Z E E1
stallguard
sg_result 0 0 0 0 0
fsactive
stst X X X X X
olb
ola
s2gb
s2ga
otpw
ot
Driver registers:
X 0x80:08:00:00
Y 0x80:08:00:00
Z 0x80:08:00:00
E 0x80:08:00:00
E1 0x80:08:00:00
ok P15 B4
stepperX = 1073808675 (0x40010523)
Starting to set microsteps to 16
SPI Tranfer: out = 236, in = 248
SPI Tranfer: out = 64, in = 128
SPI Tranfer: out = 1, in = 8
SPI Tranfer: out = 5, in = 0
SPI Tranfer: out = 35, in = 0
Done setting microsteps to 16
stepperX = 1073808675 (0x40010523)
Starting to set microsteps to 8
SPI Tranfer: out = 236, in = 248
SPI Tranfer: out = 80, in = 64
SPI Tranfer: out = 1, in = 1
SPI Tranfer: out = 5, in = 5
SPI Tranfer: out = 35, in = 35
Done setting microsteps to 8
stepperX = 1342244131 (0x50010523)
X Y Z E E1
Enabled false false true false false
Set current 950 950 960 960 960
RMS current 923 923 923 923 923
MAX current 1301 1301 1301 1301 1301
Run current 17/31 17/31 17/31 17/31 17/31
Hold current 8/31 8/31 8/31 8/31 8/31
CS actual 8/31 8/31 8/31 8/31 8/31
PWM scale 0 0 28 0 0
vsense 0=.325 0=.325 0=.325 0=.325 0=.325
stealthChop true true true true true
msteps 8 16 16 16 16
tstep 1048575 1048575 1048575 1048575 1048575
pwm
threshold 109 109 527 62 62
[mm/s] 36.27 72.53 3.00 30.36 30.36
OT prewarn false false false false false
OT prewarn has
been triggered false false false false false
off time 3 3 3 3 3
blank time 24 24 24 24 24
hysteresis
-end 2 2 2 2 2
-start 3 3 3 3 3
Stallguard thrs 6 5 0 0 0
DRVSTATUS X Y Z E E1
stallguard
sg_result 0 0 0 0 0
fsactive
stst X X X X X
olb
ola
s2gb
s2ga
otpw
ot
Driver registers:
X 0x80:08:00:00
Y 0x80:08:00:00
Z 0x80:08:00:00
E 0x80:08:00:00
E1 0x80:08:00:00
ok P15 B4
Edited the above with converted hex values.
marcio-ao
on 5 Oct 2018
I think the bit-field CHOPCONF_t may have gaps in it. Playing around with "__attribute__ ((packed))" to see if i can fix this.
marcio-ao
on 5 Oct 2018
D'oh! My fault, I had inadvertently dropped "-fpack-struct" from my Makefile. This was because I was getting a bunch of the following warnings and I thought the compiler was telling me that option was not necessary:
warning: #pragma pack has no effect with -fpack-struct - ignored [-Wpragmas]
Turns out that option is absolutely necessary, unless all code that needs it has a "#pragma pack", which isn't the case right now.
marcio-ao
on 5 Oct 2018
@teemuatlut : Printer works now! But I get a lot of warnings related to packed structs. Not sure if there is anything here worth looking at, but I am attaching it just in case.
marcio-ao
on 5 Oct 2018
Is -fpack-struct needed now? I don鈥檛 think that the core for STM32 is using
it by default.
Mit freundlichen Gr眉脽en
Nils Hasenbanck
hasenbanck
on 5 Oct 2018
Should I add #pragma pack to the bitfield headers?
teemuatlut
on 5 Oct 2018
I think that would be best? If that option is needed, then every build
environment would need to include it for an ARM environment. And as of
right now, we know of one (stm32duino) that doesn鈥檛 ship with it in
default. I won鈥檛 be able to test it until tomorrow though.
Mit freundlichen Gr眉脽en
Nils Hasenbanck
hasenbanck
on 5 Oct 2018
@teemuatlut: I think adding the "#pragma pack" makes sense. I only say that because it's used elsewhere and seems to solve the problem. I know "platform.io" is the recommended build system, but there are always going to be folks using the Arduino IDE or the Makefile. If "#pragma pack" helps those folks, I think it should be included.
@hasenbanck: What are you using to compile?
marcio-ao
on 5 Oct 2018
I'm using Eclipse with Sloeber. But that is using the platform.txt of the
Arduino core I'm using. So it's essentially an Arduino environment.
hasenbanck
on 5 Oct 2018
@hasenbanck: That's what I figured. Arduino IDE will not include "-fpack-struct". I would prefer to see all bitfields that need to be aligned to have "#pragma pack" so compatibility can be maintained. Once those are in, I'll probably remove the "-fpack-struct" from my Makefile so I'll be made aware if anything else in Marlin breaks.
marcio-ao
on 5 Oct 2018
So taking a look at the warnings log I posted, it looks like "#pragma pack" is only used in a few sam libraries and a couple places in the HAL_DUE. So whatever is done there probably ought to be done in the TMC library for compatibility with the DUE.
marcio-ao
on 5 Oct 2018
Library v0.2.1 released with #pragma pack(1).
teemuatlut
on 5 Oct 2018
@teemuatlut: That's weird. I was about to test your new release with the #pragmas, but now I am finding the board won't boot at all without the -fpack-struct (but does startup with -fpack-structs). I don't think it was anything you did with the TMC library update. I think something else is incompatible with unpacked structs now. Somehow I feel like this will be something that will be showing up quite often on DUE.
marcio-ao
on 5 Oct 2018
I don't think there is anything in Marlin that would cause a 32bit build not to run if pack_struct is not enabled, the option can hit performance pretty hard so packing to byte boundary should only be used on specific data structures when absolutely necessary.
p3p
on 5 Oct 2018
@teemuatlut: I found the cause. In your headers, you should do at the top:
#pragma pack(push, 1)
and at the end:
#pragma pack(pop)
If you don't do that, the pragma leaks to other code and causes chaos. I confirmed that changing "#pragma pack(1)" to these bracketed calls fixed the problem.
Reference: https://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/Structure_002dPacking-Pragmas.html
marcio-ao
on 5 Oct 2018
@p3p: @teemuatlut is using bit-fields to assemble registers for the TMC2130 for transmission via SPI, so pack-structs is absolutely necessary, but I guess the issue is making sure the pragmas don't leak and affect other unreleated code.
marcio-ao
on 5 Oct 2018
I'm somewhat concerned that even pack(1) is not correct for all TMC registers. There are fields in there which do not even fall on a byte boundary, or which span byte boundaries.
marcio-ao
on 6 Oct 2018
I think we want to emulate the value of "-fpack-struct", which according to this documentation, packs the structure without holes. I'm beginning to think that this cannot be accomplished with #pragmas, unless the pack argument can be zero.
marcio-ao
on 6 Oct 2018
@marcio-ao I know, it's one of the situations it should be used but only wrapped around the specific data structures that needed it, I was responding directly to you worrying that packing would be a recurring issue with the DUE platform,
There are fields in there which do not even fall on a byte boundary
bit fields are padded at the end to the boundary parameter so it should be fine,
think we want to emulate the value of "-fpack-struct", which according to this documentation, packs the structure without holes
without holes means pack to byte boundary, so is equivalent to pack 1, there is no sub byte packing, I assume this is all testing on avr which is packed at byte boundary by default.
p3p
on 6 Oct 2018
@p3p: Yes, this all works fine under AVR, so it looks like byte packing is the answer. Microstepping works fine with #pragma pack(push, 1) and #pragma pack(pop) around the specific data structures. Allowing it to leak beyond the header file does lead to an unbootable board, however, so @teemuatlut will need to make a new release of the TMCStepper lib to fix that.
marcio-ao
on 6 Oct 2018
Allowing it to leak beyond the header file does lead to an unbootable board,
well that will probably break binary compatibility with the other half of the binary so not really surprising it doesn't boot
p3p
on 6 Oct 2018
teemuatlut
on 6 Oct 2018
v0.2.2 seems to fix the problem on my side.
hasenbanck
on 6 Oct 2018
I think the microstepping issue should be fixed when specifying the pack pragma. I tested with a Re-Arm and a single TMC2130. Board boots, response was good and the motor moved a full circle with X+40.
teemuatlut
on 7 Oct 2018
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
![github-actions[bot] picture](https://avatars2.githubusercontent.com/in/15368?v=4&s=40)
github-actions[bot]
on 7 Aug 2020
Related issues
StefanBruens
路
4Comments
Kaibob2
路
4Comments
Anion-anion
路
3Comments
modem7
路
3Comments
jerryerry
路
4Comments
Most helpful comment
Library v0.2.1 released with
#pragma pack(1).