RRF 2.x debug procedure ?

Having some issues with RRF 2.0 2.05RC1R (2019-13-03b1) for SAM4S WiFi. The firmware arbitrarily gets Emergency stop and restarts. A file simulation passes with no issues, but when begin to print, it prints few layers and Emergency stop appears.

Is there are any guide how to use the debug functionally and tackle such issues ? Any recommendations ?

If you get unexpected resets, run M122 and look in the resulting report for the "last reset reason". If tit reason is "software" then look at the "software reset reason". This gives details of the reason for the reset and a stack trace at the point that the reset procedure was initiated.

For faster response to questions on RepRapFirmware, post at [forum.duet3d.com].

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
the "last reset reason".

> Last software reset time unknown, reason: Unknown, spinning module Platform, available RAM 22796 bytes (slot 3)
> Last software reset time unknown, reason: Heat task stuck, spinning module GCodes, available RAM 23092 bytes (slot 2)

Is this: heaterWatchdog = 0xA0, // the Heat task didn't kick the watchdog often enough ?


Also, I am currently trying to add WiFi support for SAM4S to RRF 3.3. However what I am getting is:

ResponseTimeout, pending=0
Error: Failed to initialise WiFi module: SPI timeout

Any additional configuration required for PDC ?

Edited 3 time(s). Last edit at 10/26/2021 04:24PM by Dev00.

Yes it looks as though the heat task didn't kick the software watchdog within the timeout period.

The SPI code was working on the SAM4E8E with the PDC way back when I first implemented it, but I was unable to run the SPI interface as fast as I could with the DMAC. So you may need to reduce the SPI clock speed in the WiFi firmware. I suggest you reduce it to 10 MHz or lower until you have it working.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Yes it looks as though the heat task didn't kick the software watchdog within the timeout period.

Changed some values but it did not help, still getting arbitrarily Emergency stops. Would you specify which parameters suppose to be tweaked ?

Quote
dc42
So you may need to reduce the SPI clock speed in the WiFi firmware. I suggest you reduce it to 10 MHz or lower until you have it working.

I think, I changed the SPI clock frequency, no so sure because not so clear which parameter actually adjusts the main SPI frequency - DefaultSharedSpiClockFrequency ? However there was no any difference. Are you sure that the PDC implementation is still functional in RRF v3.3 and up ? It seems not used from any of Duet boards. On RRF v2.05.1 it works, but in my opinion it is the main cause of the emergency stops, no such events occur with the Ethernet interface.

Edited 1 time(s). Last edit at 10/28/2021 04:50AM by Dev00.