I have used secondary bootloader in my project for making custom PID/VID and string descriptor.
I have also changed one line usb_boot.c file and that is,
CyFx3BootUsbStart (CyTrue, myUsbEventCallback); -> CyFx3BootUsbStart (CyFalse, myUsbEventCallback);
To force making re-enum.
I have noticed that on Windows 7 things looks okay but on Windows 10 sometime it becomes fail to download firmware sections in RAM.
To cross verify this issue, I have tried it with default bootloader (0x4b4:0xf3) on which everything works perfectly.
Is there any kind of bug in Secondary bootloader example firmware?
I have debugged DownloadFwToRam() API from CyAPI.cpp file and things become fail sometimes at DownloadBufferToDevice() or UploadBufferFromDevice() functions
if I put 2ms sleep after DownloadBufferToDevice() and 2ms sleep after UploadBufferFromDevice() than things are working fine.
I'm suspecting below code part in Fx3BootAppGcc firmware
Should I move CyFx3BootUsbAckSetup completion function after DmaXfer function ? I'm tgargeting this because by putting sleep in the firmware download application I give some time to firmware for processed in/out data.
Yes, you can try the same since the default timeout for the control transfer is 10sec.
I have seen that on USB 2.0 port there are no issue at all.
only problem with SS ports while downloading fw to system RAM with cy fx3bootappgcc example
why there are no such issues with default west bridge bootloader.
It can respond with both HS/SS ports.
The Default Bootloader enumerates as USB 2.0 Device when connected to USB 2.0/3.0 port.
But the second stage Bootloader can enumerate as a 3.0 device (as in the default example).
Can you please let me know the result after doing the change related to CyFx3BootUsbAckSetup()?
By altering CyFx3BootUsbAckSetup() at the end of data xfer, I don't see any good effect and behaviour is same like download is failed. The only solution I found is enumerated device as USB 2.0 like Westbridge and it works expected. CyFx3UsbBoot(cyfalse,cyfalse) is worked for me. And I'm go with that as I don't required if my secondary bootloader is support superspeed or not. But yes with usb 3.0 connection the problem is same.
- If you like to debug further on this, please check if CyFx3BootUsbDmaXferData() is failing at any point (in failure case)?
- Is it possible to capture a USB trace while the issue occurs?