Closed chrisqwertz closed 5 years ago
Can't extract your config files @chrisqwertz for some reason.
I can't extract them either.
weird let's try again:
Seems I can read them now. Just a thought do you understand exactly what the power on sequence is with this setup? Is there any delay between the board being powered and power being supplied to the driver boards? That may not be good. They really need to have power on VS when you try and talk to them. I'm not sure that applying power later works either as I think there is some rule that says you must have power on VS before you have it on VCC_IO. But it shouldn't really cause anything to hang.
I am using PS_DEFAULT_OFF
disabled quite a while to ensure the correct power sequence to my TMC5160
its still working with current Marlin on my Re_Arm, but I am using an ATX PSU
and have #define POWER_SUPPLY 1
chrisqwertz has #define POWER_SUPPLY 2
which has the PS_ON_PIN inverted
Now a commit (451ea99) that was working before stopped working
my Re-Arm is caught in a bootloop!
Its booting if I enable PS_DEFAULT_OFF
but then I have the Problem #14051
It seems the issue is caused by a recent change in the TMCStepper library
after downgrading TMCStepper lib to 0.3.2 my printer is working normal again
I'll investigate further tomorrow.
CoreXY with RAMPS/Re-Arm and TMC5160 forX/Y
my fork
UPDATE: last working commit of the TMCStepper library is https://github.com/teemuatlut/TMCStepper/commit/d33aba21b4d4b26c6d27b238ca0be518af00f649
@kAdonis I just came to the same conclusion for my issue as well. Specifying 0.3.2 in platformio.ini fixed my TMC issues.
In my case, I also found a hardware fault on my end. I had those Stepstick protectors under the tmc2008 modules and it so happens, that those have a diode in there that will forward the 3.3V LPC1768 supply from the drivers Vio to Vmot. Without investigating further I'd say that put too much strain on the Re-Arm 3.3V rail and therefor blocked the LPC from from leaving its reset state.
@chrisqwertz If you're problem is solved, go ahead and close this issue, My problem is probably the same as 14051
Just tried flashing with PS_DEFAULT_OFF disabled, won't boot again.
Neither TMCStepper 0.3.2 or 0.3.3 allow me to boot with the PSU on. 😑
@chrisqwertz Do you have a configuration that will boot? It would really help to know what does work and what change makes it no longer boot.
@gloomyandy sorry, didn't see your message. Yes, of course, I have a working configuration. It's the same as the non working one except PS_DEFAULT_OFF is enabled.
Consider this code fragment from Marlin.cpp
:
void setup_powerhold() {
#if HAS_SUICIDE
OUT_WRITE(SUICIDE_PIN, HIGH);
#endif
#if HAS_POWER_SWITCH
#if ENABLED(PS_DEFAULT_OFF)
powersupply_on = true; PSU_OFF();
#else
powersupply_on = false; /* PSU_ON() */; // <-- disabling this will lead to a successful boot
#endif
#endif
The PSU_ON()
macro expands to powerManager.power_on()
in my case. Disabling this will make my machine boot and display "TMC CONNECTION ERROR" on the LCD screen.
@gloomyandy
PSU_ON()
expands to the following lines in power.cpp
:
void Power::power_on() {
lastPowerOn = millis();
if (!powersupply_on) {
PSU_PIN_ON();
#if HAS_TRINAMIC
delay(100); // Wait for power to settle
restore_stepper_drivers();
#endif
}
}
Commenting out restore_stepper_drivers();
will enable Marlin to boot again
Moving
#if HAS_DRIVER(TMC2208)
tmc2208_serial_begin();
#endif
in Marlin.cpp
before setup_powerhold();
will fix the issue
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.
Description
With
PS_DEFAULT_OFF
disabled my Re-Arm board will never successfully boot to the boot screen.Steps to Reproduce
Comment out
#define PS_DEFAULT_OFF
, reset boardExpected behavior: normal boot with PSU on after reset Actual behavior: nothing happens after reboot. LCD is powered, but remains blank.
Additional Information
conf.zip