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.

RTOS/AM4377: USB mass-storage example fails

Part Number: AM4377

Tool/software: TI-RTOS

Hello all,

I'm experiencing an issue with running the USB mass-storage host example application on a custom AM4377 board. Application in question is as-per supplied example application 'usb_host_msc_evmAM437x_arm_project' however with PINMUX changed to reflect the custom board instead of EVM.

This application executes successfully when loaded via the CCS debugger connection (i.e. can navigate command-line interface of attached USB MS device with FATFS). However if the same application is loaded via the Starterware bootloader from mmcsd device the enumeration fails with the following console output (address set fail):

RTOS USB Host MSC example!!
got intr. portNum = 0. ptrEvent=0x8004c000
-> PSC on port 1
xhciPortNum!=2. Using USB2.0 initialization sequence
about to do port reset! PORTSC1=0x6e1
about to do enable slot. PORTSC1=0xe03
about to set Address
USBHCDMain failed with this error: 0x60004

The only difference between the two cases that I that can see is the GEL file initialisation (for debugger load) vs. SBL initialisation (for mmcsd load) but I cannot see anything in either code-base that would affect USB operation. I have not seen this issue while loading any other application via mmcsd SBL. 

Any suggestions for a way forward here appreciated.

Kind regards,

David

  • Hi,

    The RTOS team have been notified. They will respond here.
  • David,

    Some suggestions:

    First to check PINMUX setting: assuming you did some steps like
    processors.wiki.ti.com/.../Processor_SDK_RTOS_Board_Support to create a board library for your own board due to some PINMUX change. When you run the standalone USB host example, you have a Board_init(boardCfg) where BOARD_INIT_PINMUX_CONFIG flag is set, this calls into the board library to use your new PINMUX. Then in the MMCSD boot mode, you have a MMCSD bootloader (SBL, or called MLO), make sure the MLO is rebuilt with your new board library, as MLO does the PINMUX setting for you.

    Then, in your USB host application, you need to rebuild it with BOARD_INIT_PINMUX_CONFIG flag removed, as you can't have both SBL and application intialize the pinmux.

    Is this the case that you have the failure?

    Regards, Eric
  • Eric,

    Many thanks for your response to my query.

    I have re-visited the PINMUX configuration and do not believe that this is causing the issue - I have created my own board library for the custom board, which works successfully with all other example projects that I have run. The USB pinmux definitions and function calls are identical to those of the EVM. The USB pinmux is not performed by the Starterware bootloader (MLO) and hence if I remove the BOARD_INIT_PINMUX_CONFIG flag in the Board_init call the example application fails as would be expected.

    Moreover, the error condition which I reported in the opening-post used PDK version 1.0.4 - I have subsequently updated my environment to use PDK 1.0.5 (from the release notes for this revision I note that fixed issue PRSDK-351 relates to the USB examples). In this configuration, the USB example application 'usb_host_msc_evmAM437x_arm_project' again runs successfully via debugger, however I am currently unable to launch it via MMCSD as the .bin/_ti.bin outputs from the post-build steps are enormous (i.e. .out is ~1.6Mb, .bin is ~512Mb) and therefore unable to exercise the original failure mechanism.

    Are you able to provide any further insight into this issue and/or raise with the development team?

    Best regards,

    David

  • David,

    I did a very similar work last year: boot USB host example on AM57x from a MMCSD card. The method is based on the \ti\board\diag package, it has a MLO (SBL, which initialzed PINMUX), MLO loads an "app", the app is framework_loader. The "app" loads the real application to run, this real application can be anythinfg, e.g. QSPI, EMAC, or your own USB host example.

    I did some debug work at that time as I have the same issue: standalone USB example works but it dlidn't run to finish when boot from MMCSD. The way is 1) I used JTAG WITHOUT gel to connect to the ARM core 2) set breakpoint at where the framework jumping into the real application 3) load symbol of the application 4) then step through the application assmbly code to debug. I found some USB intialization sequence issue which worked in standalone (CCS/GEL case) but failed in MMCSD card case. The issue was already fixed in 1.0.4 release (AM57X and AM437x use the same DWC USB). Then USB host works for me from MMCSD card, on AM57x.

    So, what we found earlier may not related to your issue. I didn't try the AM437x USB case. You may follow my sugestion to debug the application, maybe you can quickly find out some code didn't execute in MMCSD case.

    If issue is still there, I will raise it to our development team.

    Can you explain the file size issue, from 1.0.4, how big is the image on SD card? Why 1.0.5 has 512MB?

    Also, I will try my old approach MLO+APP+USB application (your approach is MLO+USB application) on AM437x for your case, to see if I can find something and will let you know in a few days.

    Regards, Eric
  • David,

    For the binary converted from USB host example .out file, I saw the file size is 512MB vs 174KB, PDK 1.0.5 vs PDK 1.0.4. I used the pdk_am437x_1_0_4\packages\MyExampleProjects\usb_host_msc_evmAM437x_arm_project as the starting point, and only changed host_msc_main.c to avoid double intialization of PINMUX:

    #if 0

       boardCfg = BOARD_INIT_MODULE_CLOCK |

           BOARD_INIT_PINMUX_CONFIG |

           BOARD_INIT_UART_STDIO;

    #endif

       boardCfg = BOARD_INIT_UART_STDIO;

       Board_init(boardCfg);

    Then, for the .out file from above CCS project:

    C:\ti\PDC3A6~1\packages>C:\ti_6_1_3\ccsv6\tools\compiler\gcc-arm-none-eabi-4_9-2015q3\bin\arm-none-eabi-objcopy -O binary C:\ti\pdk_am437x_1_0_4\packages\MyExampleProjects\usb_host_msc_evmAM437x_arm_project\Debug\usb_host_msc_evmAM437x_arm_project.out C:\ti\pdk_am437x_1_0_4packages\MyExampleProjects\usb_host_msc_evmAM437x_arm_project\Debug\usb_host_msc_evmAM437x_arm_project_my.bin

    C:\ti\PDC3A6~1\packages>C:\ti\pdk_am437x_1_0_4\packages\ti\starterware\tools\ti_image\tiimage.exe 0x80000000 NONE C:\ti\pdk_am437x_1_0_4\packages\MyExampleProjects\usb_host_msc_evmAM437x_arm_project\Debug\usb_host_msc_evmAM437x_arm_project_my.bin

    C:\ti\pdk_am437x_1_0_4\packages\MyExampleProjects\usb_host_msc_evmAM437x_arm_project\Debug\usb_TEST

    Then I copied MLO, app (this came from ) and usb_TEST into a MMCSD card. I have no issue to boot up the USB example, see below log (test case #15):

    StarterWare Boot Loader
    BOARDInit status [0x0]
     SoC                   : [AM43XX]
     Core                  : [A9]
     Board Detected        : [GPEVM]
     Base Board Revision   : [1.5]
     Daughter Card Revision: [UNKNOWN]
    GPIO Instance number: 5
    Pin number: 7
    Copying application image from MMC/SD card to RAM
    Jumping to StarterWare Application...


    Opening framework from SD card...
    Loading framework into memory...
    Copying application image from MMC/SD card to RAM
    Running framework

    DIAGNOSTIC TEST FRAMEWORK
    Command options:
            help - displays this help menu again
            run - run a diagnostic application
            status - prints the test status
    [Diag Menu]:
    [Diag Menu]:
    [Diag Menu]:
    [Diag Menu]:
    [Diag Menu]:
    [Diag Menu]: run
    Diagnostic Test Status:
    --------------------------------------------------------------
    ID      Name                            Pass    # of times Ran
    1       ambient_light_sensor_TEST       No      0
    2       button_TEST                     No      0
    3       uart_TEST                       No      0
    4       accelerometer_TEST              No      0
    5       adc_TEST                        No      0
    6       buzzer_TEST                     No      0
    7       eeprom_TEST                     No      0
    8       haptics_TEST                    No      0
    9       led_TEST                        No      0
    10      mem_TEST                        No      0
    11      mmcsd_TEST                      No      0
    12      pmic_TEST                       No      0
    13      rtc_TEST                        No      0
    14      temperature_TEST                No      0
    15      usb_TEST                        No      0

    Select test number (1 - 15): 14
    Parsing temperature_TEST
    Copying application image from MMC/SD card to RAM
    Running temperature_TEST

    *********************************************
    *         Temperature Sensor Test           *
    *********************************************
    Testing temperature sensor...
    got rx[0] = 27, rx[1] = 128, val = 440
    Temperature = 27 C
    Test PASSED!
    Finished running temperature_TEST, result passed!
    [Diag Menu]: 15
    [Diag Menu]: run
    Diagnostic Test Status:
    --------------------------------------------------------------
    ID      Name                            Pass    # of times Ran
    1       ambient_light_sensor_TEST       No      0
    2       button_TEST                     No      0
    3       uart_TEST                       No      0
    4       accelerometer_TEST              No      0
    5       adc_TEST                        No      0
    6       buzzer_TEST                     No      0
    7       eeprom_TEST                     No      0
    8       haptics_TEST                    No      0
    9       led_TEST                        No      0
    10      mem_TEST                        No      0
    11      mmcsd_TEST                      No      0
    12      pmic_TEST                       No      0
    13      rtc_TEST                        No      0
    14      temperature_TEST                Yes     1
    15      usb_TEST                        No      0

    Select test number (1 - 15): 15
    Parsing usb_TEST
    Copying application image from MMC/SD card to RAM
    Running usb_TEST

    RTOS USB Host MSC example!!
    got intr. portNum = 0. ptrEvent=0x8004c000
    -> PSC on port 1
    xhciPortNum!=2. Using USB2.0 initialization sequence
    about to do port reset! PORTSC1=0x6e1
    about to do enable slot. PORTSC1=0xe03
    about to set Address
    about to get device descriptor
    about to get Configuration descriptor
    USBHostConfigureEndpoint. EP=1. pks=767. epType=6
    USBHostConfigureEndpoint. EP=2. pks=767. epType=2
    about to set Configuration
    0:>ls
    D---- 2007/06/05 11:38         0  test_empty
    D---- 2007/06/05 11:38         0  test
    D---- 2013/03/18 14:06         0  Drivers and manuals
    ----A 2013/11/22 10:14    233984  Socket setup Complete.doc
    ----A 2013/11/22 10:16     75520  udp.pcapng
    ----A 2013/11/20 17:12     50456  cap.pcapng
    ----A 2013/11/20 17:12      1100  mylog.txt
    ----A 2013/10/15 13:45      1734  Readme.txt
    ----A 2013/11/22 12:14   4636678  helloWorld_evmc6670_customer.out
    ----A 2013/11/22 12:19   4636678  helloWorld_evmc6670_no_100.out
    ----A 2013/12/06 11:13      9064  pingtest_1206.pcapng
    ----- 2014/02/24 04:01    392720  u-boot-spi-keystone-evm.gph
    ----- 2014/02/24 04:01    327120  u-boot-keystone-evm.bin

      10 File(s),  10365054 bytes total
       3 Dir(s),    1926432K bytes free
    0:>

    Regards, Eric

  • Next I did is to delete the "app" and rename "usb_TEST" to "app", then boot it up. See below screenshoot:

    So there is some issue of binary size on PDK 1.0.5, but no issue to boot USB host example from MMCSD using PDK 1.0.4.

    Regards, Eric

  • Eric,

    Many thanks for your input and investigations following my original query and also subsequent binary conversion file-size query.

    I have now resolved the USB MSC issue following boot from MMCSD - this was being caused by the SBL (MLO) configuring the clock module for 24MHz input clock (as per the IDK) however our board uses a 25MHz reference. The GEL file takes this into account by reading the relevant SYSBOOT pin state and configuring the clock module accordingly; the equivalent SBL function is in file 'sbl_am43xx_platform_pll.c' which does read the SYSBOOT configuration but then the clock configuration is hard-coded and not influenced by the detected SYSBOOT configuration. I have modified this function accordingly and the USB MSC example now executes correctly.

    Kind regards,
    David
  • David,

    Glad to know MMCSD boot of the USB example worked on your side! For the PDK 1.0.5 binary size issue, do you need that resolved or you can use the PDK 1.0.4?

    Regards, Eric
  • Eric,

    Happy to use the PDK 1.0.4 for the time-being. It would be useful if the binary size issue is recorded as a known issue however so can be resolved in future releases.

    Regards,
    David