USB bootloader along with dfuprog exe

Hi Namita,

Are you calling dfuprog -m before calling dfuprog with the download command?

The dfuprog -m is required by itself to get the device into DFU mode.

Regards,

Gautam

Hi Gautam,

Thanks for your reply. I have already tried this command  but still it gives same error.

C:\ti\controlSUITE\device_support\f2806x\v135\MWare\tools\dfuprog\Release>dfupro
g -m

USB Device Firmware Upgrade Example
Copyright (c) 2008-2011 Texas Instruments Incorporated.  All rights reserved.

The driver for the USB Device Firmware Upgrade device cannot be found.
Before running this program, please connect the DFU device to this system
and install the device driver when prompted by Windows.  The device driver
can be found on the evaluation kit CD or can be found in the package named
"TI embedded USB drivers" which may be downloaded from
http://www.ti.com/software_updates.

Reagrds,

Namita

I would like you to go through these links to find some useful tips:

http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/220904.aspx

http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/181516.aspx

Also, forwarding your query to one of my TI buddy.

Regards,

Gautam

Namita,

Let me preface this with the fact that I am embedded software professional and I have little experience with Windows driver software.

That said, I took a look and it looks like the drivers are pulling in an older version of one of the DLLs used to communicate with the board.  This DLL was named lmdfu but was later changed to tidfu.  Dfuprog tries to load tidfu.dll, but because the driver is installing lmdfu.dll it won't work.

To fix this I need to rebuild the tiusb and tidfu DLLs and re-associate them with the driver.  After that everything should work.  Problem is, in order to do this, I need a professional license to Visual Studio, which I don't have.  One of my other team members does though.  I will speak with him and get an updated copy of the files generated.  

Sorry for the trouble.  We'll get this resolved shortly.

BR,

Trey,

Thanks for reply.

Waiting for updated copy of driver.

Regards,

Namita

Hi Trey,

Waiting for updated copy of driver.

Regards,

Namita

Namita,

Don't worry I haven't forgotten :-)

I have an updated copy of the driver here. I just need to test it before I upload it.  I should have it for you shortly.

BR,

Hi Trey,

Thanks for support.

I have installed the new driver & also able to see the DFU device by using -e option but I am not able to program the device using option -f.

C:\ti\controlSUITE\device_support\f2806x\v135\MWare\tools\dfuprog\Release>dfupro
g.exe -e

USB Device Firmware Upgrade Example
Copyright (c) 2008-2011 Texas Instruments Incorporated.  All rights reserved.

Scanning USB buses for supported DFU devices...


<<<< Device 0 >>>>

VID: 0x1cbe    PID: 0x00ff
Device Name:   Device Firmware Upgrade
Manufacturer:  Texas Instruments
DFU Interface: SUPER-BOOT
Serial Num:    0.1
Max Transfer:  1024 bytes
Mode:          DFU
TI Extensions: Not Supported
Attributes:
   Will Detach:       No
   Manifest Tolerant: Yes
   Upload Capable:    Yes
   Download Capable:  Yes

Found 1 device.

C:\ti\controlSUITE\device_support\f2806x\v135\MWare\tools\dfuprog\Release>dfupro
g.exe -f c:\ti\Program.bin

USB Device Firmware Upgrade Example
Copyright (c) 2008-2011 Texas Instruments Incorporated.  All rights reserved.

Scanning USB buses for supported DFU devices...

Downloading c:\ti\Program.bin to device...
Error DFU_ERR_UNSUPPORTED (-5) reported during file download

Regards,

Namita Muley

Hi Trey,

Waiting for reply on above post.

Thanks in advance.

Regards,

Namita Muley

Hi Trey,

Waiting for your reply.

I required it to resolve urgently as I have to test the complete boot loader functionality and integrate with my project.

Thanks in advance.

Regards,

Namita Muley

Hi Trey,

I have done changes in code as per your suggestion. but still I am not able to use erase & program options. It shows  the same error "DFU_ERR_UNSUPPORTED (-5)". I also tried to debug the code during operation but not able to debug it properly.

Is issue related with application code size?

Thanks & Regards,

Namita Muley

No, it looks like there is an identifier which is set incorrectly. That's what I mentioned in the previous post.

Which code were you trying to debug? PC or Embedded?  Both side should be debuggable.  You can debug the PC application with a free copy of Microsoft Visual Studio Express (just google it).

No, the application size isn't an issue at this point.  The PC application is looking for the identifier, but isn't finding it which is why you are getting that error message.

BR,

Hi Trey,

1. We are able to connect the device properly with option -e

2. We are able to erase the entire flash with -c option. We are getting the success message.  But we dont know how to confirm if the flash has really got erased.

3. Also we are still not able to download the hex file using the bootloader code from TI, with the change of 

#define TI_DFU_PROTOCOL_VERSION_C2000_1      0x0001

4. We have tried downloading without any options and with having options like address and length, but it still gives the download error.

The screenshots for your reference are attached herewith. Please let us know what other changes are needed in the code. 

It would be great if you could let us know ASAP, as we need to provide a solution to our client in the next week.

5. We are also planning to create a solution to download the hex file from hyperterminal to device with USB bootloader by using USB-CDC class using ACK-NACK handshaking. Please let us know if you can help us creating this solution or provide it to us if you have it ready with you.

Thanks and Best Regards,

Suvrat

Survat,

I've been working on this all afternoon and I am close to having a solution.  When complete, I will email the solution to your FAE.  This should be within the next 24 hours.

In regard to number 5, I can only support the software that has been released.  I'm happy to answer implementation related questions, but I cannot write the code for you.

BR,

Survat,

Here's a quick update:

I spent the entire afternoon and into the evening working on this.  It looks like the block addressing is what is causing things to break.  I’m honestly not sure why I didn’t catch this when I originally wrote it.  I’m reworking the bootloader, DLL, and PC application to use a standard 32 bit address instead which should resolve the issues we are seeing.  I’ve already made the changes to accomplish this, and I’m currently debugging the new solution.  I expect I will have a working solution sometime tomorrow.

BR,

Hi Trey,

Thanks for the update. Good to know that you are really close to solution.

Eagerly waiting for the working solution.

Thanks and Best Regards,

Suvrat

Hi Trey,

Thank you for sending the files. I got all the files from Pratik today.

We downloaded the new bootloader code to device first so that we could install the new .inf driver file. But when we downloaded the bootloader code to device, we found that the device is not getting detected on PC and we cant see any auto refresh in device manager indicating that some USB device is connected.

Then we downloaded the old bootloader code to device. So the device got detected on PC. We then uninstalled old driver for the detected port and installed new driver provided by you. So the driver got installed on PC.

We then again downloaded the new bootloader code to device, but still the device is not getting detected on PC.

So we havent gone to the next step yet of using dfuprog.

Please help.

Best Regards,

Suvrat

Survat,

Glad to hear you got the file, but sorry to hear you're still having trouble.

I just retested the exact files I sent over to Pratik and they worked on my machine.  Are you using a controlCARD or custom hardware?  If you rebuild the project and load does it work?

Because I can't recreate the issue here, I will need more information in order to be able to help you debug your problem.

BR,

Hi Trey,

We are using our project hardware i.e custom hardware.

Yes we did rebuild of the new bootloader project before downloading to hardware.

After getting the files we were not able to import the project first and were getting some errors. Then I installed some updates, and then was able to import the project, build and download it to hardware. One observation is that once the new bootloader code gets downloaded to hardware it doesnt automatically stop at main but it looks it immediately starts running. We dont need to click the continue button to start the project run.

My current CCS ver is Version: 5.2.1.00018.

The other exact steps are mentioned in the previous post.

Actually we did not try firing the dfuprog utility with old bootloader code (which when downloaded to hardware, it gets detected on PC).

Do you think that trying new dfuprog which you sent yesterday with the old bootloader code and new driver would work?

We were trying with only new files today i.e. new bootloader code and the new windows driver file. We didnt try any old-new combinations.

This is all the information about experiments we did today.

Do you have any suggestions on trying some combinations?

Please let us know.

Best Regards,

Suvrat

Hi Trey,

This is regarding USB CDC bootloader which I am working on parallely.

I have a project where USB CDC is initialized with standard API, and the device gets detected on PC. We are thinking of using handshaking mode where hex file would be sent from hyperteminal and device will receive limited bytes buffer and process it each time. Till the processing is completed on previous buffer, it wont read the new buffer, so no acknoledgement would be sent to USB host and host would wait for sending next buffer.

Till now with initial experiments it looks that the handshaking concept is working.

In an experiment I just wanted to check what time it takes to transfer a file with this connection type to device. While doing this experiment I always read out the buffers each time whenever the USB_EVENT_RX_AVAILABLE event was received. So actually host PC did not have to wait for sending the next buffer and the file tranfer took place like a continuous transmission without any waits. In this experiment I transfered the 132KBytes hex file using hyperteminal's "send text file" option and it took around 8 to 9 minutes to complete the file transmission. (I tried using different baud rates of hyperterminal connection but no use - as expected)

We think that this speed is really slow for USB connection. Is expected to be with this rate. Is there any way or any API's to increse the default baud rate (if any for tLineCoding). If yes please let us know. We want to increase the transfer speed.

Best Regards,

Suvrat

Hi Trey,

Thanks for your reply.

We went a step ahead where we had stuck but sorry to say that now facing problem with opening the new dfuprog utility. I have created document which is attached herewith which describes all the steps we did alongwith screenshots.

Please help.

Best Regards,

Suvrat

Survat,

I think you may have forgotten to attach the document.

BR,

Here is the file.

I used some incorrect option.

Survat,

The DLL error you are seeing is because you do not have the MS Visual Studio Redistributable package installed.  A quick google search for this error would have informed you of this:

https://www.google.com/search?q=program+can%27t+start+because+msvcp110.dll+is+missing&oq=program+can%27t+start+because&aqs=chrome.5.69i57j0l5.6720j0j7&sourceid=chrome&es_sm=93&ie=UTF-8#q=program+can't+start+because+msvcr110.dll+is+missing

The second error you got when you ran the 64 bit version is because your computer is 32 bit.  The application version needs to match the type of machine you have.

The third error that you got when actually programming the device is due to errors in the formatting of your hex file.  Can you try loading bl_app_i.hex from the examples/bl_app/debug directory?  If this file loads it will confirm there are errors in your hex file.

BR,

Trey,

Yes I had to google more for the exact file and copying it to system32 folder.

Looks the error has gone now and the new dfuprog utility is opening now. I dont have hardware right now to connect as I am at home.

Can you please tell me how to ensure that the hex file has the correct format. Like are there any options in CCS to generate the file in the required way only? Because we had generated the hex file using CCS 5.5 only.

Please explain in detail. Monday morning, I will try generating the hex file in the way you suggest to have it in correct format and will try downloading now using the new dfuprog utility.

Best Regards,

Suvrat

Hi Trey,

Today the latest dfuprog provided by you got connected to device with latest bootloader code.

I could enumerate the device, clear the flash.

While downloading the application using dfuprog, first I was getting the error code (-7) DFU_ERR_INVALID_ADDR. But then after doing the adderess change in the linker file I could resolve that error.

After resolving that error, when I tried to download my application file again, I started getting the error code (-12) DFU_ERR_DNLOAD_FAIL.

I get this error not only for my application, but also get the same when I try to download the bl_app.hex which I created by compiling bl_app code (from v135 folder) on my PC. The latest bl_app code provided by you in version folder is giving 2 errors, when I try to compile it on my PC.

Both the errors are: gmake: *** No rule to make target ..... alongwith some invalid path where project files are not present:

/F2806x_CSMPasswords.asm needed by F2806xPasswords.obj

/driverlib.lib needed by bl_app.out

The CCS version on my PC is 5.5 and C2800 compiler tools version is 6.2.6.

With the latest dfuprog I can download the bl_app.hex and bl_app_i.hex file provided by you in version folder, but for any code compiled on PC, I get error code (-12) while downloading.

Please help. We need to provide solution to our customer.

Best Regards,

Suvrat

Survat,

I just extracted the exact same zip file I sent you, put it in C:\ti\controlsuite\device_support\f2806x, built the boot_loader and bl_app programs, loaded the boot_loader, and went through a erase and program cycle successfully.  I'm not sure why you're having so much trouble.  That said, I can still fix the problems you're having in the above post.

I think your application image still isn't in the correct format.  Are you using the same bl_app_hex.cmd file to generate your application hex image?  The file that you load should be about a half a megabyte in size and should contain a full image of the flash.

As far as building the bl_app program goes, I was able to extract a fresh copy of the zip and it built fine.  The errors you're getting are because the files aren't being found.  If you look at the project in the project navigator the files it can't find should have a little yellow exclamation point (!) on them.  You can right click on the file, select properties, and then look at the Resource view in the properties box to find out where CCS expects them to be.  On my computer for instance, driverlib is a linked file using the path: PROJECT_LOC\..\..\MWare\driverlib\Debug\driverlib.lib

This resolves to C:\ti\controlSUITE\device_support\f2806x\version\MWare\driverlib\Debug\driverlib.lib on my computer.  I checked and this file is in fact included in the original zip file I sent over.  You can do the same check for F2806x_CSMPasswords.asm.  

At this point, I'm guessing you are using the original copy of the files that you extracted and imported with CCSv5.2 and then re-imported in CCSv5.5.  Try deleteing the version folder that you have right now and extracting a fresh copy.  Then import the boot_loader and bl_app projects and building.  I think this will fix all the build errors you're having.

BR,

Hi Trey, Thanks for your reply.

For building new bl_app code, I will try the things you have suggested.

For old bl_app code which gets compiled on my PC and generates hex file, I havent modified anything in that project. Still the hex file does not get downloaded to device. Why such thing should happen?

Once the hex file of bl_app project generated hex file gets downloaded well, then we can recheck settings related to our application. But we aren't done with bl_app.hex generated on my machine yet. :(

Today I upgraded my CCS version to 6.0 i.e. latest thinking that, it might help in resolving problems, but no use.

Should I revert it back to 5.5? What CCS version and compiler versions you use?

Can we have a live meeting session on Thursday if things wont work tomorrow?

Regards,

Suvrat

Trey,

One more query to you is, once we get these file download issues resolved, how should we be doing for switching between bootloader mode and application mode at customer site?

Will dfuprog be only sufficient to handle that?

Do we need to write some interface routines in application code for DFU class so that it can switch back to bootloader mode for downloading new application, using dfuprog -m option?

It would be great if you could explain this in detail.

Best Regards,

Suvrat

Survat,

I'm using CCSv5.5, but anything v5.5 or higher should work.  Can you attach the hex file you're trying to load to the next post you make so I can have a look?

Yes, I'm available tomorrow or Thursday for a meeting.  Talk to Pratik and he can setup a meeting for us.

Yes, you can use dfuprog to switch between the bootloader and application run modes with the -m option. Yes, you'll need to add the same USB code that is in the bl_app example.

BR,

Hello Trey,

We waited for you for the Webex call this morning 8am India time (for Thursday-5/29). Pratik was trying to reach you.

Pratik is again scheduling a call today at 6:30pm India time (for Thursday-5/29).

So we will talk in the call regarding download issue today.

Best Regards,

Suvrat

Hi Trey,

The call got disconnected.

Thanks a lot from Honeywell team for giving your precious time.

Please let me know about resolution for -m option and hex file renaming thing. That would really be great help.

Thanks again!

Best Regards,

Suvrat

Trey,

One more thing I forgot to ask is, if the verification is done after the clear flash and download options, by default? Just wanted to know as it doesnt give any acknowledgement of download operation completion.

Please let me know.

Regards,

Suvrat

Survat,

Happy to help out.

Verification is done twice during programming operations.  Once during the actually programming by the Flash API on the device, and again by the PC after the entire application has been downloaded.

Ok. That is nice. :)

Is there any different method to add two kinds of .cmd files to project?

i.e. here in bl_app there are two files.. bl_app_hex.cmd and F28069_bl_app.cmd. Both show different icons in the project explorer window.

Regards,

Suvrat

There are two different types of command files in use here...one for the actual linker and one for the hex2000 utility which generates our hex file.  The one for the hex utility shows up as greyed out because it is being excluded from the normal build process.  We do this because if it isn't, the linker will try to use it as an application linker file and will have an error.

In addition to adding command files directly to the project you can specify them in the project properties, under the linker file search path.

BR,

Survat,

Regarding the -m option:

The memory copy at the beginning of main in the bootloader needs to be moved before the application check.  The applicaiton check contains a call to a delay function located in RAM.  If this is executed before the memcopy then the function won't actually be in RAM and the device will not start executing the application.  Here is an updated copy of the file:

8463.bl_usb.c

I verified that the -m option works after correcting this mistake.  Entering back into the bootloader is a little slow because of a delay loop in the USB library.  Replace the usblib/device/usbdfu-rt.c file with the following file and then recompile USBlib, boot_loader, and bl_app to increase the speed at which the application switches back into DFU mode:

//###########################################################################
//
// FILE:   usbddfu-rt.c
//
// TITLE:  USB Device Firmware Update runtime device class driver.
//
//###########################################################################
// $TI Release: f2806x Support Library v1.15 $
// $Release Date: December 12, 2011 $
//###########################################################################

#include "DSP28x_Project.h"

#include "inc/hw_memmap.h"
#include "inc/hw_types.h"
#include "driverlib/debug.h"
#include "driverlib/usb.h"
#include "driverlib/sysctl.h"
#include "driverlib/systick.h"
#include "driverlib/interrupt.h"
#include "usblib/usblib.h"
#include "usblib/usbdfu.h"
#include "usblib/usb-ids.h"
#include "usblib/device/usbdevice.h"
#include "usblib/device/usbddfu-rt.h"
#include "usblib/usblibpriv.h"

//*****************************************************************************
//
//! \addtogroup dfu_device_class_api
//! @{
//
//*****************************************************************************

extern void * pBootEntry;

//*****************************************************************************
//
// DFU Device Descriptor.  This is a dummy structure since runtime DFU must be
// a part of a composite device and cannot be instantiated on its own.
//
//*****************************************************************************
const unsigned char g_pDFUDeviceDescriptor[] =
{
    18,                         // Size of this structure.
    USB_DTYPE_DEVICE,           // Type of this structure.
    USBShort(0x110),            // USB version 1.1 (if we say 2.0, hosts assume
                                // high-speed - see USB 2.0 spec 9.2.6.6)
    USB_CLASS_VEND_SPECIFIC,    // USB Device Class
    0,                          // USB Device Sub-class
    0,                          // USB Device protocol
    64,                         // Maximum packet size for default pipe.
    USBShort(0),                // Vendor ID (VID).
    USBShort(0),                // Product ID (PID).
    USBShort(0),                // Device Release Number BCD.
    0,                          // Manufacturer string identifier.
    0,                          // Product string indentifier.
    0,                          // Product serial number.
    1                           // Number of configurations.
};

//*****************************************************************************
//
// DFU device runtime configuration descriptor.  This is also a dummy structure
// since the primary device class configuration will be used when DFU is added
// to the composite device.
//
//*****************************************************************************
unsigned char g_pDFUConfigDescriptor[] =
{
    //
    // Configuration descriptor header.
    //
    9,                          // Size of the configuration descriptor.
    USB_DTYPE_CONFIGURATION,    // Type of this descriptor.
    USBShort(27),               // The total size of this full structure.
    1,                          // The number of interfaces in this
                                // configuration.
    1,                          // The unique value for this configuration.
    0,                          // The string identifier that describes this
                                // configuration.
    USB_CONF_ATTR_SELF_PWR,     // Bus Powered, Self Powered, remote wake up.
    250,                        // The maximum power in 2mA increments.
};

//*****************************************************************************
//
// The DFU runtime interface descriptor.
//
//*****************************************************************************
unsigned char g_pDFUInterface[] =
{
    //
    // Interface descriptor for runtime DFU operation.
    //
    9,                          // Length of this descriptor.
    USB_DTYPE_INTERFACE,        // This is an interface descriptor.
    0,                          // Interface number .
    0,                          // Alternate setting number.
    0,                          // Number of endpoints (only endpoint 0 used)
    USB_CLASS_APP_SPECIFIC,     // Application specific interface class
    USB_DFU_SUBCLASS,           // Device Firmware Upgrade subclass
    USB_DFU_RUNTIME_PROTOCOL,   // DFU runtime protocol
    0,                          // No string descriptor for this interface.
};

//*****************************************************************************
//
// The DFU functional descriptor.
//
//*****************************************************************************
unsigned char g_pDFUFunctionalDesc[] =
{
    //
    // Device Firmware Upgrade functional descriptor.
    //
    9,                              // Length of this descriptor.
    USB_DFU_FUNC_DESCRIPTOR_TYPE,   // DFU Functional descriptor type
    (DFU_ATTR_CAN_DOWNLOAD |        // DFU attributes.
     DFU_ATTR_CAN_UPLOAD |
     DFU_ATTR_WILL_DETACH |
     DFU_ATTR_MANIFEST_TOLERANT),
    USBShort(0xFFFF),               // Detach timeout (set to maximum).
    USBShort(DFU_TRANSFER_SIZE),    // Transfer size 1KB.
    USBShort(0x0110)                // DFU Version 1.1
};

//*****************************************************************************
//
// The DFU runtime configuration descriptor is defined as two sections.
// These sections are:
//
// 1.  The 9 byte configuration descriptor.
// 2.  The interface descriptor + DFU functional descriptor.
//
//*****************************************************************************
const tConfigSection g_sDFUConfigSection =
{
	sizeof(g_pDFUConfigDescriptor) & 0xFF,
	(sizeof(g_pDFUConfigDescriptor) & 0xFF00) >> 8,
    g_pDFUConfigDescriptor
};

const tConfigSection g_sDFUInterfaceSection =
{
	sizeof(g_pDFUInterface) & 0xFF,
	(sizeof(g_pDFUInterface) & 0xFF00) >> 8,
    g_pDFUInterface
};

const tConfigSection g_sDFUFunctionalDescSection =
{
	sizeof(g_pDFUFunctionalDesc) & 0xFF,
	(sizeof(g_pDFUFunctionalDesc) & 0xFF00) >> 8,
    g_pDFUFunctionalDesc
};

//*****************************************************************************
//
// This array lists all the sections that must be concatenated to make a
// single, complete DFU runtime configuration descriptor.
//
//*****************************************************************************
const tConfigSection *g_psDFUSections[] =
{
    &g_sDFUConfigSection,
    &g_sDFUInterfaceSection,
    &g_sDFUFunctionalDescSection
};

#define NUM_DFU_SECTIONS (sizeof(g_psDFUSections) /                         \
                          sizeof(tConfigSection *))

//*****************************************************************************
//
// The header for the single configuration we support.  This is the root of
// the data structure that defines all the bits and pieces that are pulled
// together to generate the configuration descriptor.
//
//*****************************************************************************
tConfigHeader g_sDFUConfigHeader =
{
    NUM_DFU_SECTIONS,
    g_psDFUSections
};

//*****************************************************************************
//
// Configuration Descriptor.
//
//*****************************************************************************
const tConfigHeader * const g_pDFUConfigDescriptors[] =
{
    &g_sDFUConfigHeader
};

//*****************************************************************************
//
// Forward references for device handler callbacks
//
//*****************************************************************************
static void HandleGetDescriptor(void *pvInstance, tUSBRequest *pUSBRequest);
static void HandleRequest(void *pvInstance, tUSBRequest *pUSBRequest);
static void HandleDevice(void *pvInstance, unsigned long ulRequest,
                         void *pvRequestData);

//*****************************************************************************
//
// The device information structure for the USB DFU devices.
//
//*****************************************************************************
tDeviceInfo g_sDFUDeviceInfo =
{
    //
    // Device event handler callbacks.
    //
    {
        HandleGetDescriptor,    // GetDescriptor
        HandleRequest,          // RequestHandler
        0,                      // InterfaceChange
        0,                      // ConfigChange
        0,                      // DataReceived
        0,                      // DataSentCallback
        0,                      // ResetHandler
        0,                      // SuspendHandler
        0,                      // ResumeHandler
        0,                      // DisconnectHandler
        0,                      // EndpointHandler
        HandleDevice,           // Device handler.
    },
    0,                          // Device descriptor (unused - composite device)
    g_pDFUConfigDescriptors,
    0,                          // Completed during USBDDFUCompositeInit().
    0,                          // Completed during USBDDFUCompositeInit().
    &g_sUSBDefaultFIFOConfig,
    0
};

//*****************************************************************************
//
// Device instance specific handler.  This callback received notifications of
// events related to handling interface, endpoint and string identifiers when
// a device is part of a composite device.  In this case, the only resource we
// need which may be renumbered is the DFU runtime interface.
//
//*****************************************************************************
static void
HandleDevice(void *pvInstance, unsigned long ulRequest, void *pvRequestData)
{
    tDFUInstance *psInst;
    unsigned char *pucData;

    //
    // Get a pointer to our instance data.
    //
    psInst = ((tUSBDDFUDevice *)pvInstance)->psPrivateDFUData;

    //
    // Get a byte pointer to the data.
    //
    pucData = (unsigned char *)pvRequestData;

    //
    // Which request event have we been passed?
    //
    switch(ulRequest)
    {
        //
        // This was an interface change event.
        //
        case USB_EVENT_COMP_IFACE_CHANGE:
        {
            //
            // Save the change to the interface number.
            //
            psInst->ucInterface = pucData[1];
            break;
        }

        //
        // We are not interested in any other event.
        //
        default:
        {
            break;
        }
    }
}

//*****************************************************************************
//
// This function is called by the USB device stack whenever a request for a
// non-standard descriptor is received.
//
// \param pvInstance is the instance data for this request.
// \param pUSBRequest points to the request received.
//
// This call parses the provided request structure and determines which
// descriptor is being requested.  Assuming the descriptor can be found, it is
// scheduled for transmission via endpoint zero.  If the descriptor cannot be
// found, the endpoint is stalled to indicate an error to the host.
//
//*****************************************************************************
static void
HandleGetDescriptor(void *pvInstance, tUSBRequest *pUSBRequest)
{
    unsigned long ulSize;

    ASSERT(pvInstance != 0);

    //
    // Which type of class descriptor are we being asked for?  We only support
    // 1 type - the DFU functional descriptor.
    //
    if(((readShort(&(pUSBRequest->wValue)) >> 8) == USB_DFU_FUNC_DESCRIPTOR_TYPE) &&
       ((readShort(&(pUSBRequest->wValue)) & 0xFF) == 0))
    {
        //
        // If there is more data to send than the host requested then just
        // send the requested amount of data.
        //
        if((unsigned short)g_pDFUFunctionalDesc[0] > readShort(&(pUSBRequest->wLength)))
        {
            ulSize = (unsigned long)readShort(&(pUSBRequest->wLength));
        }
        else
        {
            ulSize = (unsigned long)g_pDFUFunctionalDesc[0];
        }

        //
        // Send the data via endpoint 0.
        //
        USBDCDSendDataEP0(0, g_pDFUFunctionalDesc, ulSize);
    }
    else
    {
        //
        // This was an unknown or invalid request so stall.
        //
        USBDCDStallEP0(0);
    }
}

//*****************************************************************************
//
// This function is called by the USB device stack whenever a non-standard
// request is received.
//
// \param pvInstance is the instance data for this HID device.
// \param pUSBRequest points to the request received.
//
// This call parses the provided request structure.  Assuming the request is
// understood, it is handled and any required response generated.  If the
// request cannot be handled by this device class, endpoint zero is stalled to
// indicate an error to the host.
//
//*****************************************************************************
static void
HandleRequest(void *pvInstance, tUSBRequest *pUSBRequest)
{
    tDFUInstance *psInst;
    const tUSBDDFUDevice *psDevice;

    ASSERT(pvInstance != 0);

    //
    // Which device are we dealing with?
    //
    psDevice = pvInstance;

    //
    // Get a pointer to our instance data.
    //
    psInst = psDevice->psPrivateDFUData;

    //
    // Make sure the request was for this interface.
    //
    if(readShort(&(pUSBRequest->wIndex)) != psInst->ucInterface)
    {
        return;
    }

    //
    // Determine the type of request.
    //
    switch(pUSBRequest->bRequest)
    {
        //
        // We have been asked to detach.  In this case, we call back to the
        // application telling it to tidy up and re-enter the boot loader.  We
        // rely upon it doing this on our behalf since this must be done from a
        // non-interrupt context and this call is most likely in interrupt
        // context.
        //
        case USBD_DFU_REQUEST_DETACH:
        {
            //
            // Tell the application it's time to reenter the boot loader.
            //
            psDevice->pfnCallback(psDevice->pvCBData, USBD_DFU_EVENT_DETACH,
                                  0, (void *)0);
            break;
        }

        //
        // This request was not recognized so stall.
        //
        default:
        {
            USBDCDStallEP0(0);
            break;
        }
    }
}

//*****************************************************************************
//
//! Initializes DFU device operation for a given USB controller.
//!
//! \param ulIndex is the index of the USB controller which is to be
//! initialized for DFU runtime device operation.
//! \param psDevice points to a structure containing parameters customizing
//! the operation of the DFU device.
//!
//! \return Returns NULL on failure or the \e psDevice pointer on success.
//
//*****************************************************************************
void *
USBDDFUCompositeInit(unsigned long ulIndex, const tUSBDDFUDevice *psDevice)
{
    tDFUInstance *psInst;

    //
    // Check parameter validity.
    //
    ASSERT(ulIndex == 0);
    ASSERT(psDevice);
    ASSERT(psDevice->psPrivateDFUData);

    //
    // Initialize the workspace in the passed instance structure.
    //
    psInst = psDevice->psPrivateDFUData;
    psInst->psDevInfo = &g_sDFUDeviceInfo;
    psInst->ulUSBBase = USB0_BASE;
    psInst->bConnected = false;
    psInst->ucInterface = 0;

    //
    // Tag the device information with our device data structure pointer.
    //
    psInst->psDevInfo->pvInstance = (void *)psDevice;

    //
    // Return the pointer to the instance indicating that everything went well.
    //
    return((void *)psDevice);
}

//*****************************************************************************
//
//! Shuts down the DFU device.
//!
//! \param pvInstance is the pointer to the device instance structure as
//! returned by USBDDFUCompositeInit().
//!
//! This function terminates DFU operation for the instance supplied and
//! removes the device from the USB bus.
//!
//! Following this call, the \e pvInstance instance should not me used in any
//! other calls.
//!
//! \return None.
//
//*****************************************************************************
void
USBDDFUCompositeTerm(void *pvInstance)
{
    tDFUInstance *psInst;

    ASSERT(pvInstance);

    //
    // Get a pointer to our instance data.
    //
    psInst = ((tUSBDDFUDevice *)pvInstance)->psPrivateDFUData;

    //
    // Terminate the requested instance.
    //
    USBDCDTerm(0);

    psInst->ulUSBBase = 0;
    psInst->psDevInfo = (tDeviceInfo *)0;
}

//*****************************************************************************
//
//! Removes the current USB device from the bus and transfers control to the
//! DFU boot loader.
//!
//! This function should be called from the application's main loop (i.e. not
//! in interrupt context) following a callback to the USB DFU callback function
//! notifying the application of a DETACH request from the host.  The function
//! will prepare the system to switch to DFU mode and transfer control to the
//! boot loader in preparation for a firmware upgrade from the host.
//!
//! The application must ensure that it has completed all necessary shutdown
//! activities (saved any required data, etc.) before making this call since
//! the function will not return.
//!
//! \return This function does not return.
//
//*****************************************************************************
void
USBDDFUUpdateBegin(void)
{
    //
    // Terminate the USB device and take us off the bus.
    //
    USBDCDTerm(0);

    //
    // Disable all interrupts.
    //
    IntMasterDisable();

    //
    // We must make sure we turn off SysTick and its interrupt
    // before entering the boot loader!
    //
    SysTickIntDisable();
    SysTickDisable();

    //
    // Disable all processor interrupts.  Instead of disabling them
    // one at a time, a direct write to PIE is done to disable all
    // peripheral interrupts.
    //
    IER = 0;

    //
    // Reset the USB peripheral
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_USB0);
    SysCtlPeripheralReset(SYSCTL_PERIPH_USB0);
    SysCtlPeripheralDisable(SYSCTL_PERIPH_USB0);

    //
    // Wait for about a second.
    //
    SysCtlDelay(SysCtlClockGet() / 20);

    //
    // Re-enable interrupts at the NVIC level.
    //
    IntMasterEnable();

    //
    // Return control to the boot loader.  This is a call to the SVC
    // handler in the boot loader.
    //
    ((void (*)(void))pBootEntry)();

    //
    // Should never get here, but just in case.
    //
    while(1)
    {
    }
}

//*****************************************************************************
//
// Close the Doxygen group.
//! @}
//
//*****************************************************************************

BR,

Hi Trey,

(1) Thanks for sending the files. -m option looks to be working now for bl_app application. For fast switching, I tried to compile the usblib with new file, I got 3 errors - actually 1 error type for 3 instances.

Error is : Too many initializer values...for "g_pDFUConfigDescriptor", "g_pDFUInterface" and "g_pDFUFunctionalDesc".

(2) With the dfuprog utility, is there any limitation on the filesize that can be downloaded?

(3) In our application, we already had the USB CDC class implemented. Today, with the help of bl_app code, I modified my application code to have CDC + DFU combined in the composite device class. After this, I downloaded the code to my device (using CCS directly). When it got downloaded, the port got detected on the PC showing "Virtual CoM Port" for which the driver wasnt found automatically. Then I tried to install it manually with different driver files you have provided till now. But the driver couldnt be installed.

Is this problem as the driver is not available for this (CDC+DFU) composition? If it is the reason, do you have such driver file?

(4) When I downloaded my application file (mentioned in step 3) using dfuprog, and reset the device, it looks as if I did not download any application. After reset the USB port gets gets detected with normal firmware upgrade driver and with dfuprog, it gets enumerated without using option -m. Is it because of the incorrect linker file? Do I need to take care for writing linker? Any suggestions on that?

Please let me know.

Best Regards,

Suvrat

Hi Trey,

Can you please let me know regarding the points posted in the last post.

Regarding point (3),

I have attached the USB code files, where I have created the composite class of DFU+CDC. Would you please look at the same and let me know if it is the correct way of imploementation? I have used the "USB_PID_COMP_SERIAL" for device's PID. Is this PID correct in my case? or do I need to create another #define to have new PID_CDC_DFU?

I am not able to install the driver on my Win7 machine yet for this composite device. I tried to create an .inf file with PID 0x07 and IM 01, like the inf file for HID+DFU, but it wasnt accepted for my device.

Can you please create a inf for me? or if the procedure is really big, can you please send me the procedure?

Regarding point (4),

Can you please suggest what changes are required in my linker file to make it correctly downloadable using dfuprog?

I have attached all the required files herewith. Please let me know.

Best Regards,

Suvrat

Hi Trey,
It would really be great if you could help me in locating issues related to our application linker.

1. I have modified my project, and added the bl_entrytable.asm file. Modified the linker file to make it almost like the liker file of bl_app example code. Added a linker cmd file (and exluded from project) for the hex2000 utility.
2. Even after having all of these changes done, I am still facing the problem of application not running. When I compile the application and download it to my device using the CCS debug option, the application works fine. But when I power cycle the device, the application doesnt run. I am not able to locate yet what I am missing. One observation is when I remove the BEGIN_FLASH (0x3F7FF6) address from my linker file, the application doesnt work. But in the bl_app example I couldnt locate this jump address and wondering how it is working without that.
3. When I compared the hex files generated for the bl_app application and my application, I found that, in bl_app hex file the meaningful data looks to be there from start but for my application hex file, the meaningful data looks to start after a lot of FF's at the start of hex file, even if the start address for code is same.
4. I played a lot with my linker file, but no use yet.

I have attached the zip file, where I have included my application's original and the modified linker file. My application's hex file which contains a lot of FF's at start.

Please help.

BTW just to let you know:
As we had issue with getting the (CDC+DFU windows driver), what we have decided to do is, to send the application to bootloader switch command from the hyperterminal using existing CDC class connection. Once it switches to bootloader mode, we will strat the dfuprog utility to download the new application file.

Best Regards,

Suvrat

Hi Trey,

Please let me know. Waiting for your reply.

Best Regards,

Suvrat

Trey,

Thank you for your reply.

(1) Today when I checked, came to know that this linker is working for one of our product's model, but not for other.

When I debugged the bootloader code, I came to know that the CRC check is failing in the 3rd iteration check (for the non working model's code dumped in device). The number of records are 6. The CRC does not match in the following if condition:

if (ulTemp != pCRCRecord->crc_value)

Why the CRC can fail, and how can I correct it? Please let me know.

P.S.: The code for this non-working model is not working (after linker changes) even if the code is downloaded directly through CCS and the unit is power cycled.

(2) I have one more query: As we will be switching to bootloader mode from application, on getting a request from hyperterminal using CDC class,

We will be calling the ((void (*)(void))pBootEntry)();

Do we need to write forcefully the flash location of pAppEntry to be 0 or 0xffffffff?

Other than this, is/are there any care/s that we will need to take?

Please suggest.

Best Regards,

Suvrat