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;
}
Code: Select all
case XMOS_DFU_RESETINTODFU:
reset_device_after_ack = 1;
dfu_reset_override = 0x11042011;
return_data_len = 0;
break;
- 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
