Long timing on function flash_is_sector_erased() causes I2C DFU failure for _INT

[ed-xmos]

I have found a function flash_is_sector_erased(), many layers down in DFU, which is taking over 5ms to complete. This causes back pressure up through get_stat_from_dnload() to requrest_with_arguments() to request() to dfu_handle_read_command() called from case dfu_control_interface.read_command: in gpio_server.xc in XVF3610

rdwr ioctl error -1: Remote I/O error
error: control read command did not return success

A salae logic trace is attached (open in Logic app) that shows at 78ms a get status packet which is followed by 4.7ms of clock stretching. This causes the host transfer to fail. This host is clearly intolerant to clock stretching.

DFU fail I2C XVF3610.logicdata.zip

Changing this function to return true immediately results in successful DFU. Below are some debug prints from dfu.xc. I added tick timers (10ns) to show iterations through flash_is_sector_erased() and it clocking up 5ms (~500000 ticks)..

dfu_control_interface.read_command....complete (1489 9 2491)
dfu_control_interface.read_command..
dfu_handle_read_command: DFU_CMD_GETSTATUS
dfu_control_interface.read_command....complete (1489 9 2491)
dfu_control_interface.read_command..
dfu_handle_read_command: DFU_CMD_GETSTATUS
dfu_control_interface.read_command....complete (1489 9 2495)
dfu_control_interface.read_command..
dfu_handle_read_command: DFU_CMD_GETSTATUS
dfu_control_interface.read_command....complete (1489 9 2491)
dfu_control_interface.read_command..
dfu_handle_read_command: DFU_CMD_GETSTATUS
(flash_is_sector_erased)
time: 28061 page_address: 0x103000
time: 59349 page_address: 0x103100
time: 90329 page_address: 0x103200
time: 121305 page_address: 0x103300
time: 152387 page_address: 0x103400
time: 183474 page_address: 0x103500
time: 214557 page_address: 0x103600
time: 245640 page_address: 0x103700
time: 276722 page_address: 0x103800
time: 307804 page_address: 0x103900
time: 338891 page_address: 0x103a00
time: 369974 page_address: 0x103b00
time: 401056 page_address: 0x103c00
time: 432138 page_address: 0x103d00
time: 463225 page_address: 0x103e00
time: 494308 page_address: 0x103f00
dfu_control_interface.read_command....complete (1489 9 548720)

[ed-xmos]

Here are a few timings (in 10ns ticks) for this function..
https://github.com/xmos/lib_dfu/blob/develop/lib_dfu/src/dfu_flash.xc#L86

fl_getSectorContaining time: 13044
fl_getSectorAtOrAfter time: 6543
time: 6927 2051 page_address: 0x103000
time: 6927 2051 page_address: 0x103100
...

So you can see that the page read and blank check are around 9000 ticks per page, so that's ~144000 ticks per sector. However the fl_get... lib functions are taking 13000 + 6500 = 19500 ticks per page. Add that up and multiply by 16 for a sector, and you get to ~450000 ticks (4.5ms).

[ed-xmos]

I have since tried this on a fresh AVS setup (which supports clock stretching) and can confirm the dfu completes successfully and tolerates the 5ms clock stretching. So this issue is purely related to devices that cannot tolerate clock stretching.

[humphrey-xmos]

I guess this is resolved now?