10 Replies Latest reply on Nov 28, 2018 3:44 AM by HemanthR_06

    Bootloader loads image to RAM but does not execute it.

    geatc_3736111

      A while ago I was assigned to make a bootloader for a custom board based on Cypress CX3. In order to do that I came up with the idea to make my own custom vendor request because I was told that while there is a hardcoded bootloader on the chip it only works with USB 2 and the custom board only uses USB 3.

       

      I tried using Fx3BootAppGcc firmware that comes with the EZ USB Suite using the fwDownloadApp application on the host. If I use the application with Denebola's implementation of the evaluation kit while it is set to boot from USB and without using Fx3BootAppGcc it successfully transfers the image to RAM and executes it. However this is not the case with the custom board.

       

      When I use Fx3BootAppGcc it downloads the image to RAM but fails to pass control to the entry point of the image uploaded both on the evaluation board and the custom board. So first of all I would like to verify some things.

       

       

      I can also verify that it does pass values to the board because when I used the bootloader as FW on evaluation board and used EZ-USB Suite's control center I succeeded to pass DE AD BE EF to RAM.

       

       

      For starters, I found code for CyAPI library that fwDownloadApp is using in the following link and I would like to verify that it is the same one that is being used in the app if possible.

      occam/indigosdk-2.0.15/third/cyusb at master · Cornell-RPAL/occam · GitHub

       

      If this is indeed the code then I did change the P_id there to be F0 instead of F3 and I also tried to alternatively change the bootloader's P_id to F3 to make the device visible to the app. In both cases it has the same result. I receive a message telling me that programming to RAM was succesfully completed but the device does not change state. (Here I have to let you know that the image file I used is Cx3UvcAS0260.img which is part of OV12895_UVC in the SDK as well and which should alter the device from Bootloader Device to video one). One question here would be which product ID is the proper one of the two ?

       

      Next from the USB Descriptor Files of the bootloader, correct me if I am mistaken but it supports BOS of USB3 capability as implied by  /* SuperSpeed Device Capability */ section and the followup descriptor.

       

      /* Binary Device Object Store Descriptor */

      unsigned char gbBosDesc[] =

      {

          0x05,                           /* Descriptor Size */

          0x0F,                           /* Device Descriptor Type */

          0x16,0x00,                      /* Length of this descriptor and all sub descriptors */

          0x02,                           /* Number of device capability descriptors */

       

       

          /* USB 2.0 Extension */

          0x07,                           /* Descriptor Size */

          0x10,                           /* Device Capability Type descriptor */

          0x02,                           /* USB 2.0 Extension Capability Type */

          0x02,0x00,0x00,0x00,            /* Supported device level features - LPM Support */

       

       

          /* SuperSpeed Device Capability */

          0x0A,                           /* Descriptor Size */

          0x10,                           /* Device Capability Type descriptor */

          0x03,                           /* SuperSpeed Device Capability Type */

          0x00,                           /* Supported device level features  */

          0x0E,0x00,                      /* Speeds Supported by the device : SS, HS and FS */

          0x03,                           /* Functionality support */

          0x00,                           /* U1 Device Exit Latency */

          0x00,0x00                       /* U2 Device Exit Latency */

      };

       

       

      /* Standard Super Speed Configuration Descriptor */

      unsigned char gbSsConfigDesc[] =

      {

          /* Configuration Descriptor Type */

          0x09,                           /* Descriptor Size */

          0x02,                           /* Configuration Descriptor Type */

          0x2C,0x00,                      /* Length of this descriptor and all sub descriptors */

          0x01,                           /* Number of interfaces */

          0x01,                           /* Configuration number */

          0x00,                           /* COnfiguration string index */

          0x80,                           /* Config characteristics - D6: Self power; D5: Remote Wakeup */

          0x32,                           /* Max power consumption of device (in 8mA unit) : 400mA */

       

       

          /* Interface Descriptor */

          0x09,                           /* Descriptor size */

          0x04,                           /* Interface Descriptor type */

          0x00,                           /* Interface number */

          0x00,                           /* Alternate setting number */

          0x02,                           /* Number of end points */

          0xFF,                           /* Interface class */

          0x00,                           /* Interface sub class */

          0x00,                           /* Interface protocol code */

          0x00,                           /* Interface descriptor string index */

       

       

          /* Endpoint Descriptor for Producer EP */

          0x07,                           /* Descriptor size */

          0x05,                           /* Endpoint Descriptor Type */

          0x01,                           /* Endpoint address and description */

          0x02,                           /* Bulk End point Type */

          0x00,0x04,                      /* Max packet size = 1024 bytes */

          0x00,                           /* Servicing interval for data transfers : NA for Bulk */

       

       

          /* Super Speed Endpoint Companion Descriptor for Producer EP */

          0x06,                           /* Descriptor size */

          0x30,                           /* SS Endpoint Companion Descriptor Type */

          0x00,                           /* Max no. of packets in a Burst : 0: Burst 1 packet at a time */

          0x00,                           /* Max streams for Bulk EP = 0 (No streams)*/

          0x00,0x00,                      /* Service interval for the EP : NA for Bulk */

       

       

          /* Endpoint Descriptor for Consumer EP */

          0x07,                           /* Descriptor size */

          0x05,                           /* Endpoint Descriptor Type */

          0x81,                           /* Endpoint address and description */

          0x02,                           /* Bulk End point Type */

          0x00,0x04,                      /* Max packet size = 1024 bytes */

          0x00,                           /* Servicing interval for data transfers : NA for Bulk */

       

       

          /* Super Speed Endpoint Companion Descriptor for Consumer EP */

          0x06,                           /* Descriptor size */

          0x30,                           /* SS Endpoint Companion Descriptor Type */

          0x00,                           /* Max no. of packets in a Burst : 0: Burst 1 packet at a time */

          0x00,                           /* Max streams for Bulk EP = 0 (No streams)*/

          0x00,0x00                       /* Service interval for the EP : NA for Bulk */

      };

       

       

       

       

       

       

      I am using Windows 7 Enterprise SP1 on the computer.

       

      From what I gathered after studying the codes is that fwDownloadApp sends several 0xA0 requests after verifying the contents of the image file and after it verifies its validity and the checksums match a new 0xA0 vendor request is being sent with 0 length that contains the EntryPoint of the image file. On the bootloader side the bootloader is loaded at the end of the memory of the board and once a non zero length 0xA0 request is received, the image is loaded anywhere in between the valid addresses as instructed by wIndex and wValue parameters of the vendor request. Afterwards when a 0xA0 request of zero length is received, the entry point is received, the USB interrupts are masked, the GPIO state is set and then CyFx3BootJumpToProgramEntry(dAddress N) is executed which is supposed to pass control to the entry point of the downloaded image file.

       

      I am struggling to understand why does it fail to work properly so I would welcome any suggestions.

       


      While reading the library CyAPI code I also encountered the following comment at the end of CCyFX3Device::DownloadFwToRam() ...

       

      //Few of the xHCI driver stack have issue with Control IN transfer, due to that below request fails

       

      after which the 0 length 0xA0 request is being generated that is supposed to pass the program entry. If that is the problem how can I fix that ? Would a new custom vendor request replacing the 0xA0 for program entry fix the problem ?

       

      Finally how do I add a new vendor request? Do i simply add another if clause with the new value and write code there? If so is it possible to pass through that the entry point. deinitialize the serial parts if any are initialized (which  i don't think they do ) and then cause a warm reset so the RAM stays intact while the system restarts and how ?

       

      Thank you in advance and sorry for the length of this post.