Forums

Hi Vishwanatha,

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

Trey

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

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
    }
}

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

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

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

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