Duet 3 6HC Rev. 1.01 Faulty
-
Now i've got the COM Detection on the Windows PC to work.
(another COM Port)
the Problem now is: BOSSA Detected ATSAME70x20 but when i load the
Firmware .bin (MB6HC) Version 3.2beta4 from Github,
select it in BOSSA (+Checkboxed for Erase All - Boot to Flash - Lock)
it Stuck at 0% and nothing more...?! if i disconnect the Board after several minutes
BOSSA Tells me immediately that the SAM-BA Operation failed.
whats the Deal?
i'm a little bit disappointed now.. a 250 € Board and i have to use every trick to get it to work... -
Can you try getting the board working in standalone mode without the SBC first?
https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_Running_in_standalone_mode
Were you able to get Bossa to flash the board or not?
Once you're able to get a firmware applied to the board again ( I suggest sticking to 3.1.1 for this) you can try downloading a fresh copy of DuetPi and create a new SD card for the Pi.
https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_DuetPi
-
Hi, Thank you for your Help!
i tried setting up the DuetPi, it always has a problem to connect to the board while sudo apt-get upgrade (FW Version 3.1.2, 3.1.1...(different Firmwares tested.. Error: no header..)) currently i'm running 3.1.1
i managed to get BOSSA on windows working with a completely new usb cable,
and flashed V3.1.1!!
NOW i can connect to the DWC! Problem now is....
i also managed to upload my saved config files...
Running M122 (in that seconds i have connection..) brings following:
1.12.2020, 18:25:34 m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956L2-G43S4-6J1FL-3SD6R-1S5YF
Used output buffers: 1 of 40 (22 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 163272 of which 44 recycled
Exception stack ram used: 224
Never used ram: 75072
Tasks: ETHERNET(blocked,844) NETWORK(ready,1972) HEAT(blocked,1188) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1436) TMC(blocked,204) MAIN(running,4552) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:08:27 ago, cause: software
Last software reset at 2020-12-01 17:17, reason: User, spinning module LinuxInterface, available RAM 77008 bytes (slot 3)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 36.7, current 37.2, max 37.4
Supply voltage: min 25.0, current 25.0, max 25.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.2, under voltage events: 0
Driver 0: standstill, reads 38834, writes 0 timeouts 0, SG min/max not available
Driver 1: standstill, reads 38834, writes 0 timeouts 0, SG min/max not available
Driver 2: standstill, reads 38834, writes 0 timeouts 0, SG min/max not available
Driver 3: standstill, reads 38834, writes 0 timeouts 0, SG min/max not available
Driver 4: standstill, reads 38834, writes 0 timeouts 0, SG min/max not available
Driver 5: standstill, reads 38835, writes 0 timeouts 0, SG min/max not available
Date/time: 2020-12-01 17:25:37
Slowest loop: 4.99ms; fastest: 0.21ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is ready with "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon* is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 0.48ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 0 of 8- Ethernet -
State: establishingLink
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== Filament sensors ===
Extruder 0 sensor: no filament
Extruder 1 sensor: no filament
=== CAN ===
Messages sent 724, longest wait 0ms for type 0
=== Linux interface ===
State: 0, failed transfers: 758
Last transfer: 23ms ago
RX/TX seq numbers: 2532/14965
SPI underruns 1184, overruns 232
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.1.1
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 31.40**
i don't understand why it's always reconnecting.. bad Flat Cable??
Prusa Mini, Chiron @ BMG X2
Metal SLS Printer Development - Ethernet -
-
While we look into it I suggest getting setup and running in standalone mode without the SBC connected to confirm the Duet 3 is working correctly and get your config sorted. At that point it may be worth trying to the 3.2 beta release which has a number of fixes for the SBC mode.
-
@NeueKlasse said in Duet 3 6HC Rev. 1.01 Faulty:
bad Flat Cable??
That is a possibility. Do you have a usable replacement or the ability to make some jumper wires to confirm this?
-
I already tried the 3.2beta 4 with the same issues, at the moment it seems that's only a problem of the DWC / SBC, the Printer is homing and probing while i get errors on the DWC that i lost connection, and get it back, and lost, and back etc. etc.......
how can i test the DWC while i'm running in standalone mode (SD card in the Duet)?
no i have no Replacement, do you have a pinout diagram of the Cable?
...btw.. the Paneldue is working fine
Prusa Mini, Chiron @ BMG X2
Metal SLS Printer Development -
i moved the cable while i was connected,
i've got one new Error that DCS has been stopped, i never got that before,
but it was so unresponsive that i cannot confirm that the cable movement was the problem....
-
@NeueKlasse said in Duet 3 6HC Rev. 1.01 Faulty:
how can i test the DWC while i'm running in standalone mode (SD card in the Duet)?
Linked above: https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_Running_in_standalone_mode
@NeueKlasse said in Duet 3 6HC Rev. 1.01 Faulty:
do you have a pinout diagram of the Cable?
It's a flat ribbon cable so 1:1 across with jumper wires.
The Duet 3 wiring diagram is here: https://duet3d.dozuki.com/Wiki/Duet_3_Mainboard_6HC_Wiring_Diagram
-
@NeueKlasse said in Duet 3 6HC Rev. 1.01 Faulty:
no i have no Replacement, do you have a pinout diagram of the Cable?
Here you go for a Rpi-3B+
-
Thanks, i managed to setup jumper wires,
now the connection lost problem comes every second...??!btw. i'm running on pi4
-
The Duet's running in Standalone mode now, i report if i have issues!
Thank's so far.. update it's running till now ( 45minutes without any problem)...
i think the DuetPi.. create problems -
So just to confirm, changing to jumper wires has made it worse?
-
@Phaedrux it seems so far...
-
In the main time i setted up the DuetPi with a Fresh image.
10min ago i changed everything to SBC Operation and started the printer,
after everything started up i had the Same issue on the DWC...
connection to duet lost, (no header).. and several seconds later, Connection established... and so on and so on...
maybe it's the Pi itself?! i ordered a new Pi4 anyway...i don't tried it yet but before if i tried to update the Firmware via pi+ribboncable
the Duet FW gets corrupted and i have to erase all and do the FW over USB..... (see 1. Post) -
Having another Pi available to test with would help troubleshoot the issue.
-
The symptoms you mentioned sound like there is a wiring issue between the Duet and the Pi. I assume if you look into the DCS log via
journalctl -u duetcontrolserver -eyou'll see lots of checksum errors, too. If there are no checksum errors, it's probably a good idea to try out a different Raspi.Just to be sure: You don't use another SPI device with the Pi, do you?
Duet software engineer
-
Thanks,
the Pi tells following...
Dec 02 15:47:46 duet3 DuetControlServer[373]: [warn] Restarting transfer because a bad header response was received (0x00000032)
Dec 02 15:47:47 duet3 DuetControlServer[373]: [warn] Restarting transfer because a bad header response was received (0x80ffff13)
Dec 02 15:47:47 duet3 DuetControlServer[373]: [warn] Restarting transfer because a bad data response was received (0xffffff7d)
Dec 02 15:47:47 duet3 DuetControlServer[373]: [warn] Restarting transfer because a bad header response was received (0x00001f00)
Dec 02 15:47:47 duet3 DuetControlServer[373]: [warn] Restarting transfer because the Duet received a bad response (header)
Dec 02 15:47:49 duet3 DuetControlServer[373]: [warn] Bad data checksum (expected 0x8707, got 0x6fc0)
Dec 02 15:47:50 duet3 DuetControlServer[373]: [warn] Bad data checksum (expected 0x07c5, got 0xc7e3)
Dec 02 15:47:51 duet3 DuetControlServer[373]: [warn] Bad data checksum (expected 0x7881, got 0x7060)
Dec 02 15:47:54 duet3 DuetControlServer[373]: [warn] Bad data checksum (expected 0x9358, got 0xbc71)
Dec 02 15:47:54 duet3 DuetControlServer[373]: [warn] Bad data checksum (expected 0xfb8f, got 0x11a2)
Dec 02 15:47:54 duet3 DuetControlServer[373]: [warn] Restarting transfer because a bad header response was received (0x000000a8)
Dec 02 15:47:55 duet3 DuetControlServer[373]: [warn] Restarting transfer because a bad data response was received (0xffffff67)
Dec 02 15:47:55 duet3 DuetControlServer[373]: [warn] Restarting transfer because a bad data response was received (0xffffff67)
Dec 02 15:47:55 duet3 DuetControlServer[373]: [warn] Bad data checksum (expected 0xe458, got 0x1b24)
Dec 02 15:47:55 duet3 DuetControlServer[373]: [warn] Note: RepRapFirmware didn't receive valid data either (code 0x00000004)
Dec 02 15:47:55 duet3 DuetControlServer[373]: [warn] Bad data checksum (expected 0xe458, got 0xca19)
Dec 02 15:47:55 duet3 DuetControlServer[373]: [warn] Restarting transfer because the Duet received a bad response (data response)
Dec 02 15:47:57 duet3 DuetControlServer[373]: [warn] Restarting transfer because a bad header response was received (0xffffff15)
Dec 02 15:47:58 duet3 DuetControlServer[373]: [warn] Restarting transfer because a bad header response was received (0xffffff67)i orderer a 40 to 26 Ribboncable from Pimoroni
-
you could try reducing the SPI frequency while waiting for new ribbon cable; /opt/dsf/conf/config.json (or something like that)
-
@bearer i used 50% of the value (100000)
interesting thing: if i do the Heater Tuning M303 the Connection loss
failures getting worse than before, but the Tuning are correctly till the end (seen from the Paneldue)MCU Temperature after 2 hours Continious running about 42°C
-
@chrishamm sorry, no i have no additional spi device running on the pi
