Feedback on MRR ESPE

[vivian-ng]

A prototype of the MRR ESPE board, which uses 2 x 74HC595 shift registers to implement I2S stepper stream for the ESP32, is out. Most of the board design is based on the MRR ESPA board (many many lessons learnt there) while the I2S stepper stream is courtesy of simon-jouet.

I will be testing it with luc-github's Marlin fork (which comes with his ESP3D embedded) once he has managed to rebase his fork to incorporate the latest I2S-related updates from the main Marlin repo.

I can probably improve the use of the "real estate" more, and I probably should.

[vivian-ng]

A quick update on this board.

Basic functionality has been checked, short of an actual test print. The motors can move, the heaters (heat bed and hot end) can work. Temperature readings seem to be fluctuating slightly, but nothing that will cause issues with prints, I think. The board also works with the Creality LCD controller. I have tried to connect a Reprap full graphics smart controller (aka LCD12864), and it works.

One thing to note: Linear Advance does not work with I2S. This probably has to do with how linear advance is implemented now. But it should not be an issue for those using direct drive extruders.

The next step is to clean up the PCB layout to make better use of the real estate. Since everything seems to be working now, the breakout pins will be reduced to only those that are not hardwired to something already.

[vivian-ng]

The next version of this board will add further functionality using 4x74HC595 shift registers. I will also be using the TTL version of the shift registers to see if it helps improve reliability. But the TTL version costs like 4 times more than the CMOS version... which drives up the BOM cost.

Preliminary testing has shown that the I2S output pins can be used for PWM output, which means it can be used to drive the various MOSFETs (heated bed, hot end, fans). This frees up pins on the ESP32, which potentially can then be used for the CS pins and UART pins for Trinamic drivers.

Stay tuned for 5 stepper drivers, multiple fan outputs, and 3 thermistors!

[vivian-ng]

v0.3 of the board (will release files soon) has been tested to compile with TMC2130 support for Marlin 2.0 bugsfix. A native ESP32 pin needs to be used for the CS pin, though. For example, GPIO21 (SDA) or GPIO22 (SCL).

TMC2208 and TMC2209 drivers will need a bit more work, since they will likely need to use software serial, and there are currently issues with compiling software serial on TMCStepper library: ESP32 is no SoftwareSerial Compatible Platform ESP32 compatibility Each of these drivers also needs 2 native ESP32 pins, which is a luxury that cannot be easily spared since the ESP32 has very few pins to start with in the first place. So it is unlikely the board will ever be designed to support TMC2208/TMC2209 drivers via jumper settings.

For SPI mode, users will just need one jumper wire (female-to-female) per stepper driver to connect the CS pin for the respective axis to a spare pin (GPIO21, and GPIO22; plus GPIO2, GPIO4, and GPIO15 when using I2S to drive the PWM for heated bed, hot end, and part fan).

[vivian-ng]

Updates on this board, which uses I2S for the stepper stream as well as PWM.

1. PWM for heated bed, hotend, and fans have been tested to be working fine. No issues with printing.

2. Experiencing resets every time babystepping is attempted through LCD screen. I have not been able to determine if this is a software or hardware issue.

3. Similar to issue 2 above, there seems to be issues with manual mesh bed leveling via the LCD; every time I tried to do this, it will home, and then after moving to the first probe point, it will reboot. I think there two issues are linked, but I am not sure how.

4. Random resets in coreXY setup. The board runs fine on a cartesian printer. But when it is used for coreXY, it seems there is some instability in the stepper stream that triggers random resets. I think this is likely the DIR or EN pin value, because the random reset happens only when it is trying to switch direction, or switch axis.

[vivian-ng]

Just for troubleshooting, as record, and also to see if there are any wise men around to help. This is the error when homing on a coreXY printer running on I2S stepper stream.

PC      : 0x400f418e  PS      : 0x00060931  A0      : 0x800f2abd  A1      : 0x3ffbe620  ␍␊
A2      : 0x00000000  A3      : 0x00000001  A4      : 0x3f000000  A5      : 0x00000000  ␍␊
A6      : 0x00000000  A7      : 0x3ffde474  A8      : 0x800f4188  A9      : 0x3ffc3080  ␍␊
A10     : 0x00000000  A11     : 0x3ffdea38  A12     : 0x4000bff0  A13     : 0x3ffbe7c0  ␍␊
A14     : 0x00002aaa  A15     : 0x00000000  SAR     : 0x00000020  EXCCAUSE: 0x00000004  ␍␊
EXCVADDR: 0x00000000  LBEG    : 0x40002390  LEND    : 0x4000239f  LCOUNT  : 0x00000000  ␍␊
Core 1 was running in ISR context:␍␊
EPC1    : 0x400f418e  EPC2    : 0x00000000  EPC3    : 0x00000000  EPC4    : 0x40082a51␍␊
Backtrace: 0x400f418e:0x3ffbe620 0x400f2aba:0x3ffbe700 0x400f15a6:0x3ffbe720 0x400f1613:0x3ffbe740 0x400f509f:0x3ffbe760 0x400f50bf:0x3ffbe780 0x40080fa5:0x3ffbe7a0 0x40081859:0x3ffbe7c0 0x4000bfed:0x3ffb1c40 0x40089d2d:0x3ffb1c50 0x4008babf:0x3ffb1c70 0x4008c144:0x3ffb1c90 0x40084a74:0x3ffb1cb0 0x40084aa9:0x3ffb1cd0 0x4008618d:0x3ffb1cf0 0x4000beaf:0x3ffb1d10 0x4016a7af:0x3ffb1d30 0x4016a781:0x3ffb1d50 0x400fac07:0x3ffb1d70 0x400ff61e:0x3ffb1db0 0x400e1056:0x3ffb1dd0 0x400e0cdd:0x3ffb1df0 0x400d311b:0x3ffb1e10 0x400e1358:0x3ffb1e30 0x400f2bae:0x3ffb1e50 0x400f1e77:0x3ffb1e70 0x400f1f3a:0x3ffb1ed0 0x400e3295:0x3ffb1f00 0x400e4b0b:0x3ffb1f30 0x400e52ad:0x3ffb1f50 0x400e695c:0x3ffb1f70 0x400e15c5:0x3ffb1f90 0x40107529:0x3ffb1fb0 0x400884a5:0x3ffb1fd0␍␊

The decoded stack:

PC: 0x400f418e: Stepper::endstop_triggered(AxisEnum) at Marlin/src/module/stepper.cpp line 2228
EXCVADDR: 0x00000000

Decoding stack results
0x400f418e: Stepper::endstop_triggered(AxisEnum) at Marlin/src/module/stepper.cpp line 2228
0x400f2aba: Planner::endstop_triggered(AxisEnum) at Marlin/src/module/planner.cpp line 1489
0x400f15a6: Endstops::update() at Marlin/src/module/endstops.cpp line 706
0x400f1613: Endstops::poll() at Marlin/src/module/endstops.cpp line 268
0x400f509f: Temperature::isr() at Marlin/src/module/temperature.cpp line 2800
0x400f50bf: tempTC_Handler() at Marlin/src/module/temperature.cpp line 2324
0x40080fa5: timer_isr(void*) at Marlin/src/HAL/HAL_ESP32/HAL_timers_ESP32.cpp line 75
0x40089d2d: vTaskExitCritical at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/tasks.c line 4274
0x4008babf: multi_heap_internal_unlock at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/heap/multi_heap.c line 380
0x4008c144: multi_heap_malloc at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/heap/multi_heap_poisoning.c line 202
0x40084a74: heap_caps_malloc at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/heap/heap_caps.c line 111
0x40084aa9: heap_caps_malloc_default at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/heap/heap_caps.c line 140
0x4008618d: _malloc_r at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/newlib/syscalls.c line 37
0x4016a7af: operator new(unsigned int) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_op.cc line 50
0x4016a781: operator new[](unsigned int) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_opv.cc line 32
0x400fac07: WiFiUDP::parsePacket() at /home/user/data/platformio/packages/framework-arduinoespressif32/libraries/WiFi/src/WiFiUdp.cpp line 210
0x400ff61e: ArduinoOTAClass::handle() at /home/user/data/platformio/packages/framework-arduinoespressif32/libraries/ArduinoOTA/src/ArduinoOTA.cpp line 382
0x400e1056: WiFiServices::handle() at Marlin/src/HAL/HAL_ESP32/wifiservices.cpp line 133
0x400e0cdd: WiFiConfig::handle() at Marlin/src/HAL/HAL_ESP32/wificonfig.cpp line 423
0x400d311b: HAL_idletask() at Marlin/src/HAL/HAL_ESP32/HAL.cpp line 84
0x400e1358: idle(bool) at Marlin/src/Marlin.cpp line 697
0x400f2bae: Planner::synchronize() at Marlin/src/module/planner.cpp line 1541
0x400f1e77: do_homing_move(AxisEnum, float, float) at Marlin/src/module/motion.cpp line 1249
0x400f1f3a: homeaxis(AxisEnum) at Marlin/src/module/motion.cpp line 1435
0x400e3295: GcodeSuite::G28(bool) at Marlin/src/gcode/calibrate/G28.cpp line 327
0x400e4b0b: GcodeSuite::process_parsed_command(bool) at Marlin/src/gcode/gcode.cpp line 244
0x400e52ad: GcodeSuite::process_next_command() at Marlin/src/gcode/gcode.cpp line 830
0x400e695c: GCodeQueue::advance() at Marlin/src/gcode/queue.cpp line 880
0x400e15c5: loop() at Marlin/src/Marlin.cpp line 1159
0x40107529: loopTask(void*) at /home/user/data/platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp line 19
0x400884a5: vPortTaskWrapper at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/port.c line 143

The error seems to be with the planner and endstops being triggered. Well, endstops being triggered should be normal, since the printer is trying to home. So the issue is probably with the planner.

[vivian-ng]

This is a long-overdue update. v0.4 was completed some time ago, and it added a lot of stuff. For one, it has support for 5 stepper drivers. And like before, Trinamic SPI drivers can be easily connected by using jumpers, and a single jumper wire for each axis.

v0.4 also added various other controllable fans. The case fan is now controllable, the heat sink fan too. There is also an extra fan connector. All these three fans can be controlled by firmware, or use the corresponding jumper to short them and set them to be "always on".

A pity but I think I forgot to take a photo of v0.3.

[vivian-ng]

Latest version is v0.5

It is not a real jump from v0.4, except for the 5V_SEL jumper that is now either VUSB or VIN. Plus a capacitor on EN pin to help with noise.

That said, I have used all PCB colors available on JLCPCB (v0.3 used blue). And yellow and white are the two colors that I will definitely avoid.

I will be making a couple of v0.5 boards available at cost+shipping for those who want to tinker with them. They should be ready in a week (I ran out of MOSFETs and waiting for the new order to arrive). The header pins won't be as colorful as the photo, though.

[vivian-ng]

Solution for reboot during homing on coreXY can be found here.

[vivian-ng]

MRR ESPE v0.5 is now available here for those who wish to give it a try but do not want to buy the parts and solder everything on your own.

I think the board is ready, as it is now, in terms of the hardware. Software support still depends on Marlin development, and I did experience random freezes in the past when using I2S, so I cannot say it is the most stable. I also experienced resets when used with a LCD controller, but recent fixes to the Marlin code seemed to have fixed that. Still, I would say the I2S version is still in the experimental stages. If stable operation is more important, the MRR ESPA (non-I2S version) is available here.

[vivian-ng]

@luc-github pointed out a mistake on the schematic/PCB of v0.5. The RX and TX pins are wrongly connected (they are swapped). On v0.5, that pin labeled TX is actually connected to UART- and the pin labeled RX is actually connected to UART+. This prevents the AUX1 connector from working with MKS TFT32 and other similar controllers using AUX1. To use such controllers, you will need to use dupont connectors.

I will put up a v0.5rev1 to fix this as soon as I can.

[vivian-ng]

I have added a simple adapter board to fix the AUX1 issue, design can be found here.

Still untested. Waiting for JLCPCB to deliver the PCB. But it is a relatively simple design and I do not expect any problems.

[vivian-ng]

The adapter board to fix the AUX1 issue has been tested to work.

Another adapter board to break out the LCD connector pins to the EXP1 and EXP2 used in more common RepRapDiscount Full Graphics Smart Controllers can be found here. To use with this controller, Configuration.h needs to be:

#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
#define ST7920_DELAY_1 DELAY_NS(500)
#define ST7920_DELAY_2 DELAY_NS(500)
#define ST7920_DELAY_3 DELAY_NS(500)

The delays are needed for the display to work without being garbled. (Edit: Try without the delays first. If the display is garbled, then add the delays.)

Some more info can be found here.

[vivian-ng]

It seems that #define MONITOR_DRIVER_STATUS will affect the SD file uploads. Once I disabled this feature, all my uploads worked, even at full SPI speed. Tested on Ender-3 with MRR ESPE + TMC2130 drivers in SPI mode on X and Y axes (basically, my working test setup). Also tested on a bare MRR ESPA with TMC2130 drivers in SPI mode on X and Y.

Background: I noticed that "Upload failed" was not being shown on my web serial terminal window on the webUI, but it was showing over a separate serial terminal window (over USB). At the same time, I was "X driver overtemperature warning!" and "Y driver overtemperature warning!" when the "Upload failed" message appears. Once I disabled #define MONITOR_DRIVER_STATUS, my uploads were fine, no warning messages, and the file sizes for consistent.

[vivian-ng]

PR#16581 sent to add sanity check that throws an error when TMC SPI drivers are in use with MONITOR_DRIVER_STATUS and SDSUPPORT both enabled. The user will then need to decide which to disable (most probably MONITOR_DRIVER_STATUS since SDSUPPORT is essential for sending files for print via the webUI).

[vivian-ng]

The issue with babystepping and linear advance not working on I2S stepper stream has been given its own issue.

[wuxiaoyi88]

Today, using my own soldered ESPE PCB board, I did a firmware write, brush the marlin.2.02 version. Brush writing is normal, power test found that the BED heat transfer bed automatically heated.Not controlled, I do n’t know if the hardware is not welded well, or the hot bed cannot be controlled because of the firmware configuration problem. At present, there is no problem, but the stepper motor can walk normally, The E0 extrusion head can be heated normally.

[vivian-ng]

@wuxiaoyi88

Today, using my own soldered ESPE PCB board, I did a firmware write, brush the marlin.2.02 version. Brush writing is normal, power test found that the BED heat transfer bed automatically heated.Not controlled, I do n’t know if the hardware is not welded well, or the hot bed cannot be controlled because of the firmware configuration problem. At present, there is no problem, but the stepper motor can walk normally, The E0 extrusion head can be heated normally.

Please check your soldering. Maybe change your bed MOSFET, it could be broken. If need be, after your have done your own troubleshooting, post a separate issue with details of the problem.