In DFU state machine bitManifestationTolerant is reversed ?

[HiFiPhile]

While I'm not 100% sure, it seems like bitManifestationTolerant interpretation is reversed in DFU class...

I'm making a very simple bootloader, if I set bitManifestationTolerant dfu-util can no longer communicate with the device once download is finished.

Download        [=========================] 100%        40656 bytes
Download done.
state(7) = dfuMANIFEST, status(0) = No error condition is present
unable to read DFU status after completion

> dfu-util.exe -e

Opening DFU capable USB device...
ID cafe:010b
Run-time device DFU version 0101
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: error get_status

If I clear bitManifestationTolerant dfu-util can still longer communicate with the device once download is finished.

Download        [=========================] 100%        40656 bytes
Download done.
state(2) = dfuIDLE, status(0) = No error condition is present
Done!

> dfu-util.exe -e

Opening DFU capable USB device...
ID cafe:010b
Run-time device DFU version 0101
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0101
Device returned transfer size 128
can't detach

Below is my source code:

void main(void)
{
    if(DFU_Unlock_Reg != DFU_ENTER_KEY)
    {
        APP_Validate_Boot();
    }
    DFU_Unlock_Reg = 0;
    BSP_Init();
    tusb_init();
    while(1)
    {
        tud_task();
    }
}

void tud_umount_cb(void)
{
    S_RST();
}

void tud_suspend_cb(bool remote_wakeup_en)
{
    S_RST();
}

bool tud_dfu_firmware_valid_check_cb(void)
{
    return DFU_Validate();
}

void tud_dfu_req_dnload_data_cb(uint16_t wBlockNum, uint8_t* data, uint16_t length)
{
    (void) data;
    DFU_Unlock_Flash();
    DFU_ErasePage(wBlockNum);
    DFU_ProgramBlock(wBlockNum * 2, data);
    DFU_ProgramBlock(wBlockNum * 2 + 1, data + 64);
    DFU_Lock_Flash();
    tud_dfu_dnload_complete();
}

bool tud_dfu_device_data_done_check_cb(void)
{
    return DFU_Validate();
}

void tud_dfu_abort_cb(void)
{
    S_RST();
}

uint16_t tud_dfu_req_upload_data_cb(uint16_t block_num, uint8_t* data, uint16_t length)
{
    (void) block_num;
    (void) length;
    
    return 0;
}

tinyusb/src/class/dfu/dfu_device.c

Line 477 in 681a61d

if ((_dfu_state_ctx.attrs & DFU_FUNC_ATTR_MANIFESTATION_TOLERANT_BITMASK) != 0)

[hathach]

Yeah, I think you are right, the logic seems to be inverted. Maybe submit an PR to fix it, so that we could request review from @xmos-jmccarthy. IMHO, actually, I don't think we really need to follow these rule anymore in the firmware. this bit is for old hardware when it use 100% cpu or the flashing just blocking disable whole interrupt which is hardwarely block usb communication. Otherwise, if we could receive the request in this manifest state, It means we could response, therefore no need to ignore it.

[HiFiPhile]

I don't think we really need to follow these rule anymore in the firmware.

In fact it's somehow useful with Windows. On Linux I can issue a USB reset once the flash is done as dfu specification. But on Windows there is no way to issue USB reset without unplug it, so if I update it remotely it can stuck in DFU. Now what I done is reboot automatically to user application once flash is done.

[hathach]

I mean even when the bitManifestationTolerant = 0, the dfu driver should still response to all USB request if it receives it. Once all dfu data is written, it just simply reset() itself. USB device nowsaday is capable of self-resetting, and/or self-disconnect/reconnect without host help with bus_reset at all. Therefore there is no reason to wait for BUS_RESET when it is done with flashing