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?!
Problem with DFU in XUF208
-
- XCore Addict
- Posts: 138
- Joined: Sun Feb 23, 2014 11:30 am
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.
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.
-
- XCore Addict
- Posts: 138
- Joined: Sun Feb 23, 2014 11:30 am
Hi,
thanks for the reply.
Yes, I saw in this document:
thanks for the reply.
Yes, I saw in this document:
But I cannot find HandleUserDeviceRequest function in dfu.xc (Audio Ref Design 6.15.2)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.
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.
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.
-
- XCore Addict
- Posts: 138
- Joined: Sun Feb 23, 2014 11:30 am
Maybe, very old - I did not find it also in 6.1.0 and 6.6.0mon2 wrote:Maybe the bug fix document is for an older Audio Ref Design?
How to do this?mon2 wrote:Suggest that you open a technical support ticket with XMOS for proper assistance. Maybe you have found a DFU tool bug.
Goto xmos.com and create an account (free) and then open your technical support ticket.
-
- XCore Addict
- Posts: 138
- Joined: Sun Feb 23, 2014 11:30 am
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.
But I hope that Ross or somebody else from XMOS can answer here.
Please ping me with a private email.
- infiniteimprobability
- XCore Legend
- Posts: 1126
- Joined: Thu May 27, 2010 10:08 am
- Contact:
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.)
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.)
-
- XCore Addict
- Posts: 138
- Joined: Sun Feb 23, 2014 11:30 am
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.
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.