[DUE] Watchdog reset at startup after changing steps/mm in EEPROM

pilot779

Hello,
I changed my stepper driver from RAPS128 to TMC2208 on my RADDS Board, so I had to configure the steps per mm variable in EEPROM from 800 to 100 (RAPS128 were working with 128 microsteps, TMC2208 works with 16 microsteps and does an internal interpolation of a quite high resolution sinus signal for silent movement).

After that EEPROM Change, the watchdog will always reset after the next reboot for a random period of time (several minutes). The behaviour is similar to this thread:

"[DUE] Watchdog keeps resetting after power on for random amount of time"

When I disable the watchdog, the changes of my settings are working fine. I also changed the settings in configuration.h and did a recompile. It will work, until I activate the new settings in EEPROM...

Repetier

Watchdog triggers if after 4 seconds the temperature and pwm interrupt were not called. So question is does it start blocking for so long I guess. RADDS has eeprom as I2C device which is known to block on communication errors (which is a reason we buffer the eeprom on startup). So question 1 is does storing new value to eeprom work at all or does old value stay. That is more or less the only reason I can think of, that the eeprom is broken but then it would be still broken on 800 steps per mm, so guess it is not that.

Does it work with 800 steps per mm and TMC2208? Or 100 substeps with RAPS128? What I'm after is, if the driver has influence on the problem. Firmware does not know about the driver and handles them the same means as STEP/DIR/ENABLE stepper driver.

pilot779

The eeprom I2C communication works fine. The watchdog will not reset after the data communication between controller and eeprom. After writing I can read the eeprom again, and the new value is stored correctly.

The watchdog resets will occur after the next restart (close RS232 communication and reopen communication of the host program, for example). You said that watchdog will trigger after 4 seconds. Thats strange, because the reset intervall of the software is about 1.5 sec -> see screenshot...

Both stepper driver are working as expected after the substep reconfiguration. I also think, that the different stepper driver doesn´t have any influence to the firmware, because the interface is only digital logic...

Repetier

The strange thing I see is that it triggers while writing "Free RAM". If you check the sources you see

Commands::writeLowestFreeRAM(); HAL::setupTimer();
#if FEATURE_WATCHDOG HAL::startWatchdog(); #endif // FEATURE_WATCHDOGSo watchdog was disabled until starting to write free ram. So this means that not our watchdog is triggering but the watchdog that was activated before. In fact we even disable watchdog at startup, but that only works with recent Arduino IDE versions. So what Arduino IDE did you use? Can you recompile using 1.8.x with SAM Board 1.6.11. I'm not sure when they changed this so you could decide in software how to handle watchdog.

pilot779

I updated arduino IDE and the SAM Board addon - still the same behaviour...

Repetier

Very strange. There is no reason firmware should do something different just because resolution has changed. Except if you have a delta there would be some difference in some cases, so you should also set resolution correctly in configuration.h. But that would only cause wrong moves when you start moving. So not so convinced it could be the case here.