Why won't DFU erase M25PE20

[Caleb]

I've had no problems with the AT25DF041A device except that it can no longer be sourced. The fab. has been shut-down and liquidated. See: http://www.adestotech.com/pcn/Adesto_LF ... cation.pdf
As far as we can tell, the parts are gone -in SO8 packages anyway. Regardless they are obsolete/EOL.

I tried several parts that are default supported. I was not able to get several of them to work. Generally DFU would write the first upgrade but would not erase - so the second write is corrupt.

I was able to get AT25DF081A to work by specifying its parameters as a custom device. So, that's what we will use in our latest upcoming product.

Normally I use xflash this way:
xflash 1v0_1.xe
xflash --upgrade 1 1v0_2.xe -o dfu_1v0_2.bin

This should be enough but I have not tested any DFU functionality with 13.x tools.

You may have problems if you've re-purposed any of the SPI bus pins:
XS1_PORT_1A
XS1_PORT_1B
XS1_PORT_1C
XS1_PORT_1D
If you're using any of these pins for some other function in your application then you'll need to shut-down any code that writes to these ports when DFU starts.

Something else spooky about DFU:
If I attempt to perform DFU while running the SpdifReceive function then DFU won't work. If I have a SPDIF receiver running then, when DFU start is detected, I send a token to SpdifReceive:
soutct( c_spdif_rx, 0 );
This causes SpdifReceive to return.

I can't tell but I wonder if there's an issue of running out of cycles when DFU starts - and it chokes. You might try cutting-out some processing and see if you can get DFU to work with minimal code running. Then you can start adding things back until DFU breaks and then figure out how to shut-down enough of your application when DFU starts.

Along those lines: decouple() spends a lot of its time burning cycles - constantly checking global variable flags. You can cut this thread back quite a bit using a timerafter delay inside the while(1).

Similar situation here...
...
Flash device: AT25DF041A
...
xflash --boot-partition-size 0x20000 Geek_Out_1V0_1.xe
xflash --factory Geek_Out_1V0_1.xe --upgrade 1 Geek_Out_1V0_2.xe 0x20000 --boot-partition-size 0x20000
Thanks,

[Ross]

Just for the benefit of others, Light contacted me to say that he is up and running. He was using bad xflash commands.

[Light]

Hi, Ross

We are working well both on xflash burner and DFU with the flash IC:
AT25DF041A

And manufacturer told us AT25SF041A is the new one we should use because AT25DF041A is EOL. We change the device ID in SPI-SPEC file with xflash, and we could burn it successfully now.

But we have trouble with DFU here. First of all, we don't know where to customized the XC code in DFU to let them use the new flash IC. (Original related code should be #define DFU_FLASH_DEVICE FL_DEVICE_ATMEL_AT25SF041A)

I tried to use xflash --spi-spec to create the new update file for new flash. But DFU burner just can not burn it.

Please help here.

Thanks.

[Light]

Hi, Ross

We are working well both on xflash burner and DFU with the flash IC:
AT25DF041A

And manufacturer told us AT25SF041A is the new one we should use because AT25DF041A is EOL. We change the device ID in SPI-SPEC file with xflash, and we could burn it successfully now.

But we have trouble with DFU here. First of all, we don't know where to customized the XC code in DFU to let them use the new flash IC.
Original related code should be #define DFU_FLASH_DEVICE FL_DEVICE_ATMEL_AT25SF041A

I tried to use xflash --spi-spec to create the new update file for new flash. But DFU burner just can not burn it.

Please help here.

Thanks.

[larry]

If a problem with support of a particular flash device is suspected, you can try to remove DFU from the test and do an isolated write or erase using xflash alone. As far as I know, xflash and DFU both use the same library for accessing the flash device.