F28069 - USB Bootloader - problem resetting the device

Hello,
I am using F28069 controller to test the USB bootloading using dfuprog.
I got the bootloader code from controlSUITE.
Right now, I am able to:
    - erase the Flash
    - upload the application image
    - download the image
After downloading, I want to reset the system and start execution of the new app image that was downloaded.
Only I am not successful in this.
I saw in F2806xU-USB-BL-UG.pdf that by sending the Reset command, the bootloader should transfer the control
to application after reset. Excerpt from this document:
"DFU_CMD_RESET: This command may be sent to the USB boot loader to cause it to perform a soft reset of the board.
This will reboot the system and, assuming that the main application image is present, run the main application.
Note that a reboot will also take place if a firmware download operation completes and the host issues
a USB reset to the DFU device."

In the dfuprog trace, I get this after Reset command has been sent:
"Error 183 from Endpoint0Transfer"
Before sending Reset command, dfuprog ensures that the target is in IDLE state; I checked that the target is
indeed in IDLE state.

Please advise me how to proceed,

Thank you,

Vishwanatha

  • Hi Vishwanatha,

    Could it be that the device is resetting successfully and therefore is unable to respond on Endpoint 0? 

    Trey

  • In reply to Trey German:

    Hi Trey,

    I thought the same. But the BL-UG.pdf says that the main application is executed after the reset.

    my concern is that this is not happening.

    Vishwanatha

  • In reply to Vishwanatha Manevarthe:

    Hi Trey,

    I observed something strange.

    as mentioned in my first post, though I am getting Endpoint error, the device is NOT resetting.

    I can tell this confidently because, if I send enumeration command from dfuprog again, I get the following details:

    D:\workspace\vc++\dfuprog\Debug>dfuprog.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: Supported
    Target:         revision A0
    Attributes:
       Will Detach:       No
       Manifest Tolerant: Yes
       Upload Capable:    Yes
       Download Capable:  Yes

    Found 1 device.

    I also did one more experiment to confirm this.

    In the bootloader firmware, there is a code snippet that is responsible for resetting the device after getting command from dfuprog.

    It writes an invalid pattern in WDCHK bits of Watchdog Control register (WDCR). And there is a while(1) loop just after that with comment that says that the loop should not be entered if the device is reset.

    I introduced a flag and set the flag before and inside the loop. After sending the reset command from dfuprog, I stopped CCS and checked the flag value - it is written with value that is inside the loop!!

    (I have added the code snippet here for clarity)

    //
    // Are we being asked to perform a system reset?
    //
    if(HWREGBITR(&g_ulCommandFlags, CMD_FLAG_RESET))
    {
        //
        // Time to go bye-bye...  This will cause the microcontroller
        // to reset; no further code will be executed.
        //

        // Enable watchdog reset
        SysCtrlRegs.SCSR &= ~0x02;
        // Enable the Watchdog
        SysCtrlRegs.WDCR |= 0x68;
        // Force a reset
        SysCtrlRegs.WDCR |= 0x40;
        
        g_MYResetFlag = 0x0A0A; //my code
        //
        // The microcontroller should have reset, so this should never be
        // reached.  Just in case, loop forever.
        //
        while(1)
        {
            g_MYResetFlag = 0x55AA; //my code
        }
    }


  • In reply to Vishwanatha Manevarthe:

    Sorry about the trouble, I think I've found the issue.  The code that enables the watchdog is actually disabling it.  Try replacing this:

        // Enable watchdog reset
        SysCtrlRegs.SCSR &= ~0x02;
        // Enable the Watchdog
        SysCtrlRegs.WDCR |= 0x68;
        // Force a reset
        SysCtrlRegs.WDCR |= 0x40;

    with this:

        EALLOW;
        // Enable the Watchdog
        SysCtrlRegs.WDCR = 0x28;
        // Force a reset
        SysCtrlRegs.WDCR = 0x00;

    Trey

  • In reply to Trey German:

    Hi Trey,
    First, thank you for the code snippet. However, the problem is not in enabling/disabling watchdog.
    It is EALLOW. the code that I have doesn't have it and since Watchdog registers are protected, nothing was happening.
    After I added EALLOW-EDIS, it started working. i.e., after the reset command, it changed to application image and started the execution.

    Now I have two more questions (based on my further experiments):
    Question 1:
    following steps are helpful in explaining the question:-
    CASE 0:
    1. connect the target using CCS(v4)
    2. run bl_app
    3. command it to jump to bootloader
    4. command target reset
    In this case, target is reset and application starts execution

    CASE 1:
    1. connect the target using CCS(v4)
    2. run bl_app
    3. command it to jump to bootloader
    4. upload existing image into a file
    5. disconnect
    6. change the code to make it visibly different from the uploaded image
    7. follow steps 1 - 3 of CASE 0
    8. erase flash sectors (for the test purpose, I have hard-coded sector G and F, where my code resides)
    9. download the stored image
    10. command reset
    In this case, target doesn't reset!!
    I noticed that pAppEntry is also erased; but after downloading the image, it is not updated. I am not sure why is this behavior.

    Question 2:
    While running an application, if I disconnect CCS, it continues to execute. If I reset the target by power cycle, it is supposed
    to start execution. My custom application starts as soon as the board is powered on; but the USB bootloader application I got from
    controlSUITE doesn't (both are run on the same custome-board).
    To examine this further, I loaded the bootloader code and started stepping. There is a point where it checks the validity of the application image.
    If I step into the code, it works i.e., the existing image starts execution. But the same doesn't happen if I directly execute (i.e., press F8)
    (I even checked the Flash for valid pAppEntry and found that it is valid)

    Could you point out where am I going wrong?

    Thank you,
    Vishwanatha


  • In reply to Vishwanatha Manevarthe:

    Answer 1:

    I'm not sure exactly what is going on in this case.  I would recommend you check in the file you upload that pAppEntry is there.  Then when you go to reprogram the flash, step through the programmation (or add a statement you can break on when it is programming pAppEntry) so that you can see why this isn't programmed.  If pAppEntry isn't programmed correctly, the bootloader will not start up the application.

    Answer 2:

    That is strange that the code is behaving differently whether you step or run.  If you run the code, at what point in the application check does it fail?

    Regards,

    Trey

  • In reply to Trey German:

    Hi Trey,

    I have found the reason for both questions. There is a code part in bootloader code that checks whether the application image is valid. In this part, it also checks whether there is any application update forced via GPIO. Since I am using a custom board, this GPIO check is invalid and the software was caught in the bootloader.

    After I commented that part (ENABLE_UPDATE_CHECK), it started working. Now I can download/upload/erase whenever I like :-)

    It also starts as soon as the board is powered up.

    Thank you,

    Vishwanatha

  • In reply to Vishwanatha Manevarthe:

    Glad to hear you were able to get it working.  I know that bootloader is complicated and getting everything you want working is difficult, but this was the easiest way to implement all the functionality I wanted to include in the bootloader.

    Best of luck with your design,

    Trey German