short-to-ground errors After Firmware upgrade/downgrade

Johann

I have checked there is nothing that can possibly cause any shorts

dc42

@johann said in short-to-ground errors After Firmware upgrade/downgrade:

Error: short-to-ground reported by driver(s) 0 1 2 3
[ERROR] Error: short-to-ground reported by driver(s) 0 1 2 3
Error: over temperature shutdown reported by driver(s) 0 1 2 3
[ERROR] Error: over temperature shutdown reported by driver(s) 0 1 2 3

Over temperature shutdown messages on multiple drivers suggest that SPI communication with the drivers has broken down. That could be caused by shorted wiring on the expansion connector. Have you disconnected everything except power and USB from the Duet?

@johann said in short-to-ground errors After Firmware upgrade/downgrade:

Regarding the WiFi, I have upgraded the DuetWiFiServer.bin with M997 S1 from the 2.03 zip package multiple times. After issuing a M552 S0 the wifi module remains disabled.

When you do that, does the blue LED on the WiFi module flash rapidly, and do you get a message that the firmware has been updated successfully? Also please check that the DuetWiFiServer.bin file you copied to the SD card has a file length that matches the one in the release area at https://github.com/dc42/RepRapFirmware/releases/tag/2.03.

Johann

@dc42 said in short-to-ground errors After Firmware upgrade/downgrade:

Over temperature shutdown messages on multiple drivers suggest that SPI communication with the drivers has broken down. That could be caused by shorted wiring on the expansion connector. Have you disconnected everything except power and USB from the Duet?

That is correct. Nothing is connected other than those two. Nothing in expansion connector.

I have also connected a PanelDue to it instead of the USB and I get the same errors reported on it.

@dc42 said in short-to-ground errors After Firmware upgrade/downgrade:

When you do that, does the blue LED on the WiFi module flash rapidly, and do you get a message that the firmware has been updated successfully? Also please check that the DuetWiFiServer.bin file you copied to the SD card has a file length that matches the one in the release area at https://github.com/dc42/RepRapFirmware/releases/tag/2.03.

Regarding the WiFi module. This is the output I get when I flash the WiFi module:
SENDING:M997 S1
Trying to connect at 230400 baud:
success
Erasing 4096 bytes...
Erasing 212992 bytes...
Uploading file...
5% complete
10% complete
15% complete
20% complete
25% complete
30% complete
35% complete
40% complete
45% complete
50% complete
55% complete
60% complete
65% complete
70% complete
75% complete
80% complete
85% complete
90% complete
95% complete
Upload successful

Johann

@dc42 Is my board doomed for the bin then?

A Former User

You didn't include what the Wifi LED did during the flashing of the Wifi module?

Johann

@bearer the led on the esp wifi board was flashing fast during the programming of the wifi firmware

I also verified that the file sizes matched that was on the releases repo for that version.

A Former User

Strange, would seem the wifi and stepper drivers are on separate spi busses and as such one ought not affect the other, but i'll leave drawing conclusions to big cheese dc42 who should have the information he asked for now

dc42

It looks like the WiFi update has been successful. Have you run M115 to check that the main firmware you are running really is 2.03?

If you confirm that you are running 2.03, check that you have no M587 commands in config.g. Send M552 S-1 to reset the WiFi module, M552 S0 to put it in idle mode, and M588 S"*" to clear the existing WiFi data. Then set up your access point details using M587.

The stepper motor status reports suggest a fault on the Duet that can probably be fixed. Is there any chance that a piece of metal swarf could have fallen on the board and be shorting two chip pins together?

Johann

@dc42 said in short-to-ground errors After Firmware upgrade/downgrade:

It looks like the WiFi update has been successful. Have you run M115 to check that the main firmware you are running really is 2.03?
If you confirm that you are running 2.03, check that you have no M587 commands in config.g. Send M552 S-1 to reset the WiFi module, M552 S0 to put it in idle mode, and M588 S"*" to clear the existing WiFi data. Then set up your access point details using M587.

I had no joy. Here is the output of the commands I ran:

SENDING:M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 2.03 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2019-06-13b2

SENDING:M552 S-1
WiFi module stopped

SENDING:M552 S0

SENDING:M588 S"*"
M588: Failed to reset the WiFi module to factory settings

SENDING:M587 S"My_WIFI" P"SuperSecretPassword"
M587: Failed to add SSID to remembered list

SENDING:M587
M587: Failed to retrieve network list

SENDING:M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.03 running on Duet WiFi 1.02 or later
Board ID: 08DDM-9FAM2-LW4S4-6J9D2-3SN6P-K2VMY
Used output buffers: 1 of 24 (10 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 93340 of which 164 recycled
Exception stack ram used: 288
Never used ram: 11600
Tasks: NETWORK(ready,548) HEAT(blocked,916) MAIN(running,3820) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 00:07:00 ago, cause: power up
Last software reset time unknown, reason: User, spinning module GCodes, available RAM 7888 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0xffffffff Task 0xffffffff
Error status: 0
[ERROR] Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 54.6, current 55.1, max 55.4
Supply voltage: min 1.6, current 1.7, max 1.7, under voltage events: 0, over voltage events: 0, power good: no
Driver 0: ok, SG min/max not available
Driver 1: ok, SG min/max not available
Driver 2: ok, SG min/max not available
Driver 3: ok, SG min/max not available
Driver 4: ok, SG min/max not available
Date/time: 1970-01-01 00:00:00
Cache data hit count 833357449
Slowest loop: 100.83ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is ready with "M122" in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 0.17ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 0 of 8

WiFi -
Network state is starting
WiFi module is disabled
Failed messages: pending 0, notready 5, noresp 0
Socket states: 0 0 0 0 0 0 0 0

I performed all of these commands only on USB power, when the stepper motors errors dont appear.

Regarding the stepper motors, I guess it is possible for a metal swarf to have fallen on the board. Are there specific pins I should have a look at on the drivers and processor side?

dc42

Please try the following sequence:

M552 S-1
wait at least 5 seconds
M552 S0
wait at least 5 seconds
M552

It should report "WiFi module is idle". Does it?

Johann

@dc42

No joy. It stays in the "WiFi module is being started"

M552 S-1
21:39:47.832 -> ok
M552 S0
21:40:20.508 -> ok
M552
21:40:39.616 -> WiFi module is being started

dc42

That sounds like a hardware fault then. As you have another fault (stepper drivers) that uses different hardware apart from the MCU, it's likely to mean either a power issue or a faulty MCU. Is the MCU getting hot? Warm is normal.

Johann

@dc42 The MCU isn't getting hot. After leaving it on for 10 minutes when I touch the MCU surface I can its warm