picotool save: 2M range produces a 4M .uf2

[Gadgetoid]

I'm using the following command to dump the contents of an RP2 based board to a .uf2:

picotool save --range 0x10000000 0x10200000 filename.uf2

I expect this to produce a 2M binary, but the result is 4M in size:

4.0M Apr 23 14:23 filename.uf2

Attempting to load this file results in an error at various degrees of progress:

picotool load filename.uf2
Loading into Flash: [==========                    ]  35%
ERROR: Communication with RP2040 device failed

picotool load filename.uf2
Loading into Flash: [============================= ]  97%
ERROR: Communication with RP2040 device failed

For context we're trying to snapshot a configured CircuitPython installation so that a board can be shipped with a ready-to-go example. Here's the board info:

Program Information
 name:            CircuitPython
 version:         6.2.0
 web site:        https://circuitpython.org
 features:        double reset -> BOOTSEL
 binary start:    0x10000000
 embedded drive:  0x00100000-0x00200000 (1024K): CircuitPython

Fixed Pin Information
 none

Build Information
 build date:        2021-04-05
 build attributes:  BOARD=pimoroni_keybow2040

Device Information
 flash size:   2048K
 ROM version:  2

I'm working upon the assumption that the "embedded drive" is an offset to the binary start, but this board only has a 2M flash part anyway so a full flash dump is feasible. My "failed" flashes seem to verify okay with picotool verify.

Flashing the 4M binary using the drag-and-drop seems to give mixed results. Some boards work, some don't. Perhaps writing a larger-than-the-flash-size file over USB causes it to loop from the start of the flash and corrupt the binary if the board doesn't catch it and reset quickly enough?

[lurch]

I expect this to produce a 2M binary, but the result is 4M in size:

I was surprised when I first saw this too, but then I dug into the UF2 specs and found that's just "how UF2 works" - the UF2 is always double the size of the actual image. If you save to a .bin file instead of a .uf2 then you get the size you'd expect :wink: (afraid I can't comment on your flashing error)

[kilograham]

I have never seen the partial flashing... attach (or send) the UF2 and I'll try and repro it on mine.

[kilograham]

may also be caused by too much power draw on ancillary LED strings.

[Gadgetoid]

Here's the file -

keybow2040-release-firmware-cpy-6.2.0-2021-04-23-2M.zip

Tried it a couple more times after rebooting and it still happens.

We've got plenty of ancillary LED strings, but they're not active during this process. That said I've got a heck of a daisy-chained USB setup here (oh for the want of more ports) so there's that...

Edit: waddya know, plugging the board directly into an upstream USB port makes flashing work fine every time. And I've been using a Picoprobe and Pico board connected to my Pi keyboard to debug and test for months now!

[kilograham]

How daisy-chained are you - i have a lot of USB hubs, but more in a shallow tree.

You could try turning on some debugging here in picotool

https://github.com/raspberrypi/picotool/blob/8d4b1d31082442e961d3165c67b6d8ae32a81581/picoboot_connection/picoboot_connection.c#L14

I wonder if something is just timing out (as we know other connected terminals via CDC spam the wire with traffic) so might be worth seeing if you have any of those and that makes a difference.