We're finding that most flash devices that are enabled by default in liblfash going EOL. We've been using AT25DF041A in two products but it is now unabailable.
I'm attempting to use M25PE20 - hoping that, since it is supported by the library by default, it could be a drop-in replacement.
I find that XFLASH will write a factory image and the first DFU upagrade 1 will work. Repeating DFU upgrade 1 (with a revisied program), the image is faulty and booting reverts to the factory image. I assume that erasing the original upgrade image is failing.
I've also tried to use the SpecMacros.h definition of parameters of the M25PE20 with no better results:
#define DFU_FLASH_DEVICE FL_DEVICE_ST_M25PE20
Am I missing something?
thanks
Why won't DFU erase M25PE20
-
- Experienced Member
- Posts: 82
- Joined: Thu Apr 04, 2013 10:14 pm
-
- Experienced Member
- Posts: 82
- Joined: Thu Apr 04, 2013 10:14 pm
NOTE: This was re-psted from Q&A because Ross told me that it's a FAQ and didn't belong in Q&A.
Perhaps some clarification is necessary.
I've used other flash devices that are supported by default by libflash for DFU upgrading. For those devices I get successful writing and re-writing DFU images.
When using the M25PE20 I get different results: re-writing an upgrade image results in a corrupt image. It appears that the upgrade sector is not successfully erased.
I've tried operating M25PE20 as a default device as well as specifying it as a custom device using the parameters from SpecMacros.h.
Perhaps some clarification is necessary.
I've used other flash devices that are supported by default by libflash for DFU upgrading. For those devices I get successful writing and re-writing DFU images.
When using the M25PE20 I get different results: re-writing an upgrade image results in a corrupt image. It appears that the upgrade sector is not successfully erased.
I've tried operating M25PE20 as a default device as well as specifying it as a custom device using the parameters from SpecMacros.h.
-
- XCore Expert
- Posts: 972
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
An issue with erasing seems like a reasonable assumption. I assume the DFU is reported as successful?
What host program are you using BTW?
Not really a Q&A since it probably requires discussion and not a question with a simple, definitive answer
What host program are you using BTW?
Not really a Q&A since it probably requires discussion and not a question with a simple, definitive answer
-
- Experienced Member
- Posts: 82
- Joined: Thu Apr 04, 2013 10:14 pm
Hi, Yes - DFU operation is reported successful. I'm using the xmosusbaudiost300D_dfuapp.exe included with our XMOS-customized production driver v2.15.
Ross wrote:An issue with erasing seems like a reasonable assumption. I assume the DFU is reported as successful?
What host program are you using BTW?
-
- Experienced Member
- Posts: 82
- Joined: Thu Apr 04, 2013 10:14 pm
Also,
I installed a M25PE20 flash in an older product that's based on a L1 processor with a program based on the L1 Audio Ref. project version 3.2 and built with 11.11.1 tools.
In this environment repeat DFU upgrades work.
DFU erase is failing with this flash device in my current project: U8 processor with a program based on the Audio Ref. project version 6.1 and built with 12.2.2 tools.
Based on this, I'm inclined to believe that a bug was introduced in flashlib between the two software ref. projects.
I installed a M25PE20 flash in an older product that's based on a L1 processor with a program based on the L1 Audio Ref. project version 3.2 and built with 11.11.1 tools.
In this environment repeat DFU upgrades work.
DFU erase is failing with this flash device in my current project: U8 processor with a program based on the Audio Ref. project version 6.1 and built with 12.2.2 tools.
Based on this, I'm inclined to believe that a bug was introduced in flashlib between the two software ref. projects.
Ross wrote:An issue with erasing seems like a reasonable assumption. I assume the DFU is reported as successful?
What host program are you using BTW?
-
- XCore Expert
- Posts: 972
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
Or potentially in the DFU handling between 3.3 and 6.1...
Have you tried 6.4 (with tools 13) at all?
Have you tried 6.4 (with tools 13) at all?
-
- Experienced Member
- Posts: 82
- Joined: Thu Apr 04, 2013 10:14 pm
I have not.
I attempted to build this project in 13.?. I can't remember which 13 (I'm at home) but probably 13.0.0.
I gave up at that time because something in 13 added another timer. My project was already using all of the timers. Perhaps there's some linker output that reports resource usage by module but I haven't tracked-down such a report.
When I have a chance I will try to make a build with the latest tools and adapt reference software project for our hardware so I can test that DFU against this flash device.
I attempted to build this project in 13.?. I can't remember which 13 (I'm at home) but probably 13.0.0.
I gave up at that time because something in 13 added another timer. My project was already using all of the timers. Perhaps there's some linker output that reports resource usage by module but I haven't tracked-down such a report.
When I have a chance I will try to make a build with the latest tools and adapt reference software project for our hardware so I can test that DFU against this flash device.
Ross wrote:Or potentially in the DFU handling between 3.3 and 6.1...
Have you tried 6.4 (with tools 13) at all?
-
- XCore Expert
- Posts: 972
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
This should be fixed in 13.0.1 and later:Caleb wrote: I attempted to build this project in 13.?. I can't remember which 13 (I'm at home) but probably 13.0.0.
I gave up at that time because something in 13 added another timer. My project was already using all of the timers.
Code: Select all
* flash programming
* The flash loader leaves one timer allocated, resulting in a runtime trap if the application tries to use all the timers available on the device.
-report should do this:Caleb wrote: Perhaps there's some linker output that reports resource usage by module but I haven't tracked-down such a report.
Code: Select all
-report Display a summary of resource usage
-
- Member++
- Posts: 21
- Joined: Thu Jun 03, 2010 9:39 am
Similar situation here...
Environment:
XMOS device: XS1-SU8
Flash device: AT25DF041A
* in customdefines.h
#define DFU_FLASH_DEVICE FL_DEVICE_ATMEL_AT25DF041A
* Tool: 13.0.1
* Command line to program the flash...
xflash --boot-partition-size 0x20000 Geek_Out_1V0_1.xe
* Command line to generate upgrade image...
xflash --factory Geek_Out_1V0_1.xe --upgrade 1 Geek_Out_1V0_2.xe 0x20000 --boot-partition-size 0x20000
* Issue: When use Theyscon driver on Windows to upload the upgrade image. The program reported successfully. But USB device reboot then only see the original firmware there.
Please let us know more details and insights.
Thanks,
Environment:
XMOS device: XS1-SU8
Flash device: AT25DF041A
* in customdefines.h
#define DFU_FLASH_DEVICE FL_DEVICE_ATMEL_AT25DF041A
* Tool: 13.0.1
* Command line to program the flash...
xflash --boot-partition-size 0x20000 Geek_Out_1V0_1.xe
* Command line to generate upgrade image...
xflash --factory Geek_Out_1V0_1.xe --upgrade 1 Geek_Out_1V0_2.xe 0x20000 --boot-partition-size 0x20000
* Issue: When use Theyscon driver on Windows to upload the upgrade image. The program reported successfully. But USB device reboot then only see the original firmware there.
Please let us know more details and insights.
Thanks,
-
- XCore Expert
- Posts: 972
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
What XMOS based firmware version please?
Also, please try with 13.0.2 tools.
Also, please try with 13.0.2 tools.
Looks okay to me, though if you are not using a data-partition you can drop the boot-partition size option.Light wrote:
* Command line to program the flash...
xflash --boot-partition-size 0x20000 Geek_Out_1V0_1.xe
hmm I normally use:Light wrote:
* Command line to generate upgrade image...
xflash --factory Geek_Out_1V0_1.xe --upgrade 1 Geek_Out_1V0_2.xe 0x20000 --boot-partition-size 0x20000
Code: Select all
xflash --factory-version <12 or 13> --upgrade 1 input.xe -o output.bin