Steps for debugging DFU Problems

All the latest news and announcements from XCore and XMOS.
User avatar
Thomas
Active Member
Posts: 53
Joined: Fri Feb 05, 2010 12:34 pm

Steps for debugging DFU Problems

Postby Thomas » Fri Dec 02, 2016 9:59 am

In case of problems with DFU (Device Firmware Upgrade), the following steps are recommended.
This is primarily for the DFU mechanism used by the USB Audio Reference Design.
https://www.xmos.com/published/usb-audi ... sign-guide
But the methodology can also be applied to other DFU mechanisms.

1. Write down differences between working system and non working system
To identify the root cause, it is important to analyse key differences of HW and SW between a working reference system and the non-working system.
Specifically:
* SPI Flash HW Interface
* SW changes to DFU logic
* SW changes to Endpoint 0
* Any additional tasks. They reduce the amount of MIPS

2. Check that the XUD has at least 80 MIPS
This Requirement is stated in Chapter
3.12 Resource Usage of USB Audio Design Guide
https://www.xmos.com/published/usb-audi ... sign-guide

On xCORE-200 the XUD can be configured to be a priority core which will give it 100 MIPS.
This is required if > 6 cores are running on the USB tile.

3. Force the Device to boot in DFU mode
The advantage is that the debugger can be used to step through the code and pinpoint where the DFU logic fails.

The device can be forced to boot in DFU mode by hardcoding the return value of GetDFUFlag() in dfu.xc to 0x11042011:

Code: Select all

static unsigned GetDFUFlag()
{
    unsigned x;
    //asm volatile("ldw %0, %1[0]" : "=r"(x) : "r"(FLAG_ADDRESS));
    //return x;
    return 0x11042011;
}


The value 0x11042011 is taken from HandleDfuRequest:

Code: Select all

 
  case XMOS_DFU_RESETINTODFU:
    reset_device_after_ack = 1;
    dfu_reset_override = 0x11042011;                                                                                               
    return_data_len = 0;
    break;


4. If you need to analyse the flash content, two useful tools are available:
- Utility to interrogate the boot partitions of the flash: https://github.com/ThomasGmeinder/app_flash_util
- Read the content of the flash with xflash --read-all. Then compare it with a diff tool like Hex Fiend
User avatar
infiniteimprobability
XCore Legend
Posts: 1108
Joined: Thu May 27, 2010 10:08 am
Contact:

Postby infiniteimprobability » Fri Dec 02, 2016 11:05 am

Read the content of the flash with xflash --read-all. Then compare it with a diff tool like Hex Fiend

^^This is a very good call. I had a case where the image was truncated and a binary diff immediately revealed this.

To get the binary image programmed to compare with what is read back from the flash, use:

Code: Select all

xobjdump --strip <appname>.xe

This will produce an .xb file which is the raw binary programmed into the flash.

My issue turned out to be the define in the Makefile

Code: Select all

BUILD_FLAGS     = -DFLASH_MAX_UPGRADE_SIZE=64*1024

I had added a lot to the reference design and and exceeded 64KB of code space... This define is in there to speed things up (only erase up to 64KB) and is OK in 99% of cases.

Who is online

Users browsing this forum: No registered users and 5 guests