Why won't DFU erase M25PE20

Technical discussions around xCORE processors (e.g. General Purpose (L/G), xCORE-USB, xCORE-Analog, xCORE-XA).
User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm

Why won't DFU erase M25PE20

Post by Caleb »

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


User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm

Post by Caleb »

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.
User avatar
Ross
XCore Expert
Posts: 768
Joined: Thu Dec 10, 2009 9:20 pm

Post by Ross »

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
User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm

Post by Caleb »

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?
User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm

Post by Caleb »

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.
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?
User avatar
Ross
XCore Expert
Posts: 768
Joined: Thu Dec 10, 2009 9:20 pm

Post by Ross »

Or potentially in the DFU handling between 3.3 and 6.1...

Have you tried 6.4 (with tools 13) at all?
User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm

Post by Caleb »

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.
Ross wrote:Or potentially in the DFU handling between 3.3 and 6.1...

Have you tried 6.4 (with tools 13) at all?
User avatar
Ross
XCore Expert
Posts: 768
Joined: Thu Dec 10, 2009 9:20 pm

Post by Ross »

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.
This should be fixed in 13.0.1 and later:

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.
	
Caleb wrote: Perhaps there's some linker output that reports resource usage by module but I haven't tracked-down such a report.
-report should do this:

Code: Select all

-report                  Display a summary of resource usage
Light
Member++
Posts: 21
Joined: Thu Jun 03, 2010 9:39 am

Post by Light »

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,
User avatar
Ross
XCore Expert
Posts: 768
Joined: Thu Dec 10, 2009 9:20 pm

Post by Ross »

What XMOS based firmware version please?

Also, please try with 13.0.2 tools.
Light wrote:
* Command line to program the flash...

xflash --boot-partition-size 0x20000 Geek_Out_1V0_1.xe
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 generate upgrade image...

xflash --factory Geek_Out_1V0_1.xe --upgrade 1 Geek_Out_1V0_2.xe 0x20000 --boot-partition-size 0x20000
hmm I normally use:

Code: Select all

 xflash --factory-version <12 or 13> --upgrade 1 input.xe  -o output.bin