PyTrack not recognised as DFU device

[dandrews]

Yeah, I can connect to the pymakr atom plugin with it. Which is why Im so surprised this doesn't work. I don't suppose there's a means of pushing the firmware via atom?

[jmarcelino]

@dandrews
Are you running dfu-util with sudo? Could be a permissions problem

[dandrews]

No, running with sudo gives the same output

[Xykon]

I would suggest you run sudo tail -f /var/log/kern.log in a second terminal window.

If the board is discovered in DFU update mode you should see the following:

Sep 15 22:03:37 UDOO-X86 kernel: [ 3803.217901] usb 1-2: new full-speed USB device number 34 using xhci_hcd
Sep 15 22:03:37 UDOO-X86 kernel: [ 3803.358711] usb 1-2: New USB device found, idVendor=04d8, idProduct=f014
Sep 15 22:03:37 UDOO-X86 kernel: [ 3803.358728] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0

Once you see this message run sudo dfu-util -D pytrack_0.0.4.dfu within 7 seconds in the other terminal window.

If you see the following instead your board is running in normal mode and dfu-util will not work:

Sep 15 22:03:46 UDOO-X86 kernel: [ 3812.526338] usb 1-2: new full-speed USB device number 35 using xhci_hcd
Sep 15 22:03:46 UDOO-X86 kernel: [ 3812.669469] usb 1-2: New USB device found, idVendor=04d8, idProduct=f013
Sep 15 22:03:46 UDOO-X86 kernel: [ 3812.669486] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 15 22:03:46 UDOO-X86 kernel: [ 3812.669499] usb 1-2: Product: Pytrack
Sep 15 22:03:46 UDOO-X86 kernel: [ 3812.669510] usb 1-2: Manufacturer: Pycom
Sep 15 22:03:46 UDOO-X86 kernel: [ 3812.669518] usb 1-2: SerialNumber: Py343434
Sep 15 22:03:46 UDOO-X86 kernel: [ 3812.676628] cdc_acm 1-2:1.0: ttyACM1: USB ACM device

[jcaron]

@dandrews just to be sure, you have only USB and no battery connected, right?

[dandrews]

@Xykon Apologies for the late reply, day job getting in the way. I ran tail and saw the update mode output you described, but dfu-util still won't recognise PyTrack as a DFU device. Could this perhaps be a driver issue? Am going to attempt on my desktop (also ubuntu, but not a Dell) now to see if there is any difference.

@jcaron 100% pure USB, no battery at all

[dandrews]

Success! Worked on the desktop first time! To that end though, does anyone have an idea as to how I check which driver I have/do not have on my laptop... and which one should I have?

[jmarcelino]

@dandrews
There is no driver, dfu-util communicates directly via libusb.

Are the two Ubuntu versions different? Perhaps one is more locked down?

[dandrews]

@jmarcelino Both are exactly the same version (16.04) The only reason I mention drivers is because I know Dell have to install some proprietary ones when you buy Ubuntu direct from them. But, as you say, it could very well be a case of it being more locked down. I've no real experience in what to do about that though, any thoughts?

[jmarcelino]

This is a very long shot but can you try to disable Bluetooth in your Dell BIOS and try dfu-util again?

[pyoneer]

Using sudo tail -f /var/log/kern.log was indeed helpful! Another marker is btw the displayed info:

Apr 30 15:51:51 tpX270 kernel: [81026.317961] usb 1-4.2: New USB device found, idVendor=04d8, idProduct=f011, bcdDevice= 0.08

You want to look for idProduct=f011. Compare that ID with the table on the firmware update guide. For the pysense expension f011 indicates update mode.

You can also retrieve the same information with the simpler: lsusb command which should yield (among others):

Bus 001 Device 028: ID 04d8:f011 Microchip Technology, Inc. 

Again the info f011 is what you are interested in.

However, even while being in update mode I got the error message from above. What worked for me was to keep holding the button on the Pysense board while executing:

sudo dfu-util -D pysense_0.0.8.dfu 

and a little update: I just had to do a firmware update on a second Pysense expansion board. Things didn't work as before, even though the board was clearly in update mode. This time I just repeated the process a couple of times (unchanged) until it worked ... there seems to be some randomness :(

[jcaron]

@pyoneer It's mostly a matter of timing. Too early and the device is not yet up. Too late and the Pysense has exited DFU mode and booted normally. IIRC the window is about 7 seconds.