DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1

Garfield

BOSSA .... No device found on /dev/ttyACM0 .....

A Former User

@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

BOSSA .... No device found on /dev/ttyACM0 .....

could just mean you have to use the erase jumper after all; it'd be interesting to see what lsusb says before and after applying the erase jumper.

(maybe i should get around to finishing the version that checks the /sys/bus/usb/ tree for usb id's to avoid such a vague error)

ChrisP

@deckingman said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

....................... but right now the learning curve is pretty steep and what I think should be simple tasks seem not to be - and I do this **** for a living !!

My God, what chance do us mere mortals have! As far as I'm concerned, you guys are all talking in some foreign language that I don't understand. I'll be sticking with stand alone operation for quite some time yet methinks.

I wouldn't worry too much. All new things have to go through some field testing and improvements before they're ready for the masses, and the move to using a SBC with additional software is a pretty significant change.
I guess it's stuff like this that highlights where perhaps some tools need to be developed to automate these sort of processes, so the user doesn't need to know what's going on in the background. Perhaps in the first instance it'd be good to have some sort of command line UI for the Pi to automate switching versions quickly and easily - something along the lines of the rasp-config interface? I appreciate that's not necessarily going to work for cases where one or more parts of the system become unresponsive...

ChrisP

@bearer said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

BOSSA .... No device found on /dev/ttyACM0 .....

could just mean you have to use the erase jumper after all; it'd be interesting to see what lsusb says before and after applying the erase jumper.

(maybe i should get around to finishing the version that checks the /sys/bus/usb/ tree for usb id's to avoid such a vague error)

Is there any particular reason why using BOSSA on the Pi on a command line interface is being encouraged rather than the gui version on Windows? I used this the other day and it took longer to download BOSSA than it did to open the program and re-flash the firmware.

A Former User

@ChrisP said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

Perhaps in the first instance it'd be good to have some sort of command line UI for the Pi to automate switching versions quickly and easily - something along the lines of the rasp-config interface? I

I think the solution is to get to the point where people who just need it to work can stay with the 3.1 stable version and for the learning curve on the unstable version to just be par for the course.

Sadly people who would have liked to stay on the 3.0 stable relase have been pushed onto the rollercoaster leading up to 3.1 due to issues with 3.0.

Garfield

@bearer - sorry I had already erased

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Trying to do this via the Pi first off - the Duet is too far from the PC (or my USB cables are too short - depends how you look at it)

A Former User

@ChrisP said in [DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1]

Is there any particular reason why using BOSSA on the Pi on a command line interface is being encouraged rather than the gui version on Windows? I used this the other day and it took longer to download BOSSA than it did to open the program and re-flash the firmware.

the only real advantage is the -R switch which resets the board after flashing, some people have struggled with that part resulting in the board staying in the bootloader after just disconnecting a usb cable that supplied power. (Well I suppose a copy paste commandline also ensures the erase and verify "checkboxes" are set correctly as well - but you get the same benefit with bossac on windows)

next for me is convenience, the pi is there and ready to go, fetching from git and building just the command line version only should take seconds unless you're on dialup from the 70's

A Former User

@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

@bearer - sorry I had already erased

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Trying to do this via the Pi first off - the Duet is too far from the PC (or my USB cables are too short - depends how you look at it)

you should see something like
Bus 001 Device 008: ID 03eb:6124 Atmel Corp. at91sam SAMBA bootloader when the usb connection is okay - bad cable? bad board?

ChrisP

@bearer said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

@ChrisP said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

Perhaps in the first instance it'd be good to have some sort of command line UI for the Pi to automate switching versions quickly and easily - something along the lines of the rasp-config interface? I

I think the solution is to get to the point where people who just need it to work can stay with the 3.1 stable version and for the learning curve on the unstable version to just be par for the course.

Sadly people who would have liked to stay on the 3.0 stable relase have been pushed onto the rollercoaster leading up to 3.1 due to issues with 3.0.

Yeh, to be fair, that's very true. When I decided to go down the unstable release route, I knew what I was possibly getting myself if for and I have no problem with re-imaging fresh raspbian images to start fresh if it comes to it. There's often more to it that simply "trying the latest RC", and I wonder whether it's obvious enough that most people should really stick to stable releases. That said, it needs enough people to test the RCs in different setups to find the bugs.

Garfield

@bearer said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

bad cable? bad board?

No USB cable connected - doing this via the Pi initially ... all the steps went fine except the flashing - which is when the error popped up

bad board - I sure hope not, if firmware changes or code behaviour can bork a board that's bad - code should not be able to kill hardware (yes I know there are codes used by the nefarious types - but even those are bug exploits really).

For what it is worth my diagnostic LED has been flashing continuously from the day I got the board - it no longer does. All power reports normal, LED power indications normal.

ChrisP

@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

@bearer said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

bad cable? bad board?

No USB cable connected - doing this via the Pi initially ... all the steps went fine except the flashing - which is when the error popped up

Using BOSSA requires connection from the host computer to the Duet via USB irrespective of whether its a PC or RPi.... if that's what you meant?

Garfield

You're kidding - why ?

Why would I execute something on the command line of a Pi if I connected a PC anyway - I could just run BOSSA on the PC and be done ....

Not logical ... and damn dangerous ... I'm not happy connecting a USB and 24V pwr with the problems I've seen reported with grounding.

Have never agreed with earth bonding of USB shells / screens but I'm not going to debate why it is a fundamentally bad idea in this thread.

A Former User

@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

I'm not happy connecting a USB and 24V pwr with the problems I've seen reported with grounding.

this is why I prefer to use usb form the pi, which is supplied from the duet. they all share a common ground and common supply to start with so odds of a ground loop should be as low as they get unless something is really wrong with the wiring (in which case the pi probably wouldn't work in the first place)

and i'll always be a sucker for a bash shell etc:)

and yes, bossa will only work with a usb cable, regardless of pi or computer.

ChrisP

@Garfield said in DCS Crash with 3.01-R10 / DWC 2.1.5 / DSF 2.1.1:

You're kidding - why ?

Why would I execute something on the command line of a Pi if I connected a PC anyway - I could just run BOSSA on the PC and be done ....

Not logical ...

Because BOSSA is a separate program made by others specifically for managing the flash on microcontroller such as the one on the Duets.

Your comment about why would you use command line if you could use the PC is precisely my comment above. Though as @bearer suggested, to some extent it comes down to what's easier for you in terms of what's available and what you're comfortable doing. While I'm not an expert on Linux, I'm comfortable with using command line, but I imagine most users would be more comfortable using a gui on a PC.
Anyway, if you don't have a flashing diag LED, I believe you option is only BOSSA and for that you'll need a USB cable and a PC/Pi platform of your choice. Tbh, since you've got this far, the quickest way is likely to be just running the command @bearer posted

(I think we've also drifted off topic too. Oops)

Garfield

OK - instruction really needs to be a little clearer.

If I read this correctly you can't do this using the 'ribbon' cable but must switch the RPi to connect to a USB port, this means I can leave 24 DC into the Duet and feed the Pi via the USB. Might be worth clarifying that the Ribbon should or should not be disconnected

A:
Use a data capable USB cable from any port on the Pi to the Duet.
Power the Duet from the RPi USB (the Pi must have its own power supply)

OR

B:
Power the Duet with VIN
RPi powered and connected via USB

Do one or the other; do not power both ways. I'd say that B is the preferred option unless you;re going to lift the common off VIN or you are sure that your PSU common is earth isolated

ChrisP

Yup, you shouldn't have to change your power arrangements - you don't have to unplug the ribbon cable. I assume you're powering the Pi from the D3 currently?

Garfield

I am indeed powering the Pi from the D3.

I don't think that were so far off topic if my disaster helps others who may encounter similar 'fatal' crashes.

Garfield

@bearer : 10 out of 10

This command needs to go in doczuki !!

wget https://pastebin.com/raw/Wa1kYf3G -O - | tr -d "\r" | bash

back up and to the point I was at before - can't stay connected, continuous connect / disconnect

Garfield

pr 27 11:15:05 duet3 DuetControlServer[3136]: [info] Application has shut down
Apr 27 11:15:05 duet3 systemd[1]: duetcontrolserver.service: Succeeded.
Apr 27 11:15:10 duet3 systemd[1]: duetcontrolserver.service: Service RestartSec=5s expired, scheduling restart.
Apr 27 11:15:10 duet3 systemd[1]: duetcontrolserver.service: Scheduled restart job, restart counter is at 57.
Apr 27 11:15:10 duet3 systemd[1]: Stopped Duet Control Server.
Apr 27 11:15:10 duet3 systemd[1]: Started Duet Control Server.
Apr 27 11:15:11 duet3 DuetControlServer[3175]: Duet Control Server v2.1.1
Apr 27 11:15:11 duet3 DuetControlServer[3175]: Written by Christian Hammacher for Duet3D
Apr 27 11:15:11 duet3 DuetControlServer[3175]: Licensed under the terms of the GNU Public License Version 3
Apr 27 11:15:11 duet3 DuetControlServer[3175]: [info] Settings loaded
Apr 27 11:15:11 duet3 DuetControlServer[3175]: [info] Environment initialized
Apr 27 11:15:11 duet3 DuetControlServer[3175]: [info] Connection to Duet established
Apr 27 11:15:11 duet3 DuetControlServer[3175]: [info] IPC socket created at /var/run/dsf/dcs.sock
Apr 27 11:15:12 duet3 DuetControlServer[3175]: [fatal] Abnormal program termination
Apr 27 11:15:12 duet3 DuetControlServer[3175]: [fatal] Update task faulted
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    System.ArgumentException: Property set method not found.
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, BindingFlags invokeAttr, Binder binder, Object[] index, CultureInfo culture)
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, Object[] index)
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at System.Reflection.PropertyInfo.SetValue(Object obj, Object value)
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 237
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.FilamentMonitor.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Sensors/FilamentMonitors/FilamentMon
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 209
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.FilamentMonitor.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Sensors/FilamentMonitors/FilamentMon
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelCollectionHelper.UpdateFromJson(IList list, Type itemType, JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Bas
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 264
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.MachineModel.UpdateFromFirmwareModel(String key, JsonElement jsonElement) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/MachineModel.cs:line 149
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetControlServer.Model.Updater.Run() in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/Model/Updater.cs:line 182
Apr 27 11:15:12 duet3 DuetControlServer[3175]: [fatal] Update task faulted
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    System.ArgumentException: Property set method not found.
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, BindingFlags invokeAttr, Binder binder, Object[] index, CultureInfo culture)
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, Object[] index)
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at System.Reflection.PropertyInfo.SetValue(Object obj, Object value)
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 237
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.FilamentMonitor.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Sensors/FilamentMonitors/FilamentMon
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 209
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.FilamentMonitor.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Sensors/FilamentMonitors/FilamentMon
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelCollectionHelper.UpdateFromJson(IList list, Type itemType, JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Bas
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.ModelObject.UpdateFromJson(JsonElement jsonElement, Boolean ignoreSbcProperties) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/Base/ModelObject.cs:line 264
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetAPI.Machine.MachineModel.UpdateFromFirmwareModel(String key, JsonElement jsonElement) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Machine/MachineModel.cs:line 149
Apr 27 11:15:12 duet3 DuetControlServer[3175]:    at DuetControlServer.Model.Updater.Run() in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/Model/Updater.cs:line 182
Apr 27 11:15:12 duet3 DuetControlServer[3175]: [info] Application has shut down
Apr 27 11:15:12 duet3 systemd[1]: duetcontrolserver.service: Succeeded.

SSH connections are stable though ...

A Former User

@Garfield it needs to evolve a little, but it has a sibling that will identify and flash any duet 2 wifi/ethernet/maestro or duet 3 with the correct firmware in any state as long as usb is working. that might be proposed for the doczuki/wiki when polished.

anyways, glad you found it helpful in the end, the goal is in the end to take the guesswork out of the flashing when necessary.