Improved STMicro L64XX stepper driver support

[Bob-the-Kuhn]

This PR replaces PR #13053 and #13498.

This PR adds support for the L6474, L6480 & powerSTEP01 steppers from STmicro. The L6480 is a subset of the powerSTEP01.

The code changes are a result of the following differences between the L6470, L6474 and the powerSTEP01/L6480:

• Additional registers
• Register address changes
• Changes to bit locations and definitions

Also added the ability to select the slew rate used by the drivers via Configuration_adv.h option.

---

This PR uses the "helper" method of linking external SPI routines to the Arduino-L6470 library.

This PR requires a change to the Arduino L6470 library. Here are the new library files:
Arduino-L6470 2020-01-03.zip

The Arduino L6470 library changes are in PR 14.

The Arduino L6470 library changes that were made are:

• Added additional definitions and #if statements to select the appropriate definitions.
• Changed the Overcurrent Detection threshold and Stall threshold commands to allow for variable numbers of bits and variable "mA per count" constants.
• Created subclasses for each chip.

---

[Bob-the-Kuhn]

This PR is almost ready to be merged. All files have been updated. The code has been tested on a STEVAL_3DP001V1 board.

The only open item is updating the Arduino-L6470 library. That update will probably affect the link to the library which will affect platformio.ini.

[kurtnelle]

Will this include the powerSTEP01's ability to be a dual independent dc motor / heater driver?

[Bob-the-Kuhn]

I've used this code with a stack of six X-NUCLEO-IHM03A1 boards. Each board has a single powerSTEP01 on it.

I'm confused about the dual independent dc motor / heater driver portion. As far as I can tell each powerSTEP01 can drive one stepper and does not have any provision to be a heater driver.

I used them with 2A NEMA 23 steppers on a 24V system. The powerSTEP01 chips didn't even get warm.

[Bob-the-Kuhn]

Why the interest in powerSTEP01?

I've switched my system to the TMC5160 drivers. They also can drive my steppers without a heat sink and have a better interface. Now I don't need any special interface/adapters and just use standard controller boards.

[kurtnelle]

The powerStep01 can run up to 85V. This gives headroom for future voltage increases once we all go to 48V power supplies as standard. It can also do both voltage and current mode driving. In essence it can drive any size stepper motor that you can find.

I'll have to double check where I saw that you can control the dual full bridge drivers independently.

[Bob-the-Kuhn]

BIG steppers

I take it that you are looking at building a CNC machine. Usually big means slow which is not wanted on a 3D printer.

My code puts the chip into the STEP_LOCK mode. See the ...\Marlin\src\libs\L6470\000_l6470_read_me.md file for an explanation of how the code works and the hardware/software interaction.

Marlin is written around the STEP/DIR/ENABLE interface. Taking advantage of the upper level comands/modes available in the L64xx series would require throwing away almost everything down stream from the planner.

Looking at the data sheet I see just the usual 4 stepper motor outputs. The registers have no provisions for an independent second stepper channel.

Perhaps you were remembering something from the NUCLEO-IHM02A1. That has two L6470 chips on one board so can control two steppers independently.

[Bob-the-Kuhn]

A word of caution on the L64xx chips. When they go bad they tend to take other devices with them. I suggest putting individual fuses on the Vmot for each chip. Maybe that'll localize any damage.

I started out with three of the dual L6470 NUCLEO-IHM02A1 boards. I never was able to properly heat sink them. Everythig was OK when doing bech testing with Nema17 steppers. Soon after tying into the five Nema23 steppers on my old printer/CNC hybrid, one of the L6470 chips literally spit out flames. The net result was all six of the L6470s were dead.

I then went to six of powerSTEP01 boards. Again bench testing with Nema17 was good but when doing an early test print the system halted and the 24V wiring to the powerSTEP01 stack started smoking. That took out 4 of the 6 powerSTEP01 chips, the DUE CPU board and my RAMPS-FD-V2 shield. The strange thing is the SPI portion of all the chips still works but only two will spin a motor.

I finally gave up on using my CNC machine as a 3D printer. I've been using a TEVO Little Monster now for 4-5 months.

[kurtnelle]

I've used L6470s. They have a thermal warning and thermal shutdown. If they started smoking then something else was wrong in the design of the PCB or the motor phase resistance was really, really low. I believe you that they smoked though. Large Format 3d printers require large stepper motors, which need a lot of power. Currently the only way to get that is with CNC current mode drivers. the powerStep01's current mode driving would allow a user to scale up without adding too much cost, in the driver department.

[Bob-the-Kuhn]

Reverting echo_yes_no back to the Boolean form will cause problems when looking for error bits in the upper 16 bits of a 32 bit register. These will always evaluate to false (NO). If I do a echo_yes_no(0x10000000 & 0xF0000000) evalautes to false/NO.

Maybe change the 32 bit versions name to echo_yes_no_32 ?

[Bob-the-Kuhn]

I'll test the changes Thursday.

[thinkyhead]

The only open item is updating the Arduino-L6470 library.

We use a direct link to Arduino-L6470/archive/dev.zip now but we can add L64XX drivers to one or more of the CI tests and at the same time change it to refer to the 0.8.0 tag specifically.

[thinkyhead]

echo_yes_no(0x10000000 & 0xF0000000) evalautes to false/NO.

That is why I changed calls like this to use (0x10000000 & 0xF0000000) != 0 as the argument instead. For example…

echo_yes_no((status & _status_axis_ocd) != 0);

[thinkyhead]

Almost building successfully, but there's a strange error I can't figure out.

Marlin/src/module/stepper.cpp: In static member function 'static void Stepper::set_directions()':
Marlin/src/module/stepper.cpp:382:46: error: expected ')' before ';' token
       A##_APPLY_DIR(INVERT_##A##_DIR, false);  \
                                              ^
Marlin/src/module/stepper.cpp:391:5: note: in expansion of macro 'SET_STEP_DIR'
     SET_STEP_DIR(X); // A
     ^

There's no obvious place where a parenthesis has gone missing or even been changed somewhere before these lines. Adding an extra ) where it's complaining gives back a hilarious response: error: expected ';' before ')' token.

[Bob-the-Kuhn]

There is a boot loop. It may take a while to root cause it.

[thinkyhead]

There's always some new funky thing!

[Bob-the-Kuhn]

The 6239dac commit has all of Scott's changes plus fixes all known issues except the WDT problem.

---

OPEN ITEMS

• Fix boot loop problem when WDT is enabled.
• Auto Build - process-palette.json still points at the buildroot\share\atom directory BUT that directory doesn't exist in bugfix-2.0.1. Either the JSON needs to be updated or the directory needs to be restored.
• timers - PR Fix SKR Pro BLTouch conflicting timers #16499 moved the STM32F4xx STEP_TIMER from 5 to 6 because the BLTouch uses timer 5. That's OK for the STM32F407 but not for the STM32F401. On the F401 timers 6-8 do not exist and will throw a compile error if used. Hmmm .... looks like I need to investigate what timer is used on the STEVAL_3DP001V1 before I can make a firm recommendation on this. UPDATE TIM9 will work as the STEP_TIMER for both. The change in this PR to TIM9 can stay as is.

[Bob-the-Kuhn]

The BLTouch uses the servo timer which is defined in the variant. Right now STEVAL_3DP001V1 doesn't have one defined. I'll do a PR to update the STEVAL_3DP001V1 variant with a timer definition that won't cause problems.

I've sucessfully tested TIM9 as the STEPPER_TIMER on the F401 so TIM9 will work for the F407.

[Bob-the-Kuhn]

Merged my changes with Scott's and tested it on a L6474 system and a POWERSTEP01 system. I know of no issues that would stop this PR from being merged once Travis is happy.

There was a bug in the L6470 library. The correction has been combined with Scott's changes and the commit has been pushed to the PR. This change will need to be implemented before the code in this PR will run.

---

CHANGES:

• Configuration_adv.h - 1) added text to clarify the acceptable ranges of currents and 2) changed the "not in a chain" from "0" to "-1" to be consistent with TMC.
• When making decisions based on STATUS_LAYOUT, use defines from library rather than hard coded numbers
• Change from L6470_status_layout to L64xx_status_layout (just to get rid of another L6470 that wasn't needed) - UPDATE: I will back this change out so that the code in the PR will compile with the released 0.8.0.0 library.
• L64XX_Marlin.cpp - correct status bit inverting for L6470 & L7474
• M906.cpp - 1) correct calculation for STALL current on L6470, L6480 & powerstep , 2) change all SERIAL_ECHOxxx macros over to DEBUG_ECHOxxx macros and 3) changed all leading "ERROR" to "Test aborted" because host may react to seeing "ERROR" as the very first text on a line.

---

OPEN ITEMS:

• Library changes on PR 14 will need to be implemented. UPDATE: A new PR will be created and just the correction will be on it.
• The timers.h changes to make both STM32F401 and STM32F407 happy may be more compicated than I originally though. I'll start a separate PR to handle this issue.
• The analog inputs on my STEVAL_3DP001V1 board do not work. I don't think that is related to the timer issue. I'll pursue that as part of PR improved STEVAL_3DP001V1 support (add SERVO and TONE timers to variant) #16538

[Bob-the-Kuhn]

RATSSSS!!! Just saw that PR 14 has been merged & closed.

I'll create a new PR to make the needed library correction.

I'll also back out of the library PR and this PR the "Change from L6470_status_layout to L64xx_status_layout (just to get rid of another L6470 that wasn't needed)". It is the only library change that will keep the code in this PR from compiling. This will allow the library correction and this PR to proceed independently.

[Bob-the-Kuhn]

I couldn't find the correct repo/branch to create a PR for the library change.

Scott - can you push these two files to the correct location?

L6470.zip

---

Here's the change comments:

L6470.h:

• Change L6480_STATUS_LAYOUT define from 3 to 2 just beause I like the sequence 0, 1, 2 better than 0, 1, 3
• Add "L6480::" to "L6470_status_layout" in both L6480 classes.
• In both powerSTEP01 classes change OCD_TH_MAX and STALL_TH_MAX from 5 to 31
• Don't know if this is needed - in all classes, add class before OCD_CURRENT_CONSTANT_INV and
• :STALL_CURRENT_CONSTANT_INV
• Remove note to myself.

L6470.cpp

• Update comments to include L6474 for cases 64XX_CONFIG_A, L64XX_STATUS_A, L64XX_CONFIG_B & L64XX_STATUS_B
• Change logic for the cases so that it's easy to determine how L6474 gets the correct register usage.

[Bob-the-Kuhn]

I'm happy with the PR as is. I'm OK with it being merged.

The open items will be pursued independent of this PR.

---

OPEN ITEMS:

• Library changes to 0.8.0 need to be implemented. Looks like Scott will need to do this.
• The timers.h changes to make both STM32F401 and STM32F407 happy may be more compicated than I originally though. I'll start a separate PR to handle this issue or include it in PR improved STEVAL_3DP001V1 support (add SERVO and TONE timers to variant) #16538 .
• The analog inputs on my STEVAL_3DP001V1 board do not work. I don't think that is related to the timer issue. I'll pursue that as part of PR improved STEVAL_3DP001V1 support (add SERVO and TONE timers to variant) #16538

[thinkyhead]

RATSSSS!!! Just saw that PR 14 has been merged & closed.

For convenience I also added to Arduino-L6470 the missing 0.7.0 tag and a new 0.8.0 tag which is directly referenced in the updated platformio.ini file. Going forward I'll make sure to refer to these tags and not to master.zip or dev.zip.

[thinkyhead]

I couldn't find the correct repo/branch to create a PR for the library change.

newdev

I created a new branch for development called newdev and the 0.8.0 tag currently points to the HEAD of that branch. The dev branch can't be changed in any significant ways because (whoops!) the Marlin 2.0.0 and 2.0.1 releases refer directly to dev.zip instead of the version tag zip.

The contents of newdev will get merged into master soon. At that point the 0.8.0 tag won't need to be changed, because it will still refer to the same commit, but now master and newdev share it.

The other branches (test, dev_handler_ptr, dev_helper_class) will also go away, since all their version tags' commits also exist in the master branch.

[thinkyhead]

Scott - can you push these two files to the correct location?

Merged into newdev and moved up the 0.8.0 tag. So everything is ready for this to be merged.

[thinkyhead]

I'll have to re-fix the M906 output and any others that got reverted by new commits before this will be ready.

An important thing to remember is that if you try to SERIAL_ECHO something defined as a char (or any 8-bit type) it will print a char, which is not what you want. This is why we cast to int so much inside of SERIAL_ECHOPAIR and other serial calls.

[thinkyhead]

change all SERIAL_ECHOxxx macros over to DEBUG_ECHOxxx macros

Actually, there is a difference, and the items I specifically modified to DEBUG_* versions were the ones wrapped in the L6470_CHITCHAT option, which will only ever be displayed in the case of that option, and which would be defined as NOOP otherwise. The rest of the SERIAL_* macros should be left as they are, since they are meant to apply whether you have L6470_CHITCHAT turned on or not.

If there are some which should only apply under L6470_CHITCHAT then these particular items may be changed to DEBUG_*, but I believe that most of them should be left unchanged.

[thinkyhead]

Rebased and squashed. This will probably be merged very soon. I believe the behavior of M906 is now correct, with a good amount of serial output without L6470_CHITCHAT and even more when that option is enabled. To get your working copy updated…

git fetch origin
git checkout L64XX-helper-PR
git reset --hard origin/L64XX-helper-PR

[Bob-the-Kuhn]

I've downloaded and tested the new code. Everything works as expected.

Time to merge this PR. I'm happy with it.

[thisiskeithb]

@Bob-the-Kuhn: Have you seen #16604? We've had to revert the STEP_TIMER change to get our TMC drivers working correctly on STM32F40*.