Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

P1 dfu-util 0.8 does not read/write from External Flash #706

Closed
jakeypoo opened this issue Oct 20, 2015 · 6 comments

Comments

@jakeypoo
Copy link
Contributor

commented Oct 20, 2015

Trying to read/write to the external flash on the P1 in the same way that I used to on the Core on alt interface 1, I've run into some issues.

dfu-util -l gives an interface I assume is the external SPI flash on the P1
Found DFU: [2b04:d008] ver=0200, devnum=10, cfg=1, intf=0, alt=2, name="@serial Flash /0x00000000/256*004Kg", serial="00000000010C"

However trying to write to this interface via dfu-util -d 2b04:d008 -a 2 -s 0 -D test.bin gives an error that I don't see with the same command to other alt interfaces :

Opening DFU capable USB device...
ID 2b04:d008
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
DfuSe interface name: "Serial Flash "
dfu-util: Only DfuSe file version 1.1a is supported
dfu-util: (for raw binary download, use the --dfuse-address option)

Trying to read from this interface works, however the file that gets downloaded is not the external flash.
In fact the file that gets downloaded seems to start at the same address as the last dfu-util upload operation performed :
For example if I run
dfu-util -d 2b04:d008 -a 0 -s 0x08020000:1024 -U test1.bin
dfu-util -d 2b04:d008 -a 2 -s 0:1024 -U test2.bin
The two files are identical.

I've run some tests with sFLASH_... commands on the P1 and they seem to work. But I can't seem to get the dfu-util part to work.

@m-mcgowan m-mcgowan added this to the 0.4.8 milestone Oct 20, 2015

@m-mcgowan

This comment has been minimized.

Copy link
Contributor

commented Oct 20, 2015

Thanks for this - it is a known issue. There is some missing code in the bootloader that isn't taking into account the "alternate" setting from DFU and instead tries to determine the memory from the address only. This fails since both DCT and external flash start with address 0.

We have a PR for this which I'll cherry pick the appropriate commits and have this released for the next version.

@jakeypoo

This comment has been minimized.

Copy link
Contributor Author

commented Oct 20, 2015

Awesome! Thanks.
Sorry this is unrelated, is this memory reserved for anything? or can we allocate the whole thing for whatever we need at the application layer?

I haven't been able to find much documentation on the external flash.

@m-mcgowan

This comment has been minimized.

Copy link
Contributor

commented Oct 20, 2015

Nothing is reserved in external flash, so feel free to use it for whatever you want!

@m-mcgowan m-mcgowan modified the milestones: 0.4.9, 0.4.8 Dec 14, 2015

@m-mcgowan

This comment has been minimized.

Copy link
Contributor

commented Jan 15, 2016

There are two issues I found here:

  • writing to address 0 isn't supported by dfu-util at present (presumably an oversight.) They use set the address to a variable like uint32_t address, then test if an address has been given by comparing it for non-zero. Naturally a 0 address will fail this test. (The line of code is here - http://sourceforge.net/p/dfu-util/dfu-util/ci/master/tree/src/dfuse.c#l629 - I'll put it on the backlog to submit a PR.)
  • on the P1, the compiler optimizations were breaking DFU reads/writes in the bootloader. (In order to fit into the available space we use fairly agressive link time optimization - LTO. This was causing writes to fail - sometimes the flash wasn't erased, or data written. I couldn't determine if the compiler was at fault or the code. The fix was to reduce the optimization level for the external flash routines.

So for the time being, writing to address 0 isn't supported until it's fixed in . You can write to address 1 and up! ;-)

@jakeypoo

This comment has been minimized.

Copy link
Contributor Author

commented Jan 15, 2016

To clarify, currently dfu-util R/W to address 1 will access external flash address 1?

@m-mcgowan

This comment has been minimized.

Copy link
Contributor

commented Jan 15, 2016

Yes, that's correct.

Just thinking about writing to address 0. As a workaround, we could modulo the address by the SPI flash size. The flash is 1MiByte, so 1024*1024 bytes. Writing to that address would write to address 0 in the flash memory, and work around the address 0 bug in dfu-util.

Scratch that - dfu requires that we describe each medium available, including it's size, which is checked.

@m-mcgowan m-mcgowan closed this in 9ff86e2 Jan 15, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.