Problem with DFU in XUF208

Technical questions regarding the XTC tools and programming with XMOS.
AlexAdvice
XCore Addict
Posts: 138
Joined: Sun Feb 23, 2014 11:30 am

Problem with DFU in XUF208

Post 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?!


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

Post 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.
AlexAdvice
XCore Addict
Posts: 138
Joined: Sun Feb 23, 2014 11:30 am

Post 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)
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post 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.
AlexAdvice
XCore Addict
Posts: 138
Joined: Sun Feb 23, 2014 11:30 am

Post 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?
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Goto xmos.com and create an account (free) and then open your technical support ticket.
AlexAdvice
XCore Addict
Posts: 138
Joined: Sun Feb 23, 2014 11:30 am

Post 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.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Please ping me with a private email.
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post 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.)
AlexAdvice
XCore Addict
Posts: 138
Joined: Sun Feb 23, 2014 11:30 am

Post 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.
Post Reply