Page 1 of 2

Problem with DFU in XUF208

Posted: Fri Feb 09, 2018 3:02 pm
by AlexAdvice
Hello jents,

I don't understand what I'm doing wrong, will be very appreciate any help!

I have a project with XUF208-128-TQ64-C10, based on an Audio Reference Design.

Makefile consists of the following line:
BUILD_FLAGS = -DFLASH_MAX_UPGRADE_SIZE=128*1024 -fcomment-asm -Xmapper --map -Xmapper MAPFILE -Wall -O3 -report -lquadflash -fsubword-select -save-temps -g -DSDA_HIGH=2 -DSCL_HIGH=1 -DXUD_SERIES_SUPPORT=4 -march=xs2a -DUSB_TILE=tile[0] -DU208_ONLY
-------------------------------------------

I compiled 3 different versions and got 3 files: MyApp0.xe, MyApp1.xe and MyAp2.xe and generate MyKey.key file for security.

Then I make factory image:
xflash --factory MyApp0.xe -o MyApp0.bin --key MyKey.key

and 2 upgrade images:
xflash --factory-version 14.2 --upgrade 1 MyApp1.xe -o MyApp1up.bin --key MyKey.key
xflash --factory-version 14.2 --upgrade 2 MyApp2.xe -o MyApp2up.bin --key MyKey.key

Then I burn the factory image to CPU:
xflash --target-file MyHardware.xn --write-all MyApp0.bin
xburn --target-file MyHardware.xn --lock MyKey.key --enable-jtag --disable-master-lock

As you see - I temporary leaved JTAG enabled, and it was good!

Everything works fine.

Then I use DFUapp software and make upgrade to MyApp1up - OK
Then I use DFUapp software and make upgrade to MyApp2up - OK

Then using dfucons I made revertfactory - still OK.
------------------------------------------------------

After this I make FW update with MyApp1up again, all OK, but after - I tried to use the wrong binary file - I simply not make it encrypted:
xflash --factory-version 14.2 --upgrade 2 MyApp2.xe -o MyApp2up_noenc.bin

So in flash memory should be 3 images:
N0: Factory Image with bootloader
N1: 1st Update (normal) image,
N2: 2nd Update (wrong) image.

After this my device stop working. PC do not see it and I cannot run dfucons to return back to the factory firmware.
I'd expect that the bootloader will see the wrong image N2 and will run the image N1 or N0.
But not, device is unusable.
As I leaved JTAG enabled, I can burn the factory image again and device will work.

But I do not understood why the wrong image was not detected and no roll-back to the previous version occures?
This means that any user can easy destroy the device by using DFU with the wrong file!
And if CPU is locked and JTAG is disabled - there need to replace CPU chip!

I do not think that this is expected behavior, so It is my fault. Bur where?!

Re: Problem with DFU in XUF208

Posted: Mon Feb 12, 2018 12:37 pm
by mon2
Hello. Not an audio developer but have you seen this document?

https://www.xmos.com/published/usb-audi ... n-advisory

https://www.xmos.com/download/private/U ... 11R%29.pdf

Please post your results after a review.

Re: Problem with DFU in XUF208

Posted: Mon Feb 12, 2018 1:36 pm
by AlexAdvice
Hi,

thanks for the reply.
Yes, I saw in this document:
The issue can be fixed by modifying the dfu.xc source file in module_dfu/src. At
line 142 the following line is within a #if 0 block:
HandleUserDeviceRequest(FLASH_CMD_ERASE_ALL, 1, 0, cmd_data, c_user_cmd);
This #if 0 should be made #if 1 so the above line is now executed.
But I cannot find HandleUserDeviceRequest function in dfu.xc (Audio Ref Design 6.15.2)

Re: Problem with DFU in XUF208

Posted: Mon Feb 12, 2018 2:04 pm
by mon2
Hi. Also unable to locate the reference source code line inside the Audio Ref Design 6.15.2 download. Maybe the bug fix document is for an older Audio Ref Design?

OTP is permanent so be very careful.

Agree that a "corrupt" image (firmware) should be rejected by the DFU process. That would make sense to me.

Suggest that you open a technical support ticket with XMOS for proper assistance. Maybe you have found a DFU tool bug.

Re: Problem with DFU in XUF208

Posted: Mon Feb 12, 2018 2:36 pm
by AlexAdvice
mon2 wrote:Maybe the bug fix document is for an older Audio Ref Design?
Maybe, very old - I did not find it also in 6.1.0 and 6.6.0
mon2 wrote:Suggest that you open a technical support ticket with XMOS for proper assistance. Maybe you have found a DFU tool bug.
How to do this?

Re: Problem with DFU in XUF208

Posted: Mon Feb 12, 2018 2:44 pm
by mon2
Goto xmos.com and create an account (free) and then open your technical support ticket.

Re: Problem with DFU in XUF208

Posted: Mon Feb 12, 2018 6:18 pm
by AlexAdvice
Not exactly clear to which part of the tickets to go, but I'll try.

But I hope that Ross or somebody else from XMOS can answer here.

Re: Problem with DFU in XUF208

Posted: Mon Feb 12, 2018 6:21 pm
by mon2
Please ping me with a private email.

Re: Problem with DFU in XUF208

Posted: Tue Feb 13, 2018 6:43 pm
by infiniteimprobability
The CRC is unencrypted, meaning that a wrongly encrypted image (or unencrypted when expecting encrypted) is still a valid image from the bootloader POV.

See:
http://www.xcore.com/viewtopic.php?t=5926

And for interest, the whole header description:
http://www.xcore.com/viewtopic.php?t=6203

This means your device has loaded a garbage image with a correct CRC.

If you do an xrun --dump-state you will probably see the PC in RAM OK but with an exception thrown?

It's vital that upgrade images are thoroughly tested as an incorrect one could brick a device (unless you add a factory button etc.)

Re: Problem with DFU in XUF208

Posted: Tue Feb 13, 2018 8:23 pm
by AlexAdvice
Hi,
thanks for the reply.
But this is a huge hole in security!
Developer can check the image he make, but this is a good possibility to fraud to user - user make DFU for the wrong image, then return "The Brick" to manufacturer/seller.