1 Reply Latest reply on Feb 13, 2013 4:55 AM by ramav_01

    HEX file gets corrupted but SPT file works


      I've contacted Cypress support about this one yesterday, but have not had a reply yet so thought I would try the forums...


      I am currently looking at adding Windows 7 64-bit support for an existing product based on the EZ-USB FX2LP chip. Currently I use the cyusb driver to download a .spt file to the chip. Once downloaded, I then interface to the firmware using a driver created by Jungo WinDriver. This works well in Windows XP, but the introduction of driver signature enforcement in Windows 7 means that this approach will no longer work (it is not acceptable to make our customers press F8 on startup in order to disable the signature enforcement).

      I understand that it is possible to get the cyusb driver signed, but it seemed simpler to remove the cyusb driver altogether and extend the driver created with Jungo WinDriver to download the firmware. As part of the WinDriver toolkit Cypress has provided an example of how to do this called "firmware_sample", which I have followed closely. The sample downloads the firmware from a .hex file rather than a .spt file. The other difference is that the download is not done automatically by the driver when the device is connected, but instead an API function in the driver's DLL is called by the software. The solution works well, I can connect to the device and the code runs as expected, expect for a small piece of the code which appears to be corrupted. When I exercise this part of the code the firmware crashes. This does not happen using the old cyusb method.

      The section of the code that crashes is attempting to write to Port C, but I believe this is just coincidence, because the same port is written to in other parts of the code without any problems. Please can anyone suggest a reasons why there would be a difference in the way the code behaves when it is downloaded as a .hex file in the software rather than as a .spt file by the cyusb driver.