DFU questions

Technical questions regarding the XTC tools and programming with XMOS.
dweeb4
Active Member
Posts: 52
Joined: Mon Jan 19, 2015 12:47 pm

DFU questions

Post by dweeb4 »

I have a fully working XMOS audio board which uses the XU216-512-TQ128-C20 chip
I want to repurpose it somewhat but wanted to retrieve the existing firmware so I can revert back to stock functionality if needed
Can I use DFU this? I've read the sparse DFU docs which seem to say that DFU commands can be run from within the console in xTIMEcomposer - is this correct - I haven't been able to use this?


User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Personally, would:

1) use the xflash tool with the --read-all -o factory_image.bin and repeat to make another backup (-o factory_image_backup.bin)

2) consider to even remove the flash device from the circuit to read using an external SPI flash reader if you have this option

3) then proceed to erase and use the board as desired. Using xflash, you can then erase and restore the images from file. The end-user would then have to install xflash tool to perform future upgrades.

Alternative ideas are to assemble the PCB with a higher density flash device and upload both firmware images onto the device and select between the firmware. Or consider to switch between 2 physical flash devices. The XU216-512-TQ128-C20 does not offer internal flash storage.

Code: Select all

--read-all

Reads the contents of all memory on the flash device and writes it to a file on the host. Must be used with -o.
dweeb4
Active Member
Posts: 52
Joined: Mon Jan 19, 2015 12:47 pm

Post by dweeb4 »

Thanks for the reply, mon2 but this working board has no flash chips, just the XU216-512-TQ128-C20 chip
Am I missing something?

I was looking for how to implement what I read in the DFU document - where do I run this command from - xIMEcomposer's console screen?

Code: Select all

3.3 Uploading existing firmware from the device
You can retrieve a firmware image from the device, providing an upgrade image is
present. Run the command:
dfucons upload currentfirmware.bin
The file currentfirmware.bin contains the latest upgrade image. This file is an
exact copy of the data from the flash and can be downloaded to the device again
to test.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Which XMOS audio board do you have ? Is it from XMOS or XMOS based but 3rd party ?

Please review the markings on the IC, p/n

XUF216-512-TQ128-C20 ; will have internal flash

XU216-512-TQ128-C20 ; will require an external flash

XFLASH stuff..

https://www.xmos.com/support/tools/docu ... ion=latest

http://www.xcore.com/viewtopic.php?f=26&t=2647

Use this document (2016 datecode vs another document which is still active and perhaps stale as it is marked with a 2013 datecode):
https://www.xmos.com/download/private/X ... 74B%29.pdf

We recommend that you test with gentle non-destructive SPI commands to the flash device such as "read the flash ID"

Code: Select all

--spi-read-id cmd
Reads the spi manufacturer’s id from the attached device. The
cmd can be obtained from the spi manufacturer’s datasheet. If there is more than one device in a network
then all id’s will be returned.
The xflash tool depends on the proper SPI pin definition from your .XN file when you compile your source code. Using this information, the tool can communicate with the target SPI flash memory device. In some cases, you can take advantage of the QSPI memory speed vs. standard and slower SPI commands. Varying with your project and code size, there is a benefit to consider QSPI mode where available.

Once you relay the details of your XMOS audio board, can review which device is soldered onto the PCB. Suspecting you have the XUF216 series which features an internal flash memory device.

Update:

1) start with ONLY read commands till you have the comfort of knowing that you are chatting reliably with the flash device

ie. read flash ID is a great start

2) then progress to dumping the flash memory to a target file (binary format is standard by the tool)

3) repeat with another filename for the dump read.

4) Use a freeware binary tool and compare the 2 image files to be sure they are 100% the same

5) only if the files match and look to be logical in size -> then consider to erase and apply your custom firmware

If your board is from XMOS then the firmware should be floating around somewhere here on the xmos.com website already. At the very least you should be able to recompile from the source code to build up the "original XMOS IP". If you do indeed have an external flash device, consider to extract from the IC directly - that is what we did for one of the XMOS board to be extra safe. Now have some zero force ZIF sockets for the 8 pin SOIC footprint to allow for production.
dweeb4
Active Member
Posts: 52
Joined: Mon Jan 19, 2015 12:47 pm

Post by dweeb4 »

This board works without external flash but the documentation says the chip is XMOS XCORE-200 XU216-512

Can you identify if this is XUF216-512-TQ128-C20 or XU216-512-TQ128-C20 ?

Image

Edit: looking up the datasheets for XU216 & XUF216, I can't see any difference in the markings on these ??
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hard to tell but the following webpage notes the (non-internal flash) version:

http://www.diyinhk.com/shop/audio-kits/ ... f-pcb.html

Do you have this board with you now ? What does the backside contain ? Perhaps the SMD flash device is soldered on the backside ?

Or it is possible that this PCB is stuffed with the pin-for-pin replacement with the internal flash (XUF216-512-TQ128-C20). If the flash is truly not visible on the top nor backside of the PCB then this component has to be with internal flash.
dweeb4
Active Member
Posts: 52
Joined: Mon Jan 19, 2015 12:47 pm

Post by dweeb4 »

Yes, no flash memory on the top or bottom of the board - strange XMOS don't id mark their chips so that they can be identified correctly?
Yes, I know their documentation say it's the XMOS XCORE-200 XU216-512 chip which is adding to the confusion

Thanks for taking the time, looking into this

So, I still am unsure how to retrieve & store the firmware before overwriting it?
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Not sure on how protected the CPU can be but considering the vendor is noting that you can obtain firmware for this widget from XMOS, you could probably do the same from XMOS channels. Not into audio but what is this ? An audio device with a VU meter using OLED displays ? Check around the website and you may be able to locate the source and/or binary file for this device.

If the internal flash is not protected, you should be able to read it out. Have you attempted to connect to an external XTAG-3 tool ? If yes, run the xflash tool and attempt to read out the FLASH ID only. DO NOT attempt any writes to this target device till you have a clean backup of the firmware.

This CPU must be with internal flash. About to post some details in a few minutes to compare notes on the markings.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Image

Image
dweeb4
Active Member
Posts: 52
Joined: Mon Jan 19, 2015 12:47 pm

Post by dweeb4 »

Just so as you & I both see that I'm not mad - the datasheets I accessed from Digikey for XU216 & XUF216 show exactly the same markings U1169 - so I'm not insane :)
Furthermore that pic shows the id as U1169C20... & that is the id in the pic - so I'm doubly confused
Where did you retrieve your datasheets from & what dates are on them? Mine from Digikey dated 2016/4/20 (XU216) & 2016/7/26 (XFU216)


Edit: Can't seem to get a large image of these datasheet pages?
Image

Image
Last edited by dweeb4 on Sat Feb 04, 2017 1:14 am, edited 1 time in total.
Post Reply