MicroPython Forum (Archive)

Posted: **Wed Oct 30, 2019 11:05 am**

Device is SF2, Tthe first download completes in just a few seconds, the second one is VERY slow, I timed it and it took 20 Mins to download the second partition.

The device is also behaving strangely and previously working bluetooth code now crashes the device (viewtopic.php?f=20&t=7161).

Code: Select all

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Match vendor ID from file: 0483
Match product ID from file: df11
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
file contains 1 DFU images
parsing DFU image 1
image for alternate setting 0, (2 elements, total size = 972712)
parsing element 1, address = 0x08008000, size = 427304
Download	[=========================] 100%       427304 bytes
Download done.
parsing element 2, address = 0x90000000, size = 545392
Download	[====                     ]  19%       106496 bytes

It took roughly 20 minutes to download the second image:

Code: Select all

parsing element 2, address = 0x90000000, size = 545392
Download	[=========================] 100%       545392 bytes
Download done.
done parsing DfuSe file

Posted: **Wed Oct 30, 2019 11:21 pm**

I have tried this on 2 different computers now, and the result is the same, so it's definitely a problem with the SF2 device !

@damien - any idea what may be causing this ??

Posted: **Thu Oct 31, 2019 7:57 am**

make ... deploy works as expected with firmware built from today's source.

Posted: **Thu Oct 31, 2019 11:12 pm**

Thanks Peter, yes I have tested another SF6 device and that is no problem, so it seems to be a hardware issue with this SF2.

Posted: **Fri Nov 01, 2019 5:03 am**

It has now just started failing after about 10 - 15 minutes:

Code: Select all

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Match vendor ID from file: 0483
Match product ID from file: df11
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
file contains 1 DFU images
parsing DFU image 1
image for alternate setting 0, (2 elements, total size = 972712)
parsing element 1, address = 0x08008000, size = 427304
Download	[=========================] 100%       427304 bytes
Download done.
parsing element 2, address = 0x90000000, size = 545392
Download	[===========              ]  47%       260096 bytesdfu-util: Error during download get_status

Posted: **Fri Nov 01, 2019 9:57 am**

As I understand it the SF6 stores the firmware in on-chip flash, whereas the SF2 stores much of it in one of the external flash chips. You'll notice that SF6 upload takes place in one pass whereas SF2 is in two passes and it's on the second pass where your upload is failing. So my (non-expert) guess is that the flash chip is failing.

Perhaps @Damien or @jimmo can advise.

Posted: **Fri Nov 01, 2019 10:48 am**

This really sounds like a hardware issue with the external QSPI flash, the memory-mapped one.

The only thing I can suggest at this stage is to remove the PYBD_SF2 completely from anything connected to it, and power it up over USB and measure the current draw using a USB power meter. It should draw about 22mA at an idle REPL.

Posted: **Sat Nov 02, 2019 3:33 am**

I measured the idle current consumption to be about 90ma, but I am able to access the REPL so the device is certainly not dead, but partially disabled !

Does this mean that it is time for the bin ??

Posted: **Sat Nov 02, 2019 7:10 am**

That probably depends on George Robotics warranty replacement policy. Failing that, your skills at replacing an SMD device - the QSPI flash chip.

Posted: **Mon Nov 04, 2019 12:59 am**

Like Damien said, almost certainly sounds like a failure of the memory mapped external QSPI flash. But just to elaborate, the reason you only see this when you flash or enable BLE, but other things like the REPL work fine is that only certain specific bits of code are put on the external flash (the BLE stack being one of them!). Most of the code actually runs from the internal flash, and your Python scripts on the filesystem are on the other external QSPI flash.

As Peter said, I think you might need to contact George Robotics about this -- http://micropython.org/contact/

MicroPython Forum (Archive)

DFU flashing 2nd partition takes 20 minutes

DFU flashing 2nd partition takes 20 minutes

Re: DFU flashing takes 20 minutes

Re: DFU flashing 2nd partition takes 20 minutes

Re: DFU flashing 2nd partition takes 20 minutes

Re: DFU flashing 2nd partition takes 20 minutes

Re: DFU flashing 2nd partition takes 20 minutes

Re: DFU flashing 2nd partition takes 20 minutes

Re: DFU flashing 2nd partition takes 20 minutes

Re: DFU flashing 2nd partition takes 20 minutes

Re: DFU flashing 2nd partition takes 20 minutes