• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 97 subscribers
  • Views 1742 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Processor SDK USB Mass Storage Example Hanging on EVMAM335x

Victor Wheeler61
Expert 2215 points
Other Parts Discussed in Thread: AM3358, AM3359

Background:

Windows 7 64-bit

CCS v6.1.2.00015

Processor SDK for AM335x

In directory   C:\ti\processor_sdk_rtos_am335x_2_00_01_07   I executed (in a command prompt)

>setupenv.bat

>gmake  all

The worst messages that I saw were relatively minor warnings, like "unused variable" and the like.  Then in directory   C:\ti\pdk_am335x_1_0_1\packages   I executed

>pdkProjectCreate.bat  AM335x  evmAM335x  little  all  arm

I can see that the SoC on the EVMAM3358 is working, and one of the UARTs is working (UART example works great with Tera Term terminal emulator).

Next I connected a USB cable to USB port 0 to my PC (the USB port is labeled "USB0" in the silk screening on the main board), imported into CCS (copying the project into my own workspace) the project in    C:\ti\pdk_am335x_1_0_1\packages\MyExampleProjects\usb_dev_msc_evmAM335x_arm_project,   and built it, and loaded it in debug mode on the  General Purpose EVMAM3358, to the Cortex_A8 core.

The USB cable is known good, and tested with another device to verify this.  The USB port on the PC has also been similarly verified.

According to my understanding, this is supposed to handshake with the PC as an uninitialized  USB Mass Storage device.  However, this did not happen.  The Tera Term window has:  "RTOS USB Dev MSC example!!" and no further text.  Setting a stop point just after this string is emitted, in the function   taskFxn()   it calls USB_open(...) and never returns.  If I pause execution, the tab heading contains this string:  "setupMusbDevMsc(struct USB_Params *)  at soc/am335x/usb_soc.c:273  0x80008a54

In the file   usb_soc.c   is this code:

    status = USBDcdIntfRegisterDcd( &pDcdCoreInterface, musbObj.name );

    if ( S_PASS == status)
    {
        /* this initialisation should be done in the dwc3 device control driver */
        ...(code removed for brevity)...
    }
    else
    {
        while(1);    // some setup errors. Trap it here.       <<<<<<<<<<<  This is line 273 where CCS says it is paused.
    }

I tried the USB cable in the other USB port (on the daughter board), but this did not change the behavior.

Anyone run into this before?  Or have any ideas as to how I can make this work?

  • 0
    TI__Guru**** 393215 points
    I will ask the RTOS team to check this.
  • 0 in reply to Biser Gatchev-XID
    TI__Guru* 95265 points

    I tried this USB example multiple times recently and never came into the issue on AM335x GP EVM:

    PC: Windows 7, 64-bit

    CCS: 6.1.2

    Attached is my .out file tested this morning https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/usb_5F00_dev_5F00_msc_5F00_evmAM335x_5F00_arm_5F00_project.out, please load and run to see if it worked on your setup. When I run this, my PC detects a new USB storage and asks me to format it. After format, I get a 16MB USB to use.

    Then we can check if this is setup issue or build procedure issue. I didn't run "gmake  all" and didn't "copying the project into my own workspace"

    Regards, Eric

  • 0 in reply to lding
    Expert 2215 points

    Outstanding, Eric!


    It's running as I type this, and as they say:  a picture is worth a thousand words:

    The call to  USB_open()  (which wasn't returning)  comes just before the "Done configuring USB and its interrupt" string is printed, and  USB_open()  call is certainly now returning, and

    ...clearly it is working.

    So now it is a matter of determining what is different between our systems!


    More info:  AFTER I run your .OUT file, if I try to debug it using my project again, it works.  The call to USB_open() is returning because -- I suspect by the code in  usb_dcd_interface.c::USBDcdIntfRegisterDcd()  that something in your .OUT file initialized something in RAM, and it is still there (as opposed to being in an uninitialized power-up state).  Backing this up is the fact that if I power off my GP EVM AM3358 then run it from my project, it fails in the same way again (gets stuck at the  'while(1)' inside the call to USB_open()).

    To continue the investigation:

    1.  I deleted the   usb_dev_msc_evmAM335x_arm_project   project from within CCS.

    2.  I backed up the project directory in my workspace into a ZIP file (so we can potentially compare files to see what's different).

    3.  I deleted the project directory from my workspace.

    4.  I went to re-import in CCS, though this time NOT copying the project into my work workspace:

    5.  I imported it and opened Project > Properties to observe an error I encountered previously (see device):

    6.  I corrected that to EVMAM3358 and also correctly set the connection.

    7.  On the RTSC tab I observe that SYS/BIOS 6.45.0.19 compains of having no repositories (and the Platform drop-down list has a VERY incomplete list)...

    8.  ...so I switch it to 6.45.0.20 (and now the Platform has "the normal" -- at least from what I've seen so far -- list).

    9.  Then I issue a Rebuild -- it builds to completion without errors.

    9a.  I go to the generated EVMAM3358.ccxml   Target Configuration file, Advanced Tab, select the Spectrum Digital XDS560V2 STM LAN Emulator (top item in tree) and fill in the IP Address (since it won't connect otherwise).  (Note:  I do not have a USB cable plugged into the emulator -- only LAN cable.)

    10.  I click the green "debug" tool-bar button, and it fails in the same way:  call never returns from  USB_open() and I get this on the serial output:

    11.  For sake of file comparisons, I'm attaching the .ZIP backup I did of my workspace project directory that contains the project files and the generated files.  Would you be so kind as to .ZIP your working project directory and send a copy?  I'd really, REALLY love to get to the bottom of this, because I'm sure it is something that is going to be plaguing my future if I don't....

    usb_dev_msc_evmAM335x_arm_project.zip

    Kind regards,

    Vic

  • 0 in reply to Victor Wheeler61
    TI__Guru* 95265 points

    Vic,

    I power cycled my EVM and loaded your .out file, it always stuck at USB_open(). So it is not the test setup issue, but build steps issue. Attached is my package.

    3542.usb_dev_msc_evmAM335x_arm_project.zip

    Regards, Eric 

  • 0 in reply to lding
    Expert 2215 points

    Hi, Eric.

    So far I'm seeing several subtle differences, and it's difficult to guess which one is causing it. The biggest one is that you're connected up to a different version of SYS/BIOS. A few days after I installed the PDK, version 6.45.0.19 stopped working (compiling on a different project started failing, after which project properties reports "Product 'SYS/BIOS' v6.45.00.19 defines no repositories.") for me and I have no idea why, and going into CCS > Help > About > Installation Details > Uninstall and then CCS > Windows > Preferences > Code Composer Studio > RTSC > Install New... didn't help.

    As the next step in this test, I'd like to FIX my bios 6.45.0.19, and I think I'm going to have to fully uninstall and re-install it -- yet there doesn't seem to be an obvious way to do that. Can you advise me? Is it safe to uninstall from CCS, then delete the directory and run the PDK installer again?

    Thoughts?

    Kind regards,
    Vic

  • 0 in reply to Victor Wheeler61
    TI__Guru* 95265 points
    Yes, you can do this "uninstall from CCS, then delete the directory and run the PDK installer again".

    Regards, Eric
  • 0 in reply to lding
    Expert 2215 points

    Hi, Eric!

    Done!  While that certainly fixed my SYS/BIOS 6.45.0.19, it didn't change the board behavior.  So I'm on to the sniffing out the next difference....

  • 0 in reply to lding
    Expert 2215 points

    Hi, Eric!

    The next big difference that is drawing my attention is our linker scripts:  for whatever reason I have an AM335x.lds file that is set as the linker command file (looks like linker command line contains   -T"../AM335x.lds"  on mine, and -T"configPkg/linker.cmd" on yours.  Though I have the latter file, something set up the AM335x.lds as the linker command file when I imported the project.  Comparing the two  .cproject   files, mine has:

                                    <listOptionValue builtIn="false" value="LINKER_COMMAND_FILE=AM335x.lds"/>

    as a <storageModule ... ><configuration ...> <folderInfo ...><toolChain ...><option ...><listOptionValue ...>, whereas yours has:

                                    <listOptionValue builtIn="false" value="LINKER_COMMAND_FILE="/>

    and we both have identical ./Debug/configPkg/linker.cmd  files.

    So I manually REMOVED the preconfigured AM335x.lds  linker command file from  Project > Properties > General > Main Tab > Advanced Settings > Linker command file (using the drop-down list and selecting "<none>"), and then issued a  Rebuild on the project.  Cleaning, compiling and linking all finished without errors.  And when I ran the project from a previously powered-off EVMAM3358, now it is working:  the  USB_open() function is returning and the board immediately enumerates with the PC, the PC suggests formatting the unformatted "drive" and voila!  Now it's working.

    For what it's worth, removing that AM335x.lds caused the newly-generated   ./Debug/configPkg/ccsObjs.opt   file to now contain the same linker options as yours (namely:   -T"configPkg/linker.cmd" ).

    Okay -- so this leaves me with a lot of unanswered questions.

    1.

    First, I'd like to do a through version comparison if you wouldn't mind:

    CCS:  6.1.2.00015

    (I notice you have a few files under directory  c:\ti_6_1_1\...   appears to be connected with things in its "ccsv6" sub-directory.)

    PDK:  1.0.1

    XDCtools:  3.31.2.38_core    << I noticed that yours doesn't have the "_core" part in the name.  Is that significant?

    When I do a close comparison in the ./Debug/packages/  directory and sub-directories, the above 2 things (CCS directory) and XDCtools "3.31.2.38_core" vs "3.31.2.38" seem to be the only differences.

    2.

    Second, I'd like to ask:  what caused the AM335x.lds  file to be set as the linker command file when I imported the project?  The only place a caseless scan locates the string "AM335x.lds" is in the file   c:\ti\pdk_am335x_1_0_1\packages\ti\starterware\bootloader\ccs\.cproject   .  I feel very confused.

    3.

    Third, how could these differences have caused something in RAM (USB gadget list?) not to be initialized (or perhaps not located in the expected location), thus causing USB_open() not to return, while running -- apparently -- the same source code?  Or is that latter a bad assumption?

    In case it is helpful, I attached the NOW WORKING PROJECT in a .ZIP file.

    working_in_place_19_usb_dev_msc_evmAM335x_arm_project.zip

    Kind regards,

    Vic

  • 0 in reply to Victor Wheeler61
    TI__Guru* 95265 points

    Vic,

    Good to know it is working now!

    • 3.31.2.38_core" vs "3.31.2.38": the _core is cut down version of the original, it should work.
    • CCS 6.1.1 and CCS 6.1.2 mess up, that is my problem, I have both versions installed, and sometimes I open the project with 6.1.1, and sometimes used the other. The release uses 6.1.2 only.
    • AM335x.lds added, when you import the project, for some reason your CCS can't find the defined target, then you manually change the taget to AM3358 or AM3359, the lds is automaticllay added at that stage. My CCS has the right target so no such issue.  
    • Why added lds caused the issue? maybe there are different section/stack/heap definitions between two linker command file and caused some problem. You may look at the .map file between working and stuck case for the clue.

    Regards, Eric

  • 0 in reply to lding
    Expert 2215 points

    Thanks, Eric!

    I DID have to change the target (mine imported saying the target was ICE_AM3359).

    I can read the linker scripts too (in addition to the MAP file) and compare memory maps....  I believe this will be important knowledge!  I'll share if I find something concrete.

    Thank you again for your time and attention.  That and the file comparisons between working and non-working versions helped a lot!

    Kind regards,
    Vic

  • 0 in reply to Victor Wheeler61
    Expert 2215 points

    P.S.  Heads up to TI engineering staff who manage the PDK:

    The fact that the imported target was set to ICE_AM3359 is caused by the   pdkProjectCreate.bat   file at line 436.  If a person has an EVMAM3358, the only choice that appears to be correct for the SOC and BOARD arguments for this batch file  AM335x  and  evmAM335x  respectively.  However, the string  AM335x  for the SOC argument causes this line to execute:

       set CCS_DEVICE="Cortex A.AM3359.ICE_AM3359"

    and then that value propagates out from there.

    However -- and I'm calling BUG here -- and I'm providing a work-around -- at least for EVMAM3358 customers:   if you edit the   pdkProjectCreate.bat  file and replace the ELSE IF block at line 436 with this:

    ) else if  %SOC% == AM335x (
       set PDK_PARTNO=AM335
       set PDK_ECLIPSE_ID=com.ti.pdk.am335x
       set RTSC_PLATFORM_NAME=ti.platforms.evmAM3359
       set RTSC_TARGET=gnu.targets.arm.A8F
       rem 03-Mar-2016 12:55 vw
       rem This doesn't work for users who have an EVMAM3358 platform,
       rem so this is being replaced so that projects will work right
       rem when imported without the need for a lot of fiddling about.
       rem Reason:  Changing the target device in the project can and does
       rem silently alter the linker command file entry causing some examples
       rem to flatly not work.  Case in point:  USB Mass Storage example.
       rem Original code:
       rem set CCS_DEVICE="Cortex A.AM3359.ICE_AM3359"
       rem Code that replaces it:
       if %BOARD% == icev2AM335x (
            set CCS_DEVICE="Cortex A.AM3359.ICE_AM3359"
        ) else if %BOARD% == evmAM335x (
            set CCS_DEVICE="Cortex A.AM3358.EVMAM3358"
        ) else if %BOARD% == skAM335x (
            set CCS_DEVICE="Cortex A.AM3358.SK_AM3358"
        ) else (
            set CCS_DEVICE="Cortex A.AM3358.BBBAM3358"
        )


    (note the hard-coded ICE_AM3359 SET line is the only line that changed -- comments and IF/ELSE were added)

    Then issuing this command in   C:\ti\pdk_am335x_1_0_1\packages\  

    pdkProjectCreate.bat  AM335x  evmAM335x  little  usb  arm

    NOW creates a project that will work the FIRST TIME on the EVMAM3358 platform.

    Now the import sequence looks like this (I have an XDS560V2 STM LAN emulator):

    ...and the RTSC tab...

    ...is already correct without any changes needing to be made.  To connect to the LAN emulator, it needs to know the emulator's IP address, so I set that by opening the  .ccxml   file here:

    ...and replacing   "x.x.x.x"   with the emulator's IP address:

    ...and I do a BUILD on the project.  It compiles and links correctly the first time.  And I click the green "debug" button (to load the program and debug it), and the whole thing works right the first time:  it enumerates with the PC, PC formats the mass storage device, and everything works.

    SO:   TI Staff:  I would suggest, providing this fits design parameters, that ANOTHER SOC / BOARD combination be made valid for the pdkProjectCreate.bat  batch file:

    1.  For customers like me with the EVMAM3358 platform:   pdkProjectCreate  AM335x  evmAM3358  little  <module>  arm

    ...and CCS_DEVICE environment variable is set to "Cortex A.AM3358.EVMAM3358".  (Note the above is currently not a valid combination.)

    2.  And for customers with the Industrial Communication Engine (ICE) AM3359 EVM, that they be able to issue this command:

    pdkProjectCreate  AM335x  icev2AM3359  little  <module>  arm

    ...and the CCS_DEVICE environment variable is set to "Cortex A.AM3359.ICE_AM3359".

    3.  You might also want to have a look at the answer to this question:  when I select either of the 2 SYS/BIOS versions 6.45.00.19 or 6.45.00.20, the only CLOSE correct platform I have to select from is "ti.platforms.evmAM3359", which is technically not correct!  Why isn't there a "ti.platforms.evmAM3358"?  I suspect this item being missing is part of the problem.  Perhaps the EVMAM3358 is newer than the pdkProjectCreate.bat  and the batch file (and other directories and config files) were not updated to accommodate the new product yet?


    Hope this helps.

    Kind regards,

    Vic