• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Subscribers 30 subscribers
  • Views 6236 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C1294NCPDT: USB-Stick-Update Issue

Nishit
Intellectual 755 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: EK-TM4C1294XL

Hello. I'm new to the TM4C1294xl Launchpad and i'm trying to use the example codes. I'm currently stuck at the usb_stick_update example. I have changed the code in to work as per my needs. My code continuously checks for a switch press if that press is detected it jumps to the Updatermain() function and from there jumps to the ConfigureUSBInterface() function and then to the UpdaterUSB(). Till here the code works fine and then it constantly checks for any usb stick to get plugged. 

My question is am i following the right steps which are as follows.

First i'm copying a binary file inside my pen drive with proper name that is defined in the code.

Secondly i'm downloading the modified usb_stick_update code inside the Launchpad which runs properly upto the UpdaterUSB() function.

I'm powering the Launchpad with an external supply. Also the jumpers are at the OTG port.

Then when the code is inside the UpdaterUSB() function i plug my OTG PENDRIVE into the "Target USB" port of the TIVA-C

I don't get response of any usb_stick detected and the program is just continuously checking for a usb device.

Am i using the wrong usb device or are there any logical errors in the ports and the jumpers connections?

Any help will be appreciated.

Thank you! 

  • 0
    TI__Guru*** 128085 points
    Hello Nishit,

    You said you modified the code to per your needs. Aside from perhaps changing the name of the .bin file you are going to use, did you make other mods?

    If so, can you test with the original example to make sure that works? This would rule out the USB stick being an issue.

    Also you mention powering the LaunchPad with external supply - what do you mean by this? Do you mean you connect the debug port to your PC so you can debug/step through code, or is there some other power source being used and if so how are you verifying the code is inside the UpdaterUSB() function?
  • 0 in reply to Ralph Jacobi
    Intellectual 755 points
    Hello Ralph,
    I'm powering the board using external supply on the supply pins and checking the execution flow of the program via LED indication.
    Demo code was checking for 3 methods of going into the bootloader mode. I just used the switch press mode and with the help of the on board LED's i can very well see the execution flow.
    It reaches the UpdaterUSB() function properly and continuously polls for the USB.
    My question is i'm changing the onboard jumper to OTG and then connecting my OTG pendrive on the "Target USB" port. Is this method correct?
  • 0 in reply to Nishit
    TI__Guru*** 128085 points
    Hello Nishit,

    The jumper for OTG is for board power supply, so I have my doubts that is the right selection though if you are getting lit up LED's that seems to indicate at least some code is running?

    You said you are supplying external power using supply pins, what pins do you mean? BoosterPack pins? If so, you need to use the BoosterPack selection for power select. Perhaps you can provide more detail on this power setup so I can try and replicate.

    That you connect the OTG pendrive to the Target USB port is correct for reading USB data.

    Again I'd also like to verify if you tested the USB stick with the TI default example powering through USB/ICDI as normal to make sure as a baseline the USB stick is being recognized and is properly loading the program to your LaunchPad.
  • 0 in reply to Ralph Jacobi
    Intellectual 755 points

    Hello,

    I tried the default usb_host_msc example code which detects the USB and communicates via a serial terminal. It worked fine. The controller was able to detect the USB stick on the Target_usb port.

    Now when i downloaded the usb_stick_update code it doesn't detect the USB.

    I cannot paste the whole code as the example code is pretty big. I'm posting the updates that i made in the code.

    int condition = 0;
    while (condition == 0) // This will continuosly checks for the Switch1 press
    {
    if(ROM_GPIOPinRead(GPIO_PORTJ_BASE, GPIO_PIN_0) == 0)
    {
    UpdaterMain();
    condition = 1;
    }
    }
    //
    // If we get to here that means that none of the conditions that should
    // cause an update are true. Therefore, call the application.
    //
    CallApplication(APP_START_ADDRESS);

    This is the only change i made. After the switch press the UpdaterMain() is called and in that ConfigureUSBInterface() gets called and finally the UpdaterUSB().

    void
    UpdaterUSB(void)
    {
    //
    // Loop forever, running the USB host driver.
    //
    while(1)
    {
    USBHCDMain();

    //
    // Check for a state change from the USB driver.
    //
    switch(g_eState)
    {
    // Rest of the Example code
    }
    It just doesn't detect the state change required to go inside the switch.

    There is no problem of any connection mistakes or fault in the USB or the OTG cable because the USB_host_msc example works perfectly.

    Please help... Thank you.

  • 0 in reply to Nishit
    TI__Guru*** 128085 points
    Hello Nishit,

    I tested adding that condition while loop to the button press evaluation of the usb_stick_update example and had no issues.

    Steps I took for this demo are:

    1) Compile usb_stick_demo
    2) Take the .bin from the example (usb_stick_demo.bin) and rename it based on what usb_stick_update expects (default is FIRMWARE.bin)
    3) Load FIRMWARE.bin onto USB flash drive
    4) Flash EK-TM4C1294XL LaunchPad with example code for usb_stick_update (I did this with the condition check on the button)
    5) Pull up UART terminal and power cycle the LaunchPad
    6) Plug in USB Flash drive to Target USB port
    7) Follow prompt to press SW1 button, new firmware loaded without issue for me
  • 0 in reply to Ralph Jacobi
    Guru 117850 points

    *** LIKE ***

    Absolutely "crystal clear" - your listing of CLEAR, STEPS in SEQUENCE - best insures poster (and follow-on reader) success.

    A "paragraph-based" narrative - while sometimes helpful - cannot compete w/the precision of your sequential listing - well done!

    BTW - poster's issue description is quite good - yet his, "Subject Line: TM4C: TM4C" is abysmal - provides NO/ZERO incentive for (anyone) to open.     Should he not be so advised (by officialdom)?    (yet another horror introduced by the recent (UNWANTED) claimed "forum upgrade."    (NOT!)

  • 0 in reply to Ralph Jacobi
    Intellectual 755 points
    Hello Ralph,

    I started a fresh code. What's my aim is that i should be able to load blinky.bin file via the USB_stick_update code that i'm executing.
    I started a fresh project and followed the steps that you mentioned.

    Now when i placed breakpoints and did some step overs i found that the execution goes into the else section in the switch which means that the ReadAppAndProgram() routine is executed without any errors.

    In the else section there is a software reset statement. So my question is how can i call my uploaded code ie blinky which is now loaded from this point? Is what i'm trying to do feasible/achievable or do i need to make changes in the addresses ?

    Best Regards,

    Nishit.
  • 0 in reply to cb1_mobile
    Intellectual 755 points
    Sorry for that cb1_mobile. This was my first post on this forum. I'll take these things into considerations henceforth.
  • 0 in reply to Nishit
    Guru 117850 points

    My friend - no "sorrow" is required.    You've described your issue rather well - yet do recognize that the Subject line you've produced - completely FAILS to interest others - it makes "no effort" to SELL your post!    (such Sales attracts those most qualified, or most interested - and/or those who have recently encountered your (exact) issue. ... i.e. those you "most want" to read & react to your post!)

    That "Subject Line" IS editable - you may change it to: "USB-Stick-Update Issue" - which far better conveys your thread's topic...

    [edit] 07:40 CST - And now you've "done just that" - this post becomes far more visible - and interesting - to others - good job!

  • 0 in reply to Nishit
    TI__Guru*** 128085 points

    Hello Nishit,

    I don't think Blinky by default is going to do what you want it to do.

    Few things to keep in mind here:

    1) The usb_stick_demo example is where the SWR1 button push originates, per comments of the example:

    //! This program simply displays a message on the screen and prompts the user
    //! to press the USR_SW1 button. Once the button is pressed, control is passed
    //! back to the usb_stick_update program which is still is flash, and it will
    //! attempt to load another program from the memory stick. This shows how
    //! a user application can force a new firmware update from the memory stick.

    2) For the usb_stick_update to be used, you must meet the requirement that I have bolded out:

    //! When this application is attempting to perform an update, it will wait
    //! forever for a USB memory stick to be plugged in. Once a USB memory stick
    //! is found, it will search the root directory for a specific file name, which
    //! is \e FIRMWARE.BIN by default. This file must be a binary image of the
    //! program you want to load (the .bin file), linked to run from the correct
    //! address, at \b APP_START_ADDRESS.

    Regarding point 2, this requirement modifying the .cmd file for the blinky example (blinky_ccs.cmd).

    You need to replace

    #define APP_BASE 0x00000000

    with

    #define APP_BASE 0x00008000

    Further more, you need to make sure to either rename blinky.bin to FIRMWARE.bin, or update the USB_UPDATE_FILENAME as follows:

    #define USB_UPDATE_FILENAME "BLINKY  BIN"

    Making these changes, I can get the blinky example to flash, but it isn't based on button push as that comes from the usb_stick_demo example.

  • 0 in reply to Ralph Jacobi
    Intellectual 755 points

    Hello Ralph,

    I was reading about this problem in other posts and came across this part. Thanks for your detailed explanation also.

    I did the same thing. I changed the blinky_ccs.cmd and in that i changed the APP_BASE to 0x00008000. Then i built the project and took the bin file, pasted it onto the usb stick with the proper changes in the name and executed the code.

    I also checked in the debug window the contents of the bin file at those flash locations in my TIVA-C.

    Now i made a small change instead of making a software reset i called the CallApplication() function instead. I'm assuming that now the execution will start from the 0x00008000 and the Blinky will get executed.

    But it shows an error that no source code preset at 0x86b6. This error also came at memory location 0x96b6 when i kept my APP_BASE to 0x00009000. I'm not trying to relate what is the issue here. There is proper code present at the location which i verified using the bin file and the memory section in the debug. Also before the Error the PC points to that address that means that the CallApplication() function is getting executed up to that point. 

    Also on the Launcpad the LED gets On and then the execution stops due to the error "No source code found" and it's kept ON. 

    Best regards, 

    Nishit.

  • 0 in reply to Nishit
    TI__Guru*** 128085 points

    Hello Nishit,

    Nishit said:

    Now i made a small change instead of making a software reset i called the CallApplication() function instead.

    I think you are jumping ahead a bit too much. First lets get this working in general for you before you make any modifications. Once we confirm you can upload blinky project with usb_stick_update without modifications, then we can look into enabling the functionality you desire. Please let's take this one step at a time, otherwise we have too many possible issues for problem source for me to be able to constructively debug on our examples and guide you.

    Can you try the following:

    1) Use usb_stick_update as per TivaWare, changing nothing but 

    #define USB_UPDATE_FILENAME "BLINKY  BIN"

    2) Use blinky project with changes I highlighted above to re-make a new .bin file for your USB stick which has app base at 0x00008000.

    3) Validate this project when run without breakpoints, will load blinky project?

    • NOTE: If debugging, you must let the code reach the ResetISR and then resume from there to get blinky to load. If you disconnect from debugger, then every time the Reset button is pressed, the blinky project will re-load (you can see this by holding down reset to observe the blinking stops)

  • 0 in reply to Ralph Jacobi
    Guru 117850 points

    Ralph Jacobi said:
    ...you are jumping ahead a bit too much.    First lets get this working in general for you before you make any modifications.     Once we confirm you can upload blinky project with usb_stick_update without modifications, then we can look into enabling the functionality you desire.     Please let's take this one step at a time, otherwise we have too many possible issues

    Or - said in ONE WORD - employ "KISS!"    The banning of  "KISS" here makes as much sense as the recent banning of  "LIKE" - both leading to GREAT & ON-GOING INEFFICIENCIES! 

  • 0 in reply to Ralph Jacobi
    Intellectual 755 points

    Hello Ralph,

    I tried again making a new project and then made the necessary modifications in those files(cmd) and now both the example code and the modified one is working properly. Now the new file to be programmed is getting flashed at 0x00008000 and the blinky is working. Now the changes i wanted to make are as follows. Can you tell me if it's possible or not.

    Suppose i have a demo program that is loaded from memory location 0x00 up to say 0x00003000 and i want the USB_Stick_update code to be present from any location say 0x00008000 far from the demo application code. At any given time i want the demo code to be running and when i press a button it goes into an ISR and then executes the usb_stick_update code as a routine and flashes a bin file on top of that demo code without affecting the code at 0x00008000 ie the usb_stick_update routine. 

    My question is how can i write the demo code and the USB_stick_upadate code at separate memory locations because i have noticed till now that every time i flash any program the code is loaded into the flash memory sequentially. Is what i want to achieve feasible or no? If no, then is there any alternative resourceful way you can suggest that can achieve this situation? 

    Best regards, 

    Nishit.

  • 0 in reply to Nishit
    TI__Guru*** 128085 points
    Hello Nishit,

    In principle I think this should be fine, but I suppose my primary question would be why wouldn't you want the bootloader at 0x0000? That's a good spot for it as you will know how large it is and can then map the memory above it for your application. Otherwise if you put the bootloader at 0x8000, what happens if the application is suddenly 0x10000 bytes of Flash? Bootloader would get smashed then.

    Anyways, that aside, I did do a few quick tests to modify the .cmd files but it looks like the usb_stick_update example isn't working when it is located with an APP_BASE that isn't 0x0000. I haven't figured out yet what is causing this (if there is another setting, or if the device can't support a non 0x0000 location for a Flash Bootloader). There is a whole Bootloader Guide with TivaWare titled SW-TM4C-BOOTLDR-UG-2.1.4.178.pdf in the doc folder. You may want to try reading this for now.

    I plan to look into the usb_stick_update example further soon, but in the meantime perhaps you can uncover the answer in the User Guide before I get the time to delve into it myself.
  • 0 in reply to Ralph Jacobi
    Intellectual 755 points

    Hello Ralph,

    Yes, i also tried to change the APP_BASE to 0x00007000 and 0x00006000 and the USB_STICK_UPDATE doesn't work at that locations. The least memory location should be 0x00008000 for it to work properly. I'm curious about what's the reason behind this. And yes i took that issue (flash application size clashing with the Stick_update) into consideration. One solution is knowing the size of the bootloader code and then keeping it very far in the memory. Anyways, thank you for all the support that you provided. I got to learn a lot of concepts by trying this example.

    I'll also refer the bootloader document again. If you find the answer for that Stick_update issue(APP_BASE) then do let me know, as i'm curious to know the reason. I'll also try to figure this thing.

    Thank you.

    Regards,

    Nishit.