This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

F28069 - USB Bootloader - problem resetting the device

Other Parts Discussed in Thread: CONTROLSUITE

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

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


  • 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

  • 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

  • Hi there,
    I know that this post has been answered and it was back a few years ago. But I was wondering if the issue discussed in this post has been addressed in the latest version of USB Bootloader code? I still not get the reset option to work on my Piccolo ISO controlCard. Other than that, it works all fine, including enumeration, -m, erase (-c) and -f to load image. But I'd like to reset and start app automatically after bbootloading. Any suggestions for troubleshooting? Here is what I used to reset device:
    dfuprog -r -f myapp.hex
  • Hi Shef,

    The practice I have seen in this forum is, any new question is asked in a separate thread. I think, only then you'll get an answer.

    I have v135 for device F28069 and see that this is NOT yet fixed.

    Vishwanatha

  • Hi guys,

    We will be deprecating this tool and replacing it with a new bootloader and usb_flash_kernel in the future. This new tool will work with a usb_flash_programmer. We currently have this solution for F2837x and we will be working to port it to F2806x.

    sal
  • Hi Sal,
    Thanks for the info. Do you know why the existing USB Bootloader will be deprecated? I thought that it is great. In fact I've got it working by following the info posted earlier. By the way, for some reason, some earlier posts have been deleted, including my own on this thread.

    The existing USB bootloader uses a popular USB class DFU (Device Firmware Upgrade). It's well documented and easily ported to other platform e.g. Linux. What about the new tool? Please share more info on it. Thanks!
  • We currently have a DFU solution for F2837xD. F2837xD has a usb bootloader in ROM and we wrote some usb flash kernels to be used with the bootloader as a flash programmer.

    Porting this solution to F2806x and deprecating the existing bl_app means there is less to support. These two tools are essentially redundant.

    sal
  • Hi Sal,

    Thanks for your info on TI's move to use usb_flash_kernel. We recently changed PCB design and started to use 28377D so I'm trying to get usb_flash_kernel working using the latest controlSuite v160. I've built usb_flash_kernel project and loaded into MCU via CCS. After connecting the micro USB port to my PC<, I can see the new device shown as "TI Device Firmware Upgrade" in device manager. However when I run "usb_flash_programmer.exe -l", it returns with error 0x0103 "Couldn't open the USB device". I've tried all other usb examples in controlSuite, and they are all working fine (including mouse, keyboard, serial etc). So presumably my hardware setup is ok. Do you have any advice on troubleshooting?

    I have some other questions regarding USB bootloader in ROM, but will ask later. THanks!
  • Are you running the kernel when you try to list the devices? The C28x needs to be running when the Host PC (usb_flash_programmer.exe) is trying to connect to it.

    What operating system are you using?

    sal
  • HI Sal,
    Thanks for the reply. Yes I was running the usb flash kernel from CCS debugger when I connected the USB. I can see that the PC recognize it as "TI Device Firmware Upgrade" in the windows device manager. Previously with Piccolo I'd use dfuprog.exe to list connected USB devices, and it always worked well (with USB bootloader). But now, I tried both usb_flash_programmer.exe and dfuprog.exe, none works. My host PC is Windows 7, and I just used the executable in controlSuite v160. I tried to rebuilt USB_Loader_WinUSB project with VS2010, but it complained that it could not find winusb.h. Should I have to rebuilt it on host pc or what else did I miss here? I read in TRM Boot ROM chapter. It says that we need to write 0x0C5A to the boot mode select address (0xD00) with the debugger. I did that too (by setting values in CCS Memory Browser). But it did not help either. All other USB examples work fine, so I assume that my board and USB connection are good. I'm stuck man please help! Thanks!
  • If you are running the usb flash kernel then there is no need to write to xD00 for USB boot mode since you have bypassed the bootloader and booted to the usb flash kernel.

    Writing 0x0C5A to oxD00 and reseting the device will cause it to boot to the USB boot loader in ROM. This is used to then load the usb flash kernel into RAM. The usb flash kernel is then used to load your application and program it into Flash.

    You can download the WinDK to get the Windows USB driver Kit and winusb.h or you can use libusb.h as well. There are to build configurations, one for each of these.

    Also, you need to uninstall the TI Device Firmware Upgrade driver and install the F28x&x USB Boot Loader driver in the usb_flash_programmer\windows_driver folder. 1st uninstall the driver. 2nd disconnect the device from the PC. 3rd connect the device and install the new driver.

    Hope this helps.

    sal
  • Hi Sal,

    Thanks for bearing with me! I tried the 3-steps that you suggested, ie. uninstall driver (from Device Manager), unplug and plug again. Once I plugged the USB to my laptop again, it showed a pop-up message saying that it found a new device called "USB Boot Loader", and looking for driver. Then it "found" the driver happily, and shows "TI Device Firmware Upgrade" in Device Manager, same as what I had earlier.  Interestingly, if I clicked on the "Safely Remove Hardware..." in notification area, it shows "Eject TMS32028377D USB Boot Loader", which is different from what is shown in device manager ("TI Device Firmware Upgrade"). When I right-clicked on it and selected "Update Device Driver Software", and browsed to the controlSuite/~Utilities/USB_Flash_programmer/Windows_Driver", it simply said that "The best driver software is already installed, windows has determined the driver for your device is up to date". WHen I tried "usb_flash_programming.exe -l" again, still no connection. I tried both controlCards, all the same. I also tried the usb_dev_serial, example again, it still works fine. Did I do anything wrong here? 

    I also tried to load the provided F28377D_usb_flash_kernel_cpu01.out file from controlSuite, but still got the same thing. What else can I try now?

    Thanks!

  • That is the incorrect driver. Try uninstalling and reinstalling the correct driver. You need to install the driver in that \windows_driver folder.

    It must say "F28x7x USB Boot Loader" in the device manager. I think the "TMS320F2837xD USB Boot Loader" is incorrect and is the string descriptor.

    sal
  • Hi Sal,

    After I first power on, loaded "F2837xD_usb_flash_kernels_cpu01" project, and ran debugger, the host PC shows "USB Device not recognized"m as shown below. Then I went to Device Manager, found "Unknown Device" under "USB controller" (note: not as "TMS320F28x7x USB Boot Loader" under "Other devices", as suggested in driver.txt file in Windows_driver folder. When I tried to update driver and browsed to the Windows driver folder which contains "F28x7x_USB_Boot_Loader.inf", it simply returned with "The best driver software for your device is already installed", and still shows as "Unknown device".  I tried several times, but always the same.

    Now, if loaded "usb_device_serial.out", which works fine, and then load "F2837xD_usb_flash_kernels_cpu01.out" again, the PC will recognize it s "TI Device Firmware Upgrade", and also show "Eject TMS32028377D USB Boot Loader" in notification area. It's apparently the "Product String" from project since I can change it to show different string. What next step can I try? I'm looking up for help in desperate!

  • Hi Sal,

    I was wondering if you are still looking at this issue. Does it happen on your setup or someone else? If it is working fine on your side, can you send me the exact files that you use in a zip file, so that I can try the same thing as you do. I'm using a F2837x controCard R1.1, and controlSuite v160.  Also, shall I open a new thread for this issue, since this is not related to Piccolo anymore? Thanks!

  • Hi Sal,

    I was wondering if you are still looking at this issue. Does it happen on your setup or someone else? If it is working fine on your side, can you send me the exact files that you use in a zip file, so that I can try the same thing as you do. I'm using a F2837x controCard R1.1, and controlSuite v160. Also, shall I open a new thread for this issue, since this is not related to Piccolo anymore? Thanks!
  • Shef,

    I was able to resolve this like I had mentioned above. This is a Windows driver issue.

    I would suggest two thing. 1) look around the internet for a solution regarding installing the correct driver. 2) if you still cannot get it to work, please open a new thread. I will close this one since you moved to F2837x.

    sal