boot_demo_usb project does not show up in uniflash

I also just tried the LMFlash program, configured for USB DFU, and no devices are showing up there either.

Hello Dave,

When you download the SW-USB-win-xxxx.msi, you must see the dfuprog tool in the following directory (if you use the default installation)

C:\Program Files (x86)\Texas Instruments\Tiva\usb_examples

Regards
Amit

Thanks, Amit. I guess I had not installed the SW-USB item before. The composite device is showing up now using dfuprog. But why does it not show up using the other flash loader programs? Will they only see a pure DFU device and not a composite one?

Also, I need to create a flash-based DFU bootloader. Is there already an example anywhere of that? None of the examples I have seen so far have that particular implementation. I know I can create one myself by hacking up one of the other examples, but if there is already one configured that way it would make life easier.

Thanks,

Dave

Hello Dave,

Look at the code from TM4C123

C:\ti\TivaWare_C_Series-2.1.0.12573\examples\boards\dk-tm4c123g\boot_usb

This uses a flash based boot loader for TM4C123 but the same can be applied to TM4C129, by changing the defines in bl_config.h and the device define of TARGET_IS_TM4C129_RA2

Regards
Amit

Thanks, Amit. I will check that out.

Regards,

Dave

Hello Dave,

Do make sure that you have TovaWare 2.1.1.71. The 2.1.0 does not have the master files updated for TM4C129x

Regards
Amit

Hi, Amit,

Now that I finally got that USB library update issue resolved, I am back to trying to get a flash-based USB bootloader working. As you suggested, I found the boot_usb project in the TM4C123G example code, and changed the processor type in the General Options > Target  to TM4C129XNCZAD. I also changed the defined symbols in C/C++ Compiler > Preprocessor to:

ewarm

PART_TM4C129XNCZAD

TARGET_IS_TM4C129_RA2

I did not see anything in the bl_config.h file that looked specific to the 123 chip, so I did not make any changes there. [UPDATE: I took a second look and updated the CRYSTAL_FREQ to 25000000, but that did not make a difference.]

The project built without any problems, but when I tried to run the program I had a couple of issues crop up.

First, when loading the program using the debugger I got a message saying “The stack plug-in failed to set a breakpoint on “main”. The Stack window will not be able to display stack contents.” After clicking OK, the program finished loading, but stopped inside HandleRequestDnloadSync() instead of main(). The code still seems to run, so I am not sure if that is a problem or not.

Second, however, is more disconcerting. When I run the program and plug in a USB cable, I get an “Unknown USB Device” error from Windows. I did check the project’s include file options, and they are pointing to the right folder!  :-)

Is there something else I need to modify to get this example code working on my TMC129X board?

Thanks,

Dave

Hello Dave,

To confirm, you are using 2.1.1.71. Also please attach the project zipped on the forum.

Regards
Amit

Hi, Amit,

Yes, I am using 2.1.1.71. Attached is the zipped project.

Thanks,

Dave

boot_usb.zip

Hello Dave,

I checked it against my copy of the TM4C129 version and I see the following difference in the bl_config.h

The Flash page Size for TM4C129 needs to be updated and so does the APP and VTABLE size location/

#define APP_START_ADDRESS 0x4000
#define VTABLE_START_ADDRESS 0x4000
#define FLASH_PAGE_SIZE 0x00004000

Regards
Amit

Hi, Amit,

I made the changes you noted, but the program still does not work. I found out that it is entering the FaultISR function in bl_startup_ewarm.S.

It sounds like you already have a TM4C129 version of the bootloader. Can you just post a zip file with that project so that I can try it out?

Thanks,

Dave

Hello Dave

Here you go (mine is CCS in 2.1.1.712084.boot_usb.zip)

Regards

Amit

Hi, Amit,

Thanks. I don't have CCS, though, so that is not going to help me. However I did do a diff between your bl_config.h and mine, and they are identical.

I re-checked all of the project options, and there does not appear to be anything chip-specific that I have overlooked. I did change the target processor references in both the General Options > Target and C/C++ Compiler > Preprocessor tabs to specify the 129 chip.

The .icf file is in the bootloader folder -- as is the bl_startup_ewarm.S file -- so presumably those do not need to be customized for a particular processor.

I looked in the example code folder and found that the makefile had references to the 123 chip. So I changed the makefile to use

PART=TM4C129XNCZAD

CFLAGSgcc=-TARGET_IS_TM4C129_RA2

But after rebuilding, the code still does not work. It hits the same FaultISR as before. [EDIT: After thinking about it, this makefile is probably only used for building gcc projects, and so has no effect on my IAR build.]

So I am at a total loss as to why the example code does not run. Is there any chance you could try loading it to see if it runs on your system? I have attached a zip file that contains the project with the latest changes to bl_config.h and the makefile.

Thanks,

Dave

5123.boot_usb.zip

Just in case there was some hidden reference to the TM4C123 part in the example project, I created a whole new workspace and project from scratch. It has the same problems as the original.

Hello Dave,

I got the IAR license finally and I am able to reproduce the issue on my DK-TM4C129X. Interestingly the CCS version works fine. When I stepped debugged the code in IAR it shows that the USB got a GET_DESCRIPTOR request from the Host but it did not respond to the same at all, causing Host to give up. In fact it went to the disconnect process in the USB0DeviceIntHandler.

Can you check with the IAR team while I debug on my side as well.

Regards
Amit

Hi, Amit,

I am glad to hear that you were able to reproduce the problem. I was afraid my problems were due to something I was doing wrong (again!).

Have you tried setting a breakpoint at the FaultISR function in bl_startup_ewarm.S? That is where the code always ends up when I run it. It does not seem to prevent the processor from responding to other interrupts, but it may explain why things are not working properly.

Regards,

Dave

Hello Dave

No, when I break the execution it is looping in SRAM but no Fault bits in the FAULSTAT are set

Regards
Amit

Hi, Amit,

Something really weird is going on with my system. When I first download, or when I click on the Reset button, I get an error: "The stack plug-in failed to set a breakpoint on "main". (I guess this is because there is no main() function in the bootloader.) Then the program halts at line 707 of bl_usb.c (line 30 of the code snippet below), which is inside the HandleRequests() function:

void
HandleRequests(tUSBRequest *psUSBRequest)
{
    //
    // This request is used by the host to determine whether the connected
    // device supports the TIVA protocol extensions to DFU (our
    // DFU_CMD_xxxx command headers passed alongside DNLOAD requests).  We
    // check the parameters and, if they are as expected, we respond with
    // a 4 byte structure providing a marker and the protocol version
    // number.
    //
    if(psUSBRequest->bRequest == USBD_DFU_REQUEST_TIVA)
    {
        //
        // Check that the request parameters are all as expected.  We are
        // using the wValue value merely as a way of making it less likely
        // that we respond to another vendor's device-specific request.
        //
        if((psUSBRequest->wLength == sizeof(tDFUQueryTIVAProtocol)) &&
           (psUSBRequest->wValue == REQUEST_TIVA_VALUE))
        {
            //
            // Acknowledge the original request.
            //
            USBDevEndpoint0DataAck(false);

            //
            // Send the status structure back to the host.
            //
            USBBLSendDataEP0((uint8_t *)&g_sDFUProtocol,
                             sizeof(tDFUQueryTIVAProtocol));
        }
        else

If I do a single-step, the code starts to run but does not break. If I manually break, the Disassembly window shows it stopped at some place in RAM (a DC32 instruction). However, if I set a breakpoint in the FaultISR, it breaks as soon as I do the single step. But AFSR, CFSR and HFSR are all 0, so I have no clue what fault might have occurred.

But it sounds like you are not having these issues, and are able to single-step through the code. I wonder what the difference is between your setup and mine?

Regards,

Dave

Hello Dave,

I was able to single step when the USB0DeviceIntHandler was put up as a break point. Now that you mentioned it, I did the same steps as you mentioned and it is not working for me in the same manner.

Need to check back if the same is true for TM4C123 project as well. This will help isolate the issue. Should be able to do on Monday.

Regards
Amit

Hi, Amit,

I got pulled into another project this week, so I haven't been able to work on this lately. Did you find out anything useful when you tried running the TM4C123 project?

Thanks,

Dave

Any news?

Hello Dave,

Could not take out time as got pulled into a lot of development and debugs. I am not sure if I can give a full day bandwidth to the issue debug at this point. Will try to get some info at the earliest.

Regards
Amit

OK. Thanks for the update, Amit.

Regards,

Dave