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.

am17x support?

Other Parts Discussed in Thread: AM1808, AM1707, AM1705, SW-USB-WINDRIVERS, OMAPL138, OMAP-L138

Please read before posting!

Update 2012-01-10: the goal of this thread is now to port the StarterWare AM1808 USB Bulk Device example (or similar functionality) to the AM1707 EVM board.

Question 1: Is StarterWare not available for Sitara AM17x?  Specifically, AM1705..
Answer 1:  No, it is not available.  See Baskaran's post.

Question 2: Can the uartEcho example (serial port) be ported from AM1808 to run on the AM1707 EVM?
Answer 2: Yes.  See this post, with source code included as sw_am17x_2012-01-10-UART_interrupt_works!.zip

Question 3: Can the usb_bulk_dev example be ported from AM1808 to run on the AM1707 EVM?
Answer 3: Yes.  See this post, with source code included as gcc_usb_bulk_dev_am1707.zip


At TI's behest, please post questions about porting other parts of StarterWare in a fresh thread.  However, for questions about any existing posts, I think it would make more sense to reply on this thread.

Special thanks to Baskaran, Madhvapathi, Sujith, and Vivek!

  • Jonathan,

                    StarterWare support is not available for AM17x. For the list of supported Socs please refer http://processors.wiki.ti.com/index.php/StarterWare.


    Thanks

    Baskaran

  • Thank you, Baskaran!

    TI's press release mentions "packages for additional devices planned for the coming month" - is there any chance that AM17x is one of these?  The entire USB stack got ported to Sitara (from Stellaris?), so I was hoping it was a much shorter hop from AM18x to AM17x...

    Unfortunately due to hardware design considerations we are forced to stick with the AM1705, which to my knowledge is the only Sitara chip available in a flatpad package..

    StarterWare is exactly what we need for our finished product - although StarterWare is free of charge for supported platforms, we would gladly buy ("sponsor"?) a port to AM17x!

     

    Best,

    Jonathan

  • Jonathan,

    I have used both AM17x and AM18x before. IMHO it should be easy to re-use AM18x Starterware for AM17x. All you you will be required to do is some change in interrupt numbers, DMA channel numbers and base addresses.

    Depending on your use case, perhaps AM18x could be a superset and the package would suffice for AM17x (I se UPP and McBSP as additional peripherals on AmM18x).

    You could probably try your luck with a simple UART based example porting to get a feel of the effort of re use

    Good luck,

    Regards,

    Madhvapathi Sriram

  • Update (2012-01-12): the zip file posted here does not work.  For working AM17x uartEcho code, see "sw_am17x_2012-01-10-UART_interrupt_works!.zip" below.


    Dear Madhvapathi Sriram,

    Thank you for your help!

    I am proceeding slowly along the lines you suggested, chronicling my misadventures below.. Any advice would be greatly appreciated, but at the very least I can preserve my findings for other complete novices like myself?  I am developing using CCSv4 in Windows + Spectrum Digital's evaluation board EVMAM1707, running code directly using the debugger and the out-of-box evmam1707.gel file.

    Current status, starting from StarterWare's UART non-EDMA example

    - UART communication via StarterWare API works (UARTCharPut/Get can indeed communicate with PuTTY)

    - interrupts do not work??

    The latter is problematic because my ultimate goal is to deploy the functionality in the StarterWare USB Bulk Device example, which uses both USB and Interrupt StarterWare modules. 

    My approach is to take a minimal subset of code from StarterWare AM1808 and recompile it as an independent project.  To get to this point, the only thing that required non-trivial changes was the pinmux...My project is attached at the top of the post.

    Untouched

    - interrupt numbers (only using UART2, which is 61 in both AM17x and AM18x)

    - DMA channel numbers (not using DMA?)

    - base addresses (most addresses are the same in both AM17x and AM18x - esp. PSC, UART2, and AINTC)

    Renamed

    examples/evMAM1808/uart/uartEcho.c -- renamed to main.c

    drivers/uart.c -- renamed to uart_api.c

    system_config/armv5/cgt/cpu.c -- renamed to cpu_cgt.c [../gcc/cpu.c did not compile]

    Minor modifications to uartEcho.c

    - /* #include "evmAM1808.h" - just some unused prototypes */

    - in call to UARTConfigSetExpClk, adjust UART2 clock speed to work with evmam1707.gel

    - added my own test code using UARTCharPut/Get to verify that serial port is indeed working; commented out in attachment.

    Unusable - had to rewrite

    include/hw/hw_syscfg0_AM1808.h (pin multiplexing #defines) - wrote up tiny subset with the help of PinSetup.exe as hw_syscfg_AM1707.h

    platform/evmAM1808/uart.c (pin multiplexing code) - wrote new AM17x version for UART2 as uart_platform.c

    Things I've tried without success to get interrupts to work

    - printf: UARTIsr is never being called?

    - reordering the Interrupt API calls to that stated in the wiki

    - populating all of fnRAMVectors with UARTIsr

    - changing the third instruction in cpu.c/CPUirqe() to "msr CPSR, r0"

    Thanks again!

    Jonathan

    sw_am17x.zip
  • Update (2012-01-12): the zip file posted here does not work.  For working AM17x uartEcho code, see "sw_am17x_2012-01-10-UART_interrupt_works!.zip" below.


    After the "progress" below, I'm now actually in supervisor mode and IntMasterIRQEnable() actually does something, but now the board simply hangs during the call to UARTIntEnable, which is just a register write?!  (You can confirm this by setting a breakpoint right after the function call - the board never gets there.  Setting a breakpoint before the call seems to modify the behavior?!)

    Also, reproducible behavior can only be obtained by power-cycling the board (can't just Reload Program).

    Updated project is attached, and the (unmodified) evmam1707.gel is included now too.

    C:\Program Files (x86)\Texas Instruments\ccsv4\tools\compiler\tms470\lib\rtssrc.zip\boot.asm

    - add to project

    - change the (32-bit) "USER MODE" line to "ORR     r0, r0, #0x13" (spruh94a.pdf p. 75)

    - link with rts32e.lib in linker.cmd (had this commented out before)

    sw_am17x.zip
  • Hi Jonathan,

    Thanks for the nice explanations on the methods you tried to find the issues.

    I went through the zip file you sent, but I did not import it to CCS or test it. But I have some basic queries,

    1. When I looked at the linker command file, I see differences with the StarterWare linker command file. We have not tried CCS provided initialization/interrupt handlers in StarterWare. StarterWare comes with its own code/methods  for initialization and exception handling. Have you tried the UART interrupt application using StarterWare provided initialization and exception handling? (if not, could you please try this way also)

    2. Could you please tell me where the interrupt vectors are mapped and loaded to memory ? (I could not find it from linker script. Sorry if I am not able to figure it out)

    3. I could not find IRQ handler file in the zip package you sent. (Just wanted to verify how it takes the address of ISR from HIPVR2). Could you please include that, if different from the exceptionhandler.asm in StarterWare ?

     

    Regards,

    Sujith.

  • Update (2012-01-12): the zip file posted here does not work.  For working AM17x uartEcho code, see "sw_am17x_2012-01-10-UART_interrupt_works!.zip" below.


    Dear Sujith,

    Thank you for your helpful reply! 

    I am currently trying your suggestions (at least, the ones I was able to figure out).  I have tried to respond to your queries below.  Basically I have tried to use StarterWare code wherever possible.  (These changes are now reflected in the attached project [apologies for length; this also serves as a master copy of my notes]):

    1. linker.cmd: replaced with StarterWare's uartEcho.cmd then fixed linker errors as best as I could

    • linked with libc.a
      - unresolved symbol __TI_auto_init; follow .ccsproject
    • commented out .init section
      - unsure about compatibility with pre-compiled AM1808 system_config.lib
      - will try to recompile from source wherever possible
    • added system_config/armv5/cgt/init.asm to project
      - unresolved symbol Entry
    • added system_config/armv7/am1808/startup.c to project
      - unresolved symbol start_boot
      - #included only a minimal set of header files and definitions
    • linker error persists: unresolved symbol start_boot, first referenced in ./init.obj
      - hacked init.asm uglily and probably incorrectly to get project to link as follows
      -- .global/.ref _start_boot (added leading underscore to link with C function)
      -- comment out label _start_boot - instead this will be linked from startup.c
      -- entry to _start_boot is changed - probably incorrectly?? see "B _start_boot"

    2. (in 1. above) added StarterWare's system_config/armv5/am1808/startup.c to project, with minimal changes to allow compile

    • to pre-empt a later linker error ("unresolved symbol _Entry, first referenced in ./startup.obj"), in init.asm:
      .def _Entry
      ...
      _Entry:
          .word Entry - corrected in a following post

    3. added to project system_config/armv5/am1808/cgt/exceptionhandler.asm

    • linker errors: unresolved symbols _AbortHandler, ..., first referenced in startup.obj
      just to link, added lines like
      .def _AbortHandler
      ...
      _AbortHandler:
          .word AbortHandler - corrected in a following post
    • linker error: unresolved symbol CPUAbortHandler, first referenced in ./exceptionhandler.obj
      - .ref _CPUAbortHandler (add leading underscore)
      - comment out the assembler label; will link with cpu.c instead
      - in AbortHandler, change to "B pc, _CPUAbortHandler" (this is probably wrong? see also ugly init.asm hack above)

    4. Finally, there are remaining linker errors: unresolved symbol _SysCfg RegistersLock, first referenced in ./startup.obj

    • add platform/evmAM1808/syscfg.c to project
    • add SYSCFG_KICK0R_UNLOCK, etc. #defines to custom hw_syscfg_AM1707.h (spruh93a.pdf p. 177: AM17x magic numbers match AM1808 header file! yay)

    This compiles and links, but on brief testing still does not output to UART via interrupts.  The resulting project is attached as sw_am17x 2012-01-09.zip.

    Where in the TI documentation can one learn more about these things?  (Update: compiler manual, spnu151f.pdf, Chapter 6?)  I could not find most if not all of the details you mentioned in the AM17x reference manuals.. I would like to learn more but do not know where to start, so unfortunately I am reduced to bothering the kind people on these forums for help!

    Sorry about all my ignorance on most of these issues; my original starting point was the example programs included with the Spectrum Digital AM1707 EVM.  Although these examples are helpful for getting started, they do not include any code for USB (besides a simple power example) or interrupts.

    Thank you again for your help!!

    Best,
    Jonathan

    sw_am17x_2012-01-09.zip
  • Update (2013-04-15): fixed some silly errors in tests/uart_sw/uart/.project and updated the included readme file.

    My build/system configuration:

    • Code Composer Studio 5.1.0.09000
    • Spectrum Digital AM1707 EVM Rev. H (the "target board")
    • evmam1707bsl.lib from Spectrum Digital (last modified date 2010-02-25) - place with linker.cmd
    • RS-232 connecting target board to PC at 115200 kbps baud rate

    When running correctly, the target board should output "StarterWare AM1808 UART echo application." to the PC, and then echo back any keyboard input from the PC thereafter.


    Debugger stepping reveals previous mistake: In order to call functions or use function pointers from exceptionhandler.asm/init.asm in startup.c or linker.cmd, extra labels should be added

    _Entry:
    Entry:
        LDR r0, _stackptr
        ...

    It was very helpful to check whether a call to CPUSwitchToPrivilegedMode() was jumping to exceptionhandler.asm/_SWIHandler.

    These minor modifications to the 2012-01-09 project results in a working uartEcho (UART + interrupt) example for AM1707!  This working example is attached as a zip file.

    Thank you, Sujith and Vivek!!!


    Summary so far
    The StarterWare AM1808 uartEcho example can be ported to AM1707 through the following steps:

    1. Create CCS project with the following StarterWare files:
      examples/evmAM1808/uart/uartEcho.c
      include/psc.h
      include/uart.h
      include/armv5/cpu.h
      include/armv5/am1808/evmAM1808.h
      include/armv5/am1808/interrupt.h
      include/armv5/hw/hw_aintc.h
      include/armv5/hw/hw_types.h
      include/armv5/hw/hw_psc_AM1808.h
      include/armv5/hw/hw_uart.h
      include/armv5/hw/soc_AM1808.h
      system_config/armv5/am1808/interrupt.c
      drivers/psc.c
      drivers/uart.c

      Thanks to Sujith for pointing out additional files essential for enabling interrupts:
      system_config/armv5/am1808/startup.c
      system_config/armv5/cgt/init.asm
      system_config/armv5/am1808/cgt/exceptionhandler.asm
      platform/evmAM1808/syscfg.c
      build/armv5/cgt_ccs/am1808/evmAM1808/uart/uartEcho.cmd
      - from .ccsproject, add the line -l libc.a
      - comment out .init section to avoid compatibility issues with pre-compiled AM1808 system_config.lib

    2. Since AM17x and AM18x are not pin-compatible, using PinSetup.exe and spruh93a.pdf (Chapter 10.4.9), rewrite and add to project the following files:
      platform/evmAM1808/uart.c
      include/hw/hw_syscfg0_AM1808.h [just the #defines needed to compile]

    3. In main(), change the second argument passed to UARTConfigSetExpClk() to the half the CPU speed; for out-of-box evmam1707.gel, this was 456000000/2.

    4. Make (small) changes to c files to eliminate compile/link errors as needed.

    5. Make (small) changes to asm files to eliminate assemble/link errors as needed (see attached project and posts above).

    In response to Madhvapathi Sriram on potential issues for porting from AM1808 to AM17x:

    • Interrupt numbers are surprisingly portable!
      - spruh82a.pdf vs spruh94a.pdf, Chapter 11
      - no changes required for uartEcho
    • Memory map addresses are nearly identical
      - data sheet comparison; SPI1 is bizarrely different
      - no changes required for uartEcho
    • DMA channel numbers: haven't used this yet
      - n/a for uartEcho; we'll see for USB Bulk Device...
    • Pin multiplexing, on the other hand, is completely different!
      - spruh82a.pdf vs spruh94a.pdf, Chapter 10.4.9

    Thank you, Sujith and Vivek!!!

    sw_am17x_2013-04-15-UART_interrupt_CCS5.zip
  • Some preliminary work on usb_bulk_dev.

    Current status when USB0 is connected to a Windows 7 PC:

    • "USB Device Not Recognized"
    • Device Manager > Hardware Ids: "USB\UNKNOWN" [no VID/PID at all!]

    Procedure

    • collect all StarterWare files required to compile/link
      - for convenience, remove all graphics code from main.c (nee usb_bulk_dev.c)
      - hw_syscfg_AM1707.h and uart_platform.c with non-trivial changes from uartEcho project
      - init.asm and exceptionhandler.asm with minor changes from uartEcho project
    • in hw_usb.h, the following helps with compile errors:
      #if !defined(SOC_USB_0_BASE)
      #include "psc.h"
      #include "soc_AM1808.h"
      #include "hw_psc_AM1808.h"
      #include "hw_usbphyGS60.h"
      #include "hw_usbOtg_AM1808.h"
      #endif
    • fix any remaining compile/link errors
    • connect USB0 to host PC and run the application
      - result: the USB device isn't even detected by the PC?
    • modification to usbphyGS60.c/UsbPhyOn(): also clear bits 13-14 of CFGCHIP2
      - reason: evmAM1707 defaults to force host?! (bit 13 set) - probably due to evmam1707.gel (CFGCHIP2 = 0x00002872;)
      - result: Device Manager detects the device but cannot enumerate (no PID/VID detected at all)

    usb_bulk_dev_20120112.zip
  • Update (2012-01-23)

    • successful enumeration and data transfer is obtained by migrating to the CodeSourcery gcc toolchain (see Verified Answer below)
    • confirmed by getting a working (!!!) usb_bulk_dev example (post forthcoming): USB data lines are not inverted, at least not for my AM1707 EVM Rev. H
    • Spectrum Digital's evmam1707.gel and evmam1707_techref.pdf are both wrong, at least for my AM1707 EVM Rev. H; the "Nay"s have it, below!

    Update: now SOF and EP0 interrupts are flowing freely - but still the device does not enumerate.

    List of all non-trivial modifications to usbphyGS60.c/UsbPhyOn():

    1. // clear "force USB host" - which was set in the factory evmam1707.gel
      reg &= ~(CFGCHIP2_FORCE_HOST | CFGCHIP2_FORCE_DEVICE);

    2. // do NOT invert data line polarity - which was also set in factory evmam1707.gel
      // n.b. If you also set FORCE_DEVICE, the Disconnect interrupt will not trigger, and debug output will be hard to read.
      reg |= CFGCHIP2_DATPOL; // bit CFGCHIP2[USB0DATPOL]

    I'm especially unsure about step 2, but it seems to get results? Arguments for/against swapping D+/D-:

    • YEA: factory evmam1707.gel explicitly resets CFGCHIP2[USB0DATPOL]
    • YEA: evmam1707_techref.pdf p. 26 (shipped with CCS4; "TMS320AM1707 Evaluation Module" by Spectrum Digital)  "Use internal register to swap DM/DP pair. This feature was used to improve printed circuit board routing."
    • NAY: evmam1707_techref.pdf p. 53 (Rev. G hardware schematic): shows D- routed to USB0_DM and D+ routed to USB0_DP in all cases (fwiw, my AM1707 EVM Rev. H uses the micro/A/B adapter)
    • NAY: without step 2, SOF and EP0 interrupts do not trigger!

    References:
    USB initialization thread - previously at junior major's problem; now at ana leticia's problem?
    sad but true

    Project not uploaded because there is only one modification to 2012-01-12 .

  • Chen,

             We have not tested with windows 7. it would take some time for us to check this. Can you try with windows XP?

    Regards

    Baskaran

  • Update: took out most of my printf statements in my testing project and we have enumeration, but only in Windows 7!?  Still a ways to go...  (Aside: learned the hard way that printf statements are costly on an embedded system...)

    In other words, I am getting worse results in XP than in 7..

    Windows 7 x64 USB host

    • Summary: board enumerates correctly as USB device but does not start?
    • Device Manager: USB\VID_1CBE&PID_0003 [which is correct - see StarterWare's usb_bulk_structs.c and usb-ids.h)
    • As per source code comments,installed SW-USB-windrivers (just WinUSB + custom inf) from http://www.luminarymicro.com/products/software_updates.html, with the following results.
    • Device Manager: This device cannot start. (Code 10)
      Details > Install Error: There is no driver selected for the device information set or element. E0000203
    • Using my own inf file and packaging it as a textbook WinUSB driver (results forthcoming): "This device cannot start. (Code 10)"

    Windows XP x86 USB hosts (same result for 2 separate computers, as well as vmware player + xp mode)

    • Summary: board does not enumerate correctly
    • System tray: USB Device Not Recognized
    • Device Manager > General: No drivers are installed for this device.
    • Device Manager > Device Instance Id: USB\VID_0000&PID_0000\1
    • Device Manager > Hardware Ids: USB\UNKNOWN

    The Windows driver is Microsoft's WinUSB in both cases and the inf file looks fine (except maybe lmusbdll, which isn't part of a standard WinUSB driver? a textbook WinUSB driver didn't help in win7, and in any case the xp enumeration issue is not solved at all).

    Ubuntu 10.04 x86 USB host via VMware Player 3.1.2: Linux crashes outright, haha, but at least no blue screen on my windows vm host

    Dear Baskaran:

    With a Windows XP USB host, here are the results:

    • System tray: USB Device Not Recognized
    • Device Manager > General: No drivers are installed for this device.
    • Device Manager > Device Instance Id: USB\VID_0000&PID_0000\5&951D826&0&1
    • Device Manager > Hardware Ids: USB\UNKNOWN

    I am using a Spectrum Digital AM1707 EVM Rev. H.

    With a Windows 7 USB host, the results are the same, except in Device Manager > General there is a different error message: "Windows has stopped this device because it has reported problems. (Code 43)"

    Thanks!
    Jonathan

    usb_bulk_dev_evmam1707_20120119.zip
  • i understood that you are using CCS for this experiment. Since CCS (tms470) has not supported unaligned access on AM1808 we have not provided CCS support for USB and ethernet applications (for AM1808).

    Please check is CCS (tms470) supports unaligned access for AM17x. May be this causes the data to be transmitted wrongly.

  • Do the latest StarterWare release notes indicate that this issue has been fixed in CCSv5?  It's not entirely clear..

    How would I check this myself?  I am running CCS 5.1.0.09000

  • Chen,

                The known issues and limitations sections mentions the IR (SDOCM00080255) which indicates that this issue is not fixed for AM1808. I am not sure if this is fixed for AM17x.

    you can try simple expreiment: type cast unaligned address to int data type and see if it is not giving exception.

    Regards

    Baskaran

     

  • Dear Baskaran,

    Thank you for your continued support!

    Code

    char a[12] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0xa, 0xb};
    char *p;
    int intValue, index;

    for (index = 0; index <= 12-4; index++)
    {
        p = &a[index];
        intValue = *((int*) p);
        printf("*( &a[%d] ) = 0x%x\n", index, intValue);
    }

    Result (for both CCS 4.1.3.00034 [cl470 v4.6.3] + 5.1.0.09000 [cl470 v4.9.1] on EVMAM1707)

    *( &a[0] ) = 0x3020100
    *( &a[1] ) = 0x30201
    *( &a[2] ) = 0x1000302
    *( &a[3] ) = 0x2010003
    *( &a[4] ) = 0x7060504
    *( &a[5] ) = 0x4070605
    *( &a[6] ) = 0x5040706
    *( &a[7] ) = 0x6050407
    *( &a[8] ) = 0xb0a0908

    So I guess this means unaligned memory access is not supported?  Is this what you meant by exception?  Sorry if I did not understand correctly..

    Question, though: isn't "__attribute__ ((packed))" CCS 5.1.0.09000 () for AM1x?  cf. usblib.h in StarterWare AM1808 01.00.02.02

    Thank you!
    Jonathan

  • "Is this what you meant by exception? " - if the unaligned exception is enabled you would have got exception. Since you have not enabled the exception, you just getting the data wrongly.

    In usblib.h the packed attribute is applied for ARM architecture V7 only. ARM 9 which is used in AM1808 is v5 architecture. So the packed attribute here will not be applicable for AM1x.


    For any new issues i would suggest you to open a new thread. In this thread itself we have discussed lot of issues and the thread has grown too big.

  • Thank you, Baskaran!  If any new issues arise, I will create a new thread; the rest of this post follows up on the previous issue of memory alignment.

    You are right--enabling the ARM core's unaligned exception in CCSv5, the board winds up in AbortHandler.  Code is posted below because I had to look up how to do this..

    char a[12] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0xa, 0xb};
    char *p;
    int intValue, index;

    // enable "Data address alignment fault checking"
    asm("    mrc p15, #0, r0, c1, c0, #0\n\t"
        "    orr r0, r0, #0x00000002\n\t"
        "    mcr p15, #0, r0, c1, c0, #0\n\t");

    index = 0;
    p = &a[index];
    intValue = *((int*) p);

    index = 1;
    p = &a[index];
    intValue = *((int*) p); // set breakpoint here and (assembly) step into abort handler.

    References
    ARM926EJ-S Technical Reference Manual
    am1808_starterware/system_config/armv5/cgt/cp15.c: CP15MMUEnable()

  • Attached is a successful port of the usb_bulk_dev example to AM1707!

    It has been confirmed to work with the following setup:

    • StarterWare AM1808 1.00.02.02 code base
    • Spectrum Digital AM1707 EVM Rev. H
    • Code Composer Studio 5.1.0.09000
    • CodeSourcery (gcc) toolchain 2009q3-68***
    • CodeSourcery (gcc) toolchain 2011.09-69 - with additional compiler flag -fno-zero-initialized-in-bss
    • GNU ARM Eclipse plug-in 0.5.4.201112030833
    • USB host (PC) driver v6459 + application v8264 from here (SW-USB)
    • Windows USB host (XP and 7 x64 both confirmed)
    • AISgen for D800K003 version 0.7.0.0 (for generating bootable image to flash to the board)

    ***Please note that other compilers did not work - including older and newer (as of this writing) versions of CodeSourcery, as well as TI's tms470 code generation tools (i.e., the built-in compiler bundled with CCS).


    Recipe (from scratch)

    1. Install CodeSourcery 2009q3 (gcc) compiler
      - it MUST be this version, as of this writing
      - 2009q1 and older: usb_bulk_dev breaks (works from CCS debugger, but not SPI boot)
      - 2010 and newer: usb_bulk_dev gives USB\UNKNOWN, and uart borks out
      - 2010 and newer: should work correctly with additional compiler flag -fno-zero-initialized-in-bss (tested in 2011.09 only)
    2. Install Code Composer Studio 5 (tested with 5.1.0.09000)
    3. Install GNU ARM Eclipse plug-in (tested with 0.5.4.201112030833)
    4. add StarterWare library + usb_bulk_dev example files to project (a pretty long list - see bottom of this post, or _manifest.txt in zip attachment)
    5. apply uartEcho fixes as needed
    6. fix trivial compile/link errors
      - one nice way is to tweak hw_usb.h
          #elif !defined(SOC_USB_0_BASE)
          #include "psc.h"
          #include "soc_AM1808.h"
          #include "hw_psc_AM1808.h"
          #include "hw_usbphyGS60.h"
          #include "hw_usbOtg_AM1808.h"
      - need to #define sourcerygxx to get the "packed" #ifdef to compile (I did this lazily in the CCS project)
    7. usbphyGS60.c/USBPhyOn() - several modifications.
      - clear CFGCHIP2[USB0OTGMODE] register bits (evmam1707.gel oversight that forces USB host)
      - set CFGCHIP2[USB0DATPOL] register bit (evmam1707.gel ERROR for board Rev. G and newer)
      - meh, for standalone boot, just clobber CFGCHIP2 = 0x00001972
          - evmam1707.gel: CFGCHIP2 = 0x3872 @ startup
          - standalone boot: CFGCHIP2 = 0xEF00 @ startup (spruh94a.pdf)
    8. other tweaks
      - do NOT (UART)printf during interrupts! timing will mess up completely.
      - (optional?) usbdenum.c/USBDCDInit(): clear POWER/HSEN bit! this disables high-speed usb.
      - (optional?) usbdenum.c/USBDCDInit(): silicon advisory 2.0.4 (sprz311a.pdf)
      - (optional?) usbdbulk.c : call InternalUSBRegisterTickHandler AFTER USBDCDInit??
    9. pc-side driver + test application at http://www.luminarymicro.com/products/software_updates.html
      SW-USB-windrivers + SW-USB-win, respectively

     --------
    |Includes|
     --------

    include/debug.h
    include/delay.h
    include/psc.h
    include/timer.h
    include/uart.h
    include/uartStdio.h
    include/usb.h
    include/hw/hw_aintc.h
    include/hw/hw_psc_AM1808.h
    include/hw/hw_uart.h
    include/hw/hw_usb.h
    include/hw/hw_usbOtg_AM1808.h
    include/hw/hw_usbphyGS60.h
    include/hw/hw_tmr.h
    include/hw/hw_types.h
    include/hw/soc_AM1808.h
    include/armv5/cpu.h
    include/armv5/am1808/evmAM1808.h
    include/armv5/am1808/interrupt.h

    usblib/include/usblib.h
    usblib/include/usb-ids.h
    usblib/include/usbdevice.h
    usblib/include/usbdbulk.h
    usblib/include/usblibpriv.h
    usblib/include/usbdcomp.h
    usblib/include/usbdevicepriv.h


    Ported by hand to AM1707
    ------------------------
    include/hw_syscfg0_AM1808.h - ported to hw_syscfg_AM1707.h using PinSetup.exe + spruh94a.pdf


    ==================================================================================================

     --------
    | Source |
     --------

    Files from AM1808 StarterWare
    -----------------------------
    examples/evmAM1808/usb_dev_bulk/usb_bulk_structs.c
    examples/evmAM1808/usb_dev_bulk/usb_bulk_structs.h
    examples/evmAM1808/usb_dev_bulk/usb_dev_bulk.c - COMMENTED OUT all graphics code!!
    examples/evmAM1808/usb_dev_bulk/ustdlib.c
    examples/evmAM1808/usb_dev_bulk/ustdlib.h

    utils/delay.c
    utils/uartStdio.c

    usblib/usbbuffer.c
    usblib/usbdesc.c
    usblib/usbringbuf.c
    usblib/usbtick.c
    usblib/device/usbdbulk.c
    usblib/device/usbdconfig.c
    usblib/device/usbdenum.c
    usblib/device/usbdcdesc.c
    usblib/device/usbdhandler.c

    drivers/psc.c
    drivers/timer.c
    drivers/uart.c
    drivers/usbphyGS60.c
    drivers/usb.c

    platform/evmAM1808/uartConsole.c
    platform/evmAM1808/usb.c - as usb_platform.c
    platform/evmAM1808/syscfg.c
    platform/evmAM1808/sysdelay.c

    system_config/armv5/gcc/cpu.c
    system_config/armv5/gcc/init.S
    system_config/armv5/am1808/interrupt.c
    system_config/armv5/am1808/startup.c
    system_config/armv5/am1808/gcc/exceptionhandler.S

    build/armv5/gcc/am1808/evmAM1808/usb_dev_bulk/usb_dev_bulk.lds


    Ported to AM1707
    ----------------
    platform/evmAM1808/uart.c - rewritten as uart_platform.c using new syscfg/pinmux header


    gcc_usb_bulk_dev_am1707.zip
  • Thanks for sharing your experience. I am sure it will help others.

  • With all the help I've received on these forums, it's the least I could do!

  • Hi Jonathan Chen,

    I am trying  USB_DEV_BULK project from OMAPL138_StarterWare_1_10_03_03 on TMDXLCDK138 (OMAP-L138 Development Kit (LCDK)).

    The Development Kit  was detect at host PC as unknown devjice.

    1. May I know how to fix this  USB_DEV_BULK error?

    2. I also install CodeSourcery 2009q3 (gcc) compiler as suggested by you. What need to set at CCS5.1 so that to use the compiler?

    3. I have downloaded GNU ARM Eclipse plug-in (org.eclipse.cdt.cross.arm.gnu_0.5.4.201202210114.zip). May I know how to install it and use it at CCS5.1?

    The detail of my set up is below:

     

    1. Eval kit model :TMDXLCDK138 ( OMAP-L138 Development Kit (LCDK) ).

    2. Starterware version :OMAPL138_StarterWare_1_10_03_03

    3. OS : Win XP SP3

    4. CCS Version : 5.1.0.09000

    5. Gel file use for target for both DSP and ARM processor : OMAP-L138_LCDK.gel

    6. Starterware project file name: usb_dev_bulk_armv5_omapl138_lcdkOMAPL138

  • Hi, Hock Leong Ang,
    2. and 3. It's been a while; sorry if the following procedure is wrong...
    - Install plugin in CCS as described at <http://gnuarmeclipse.livius.net/wiki/Plug-in_installation>
    - Create a new Code Sourcery (gcc?) project and add your firmware files
    - Compile and debug as usual
    1. Sorry, there are too many possibilities, and both my hardware and firmware are different from yours (AM1707 processor, "custom" StarterWare). 

    I can tell you what was wrong with the AM1707 board: there was a wrong bit in the gel file - specifically, register CFGCHIP2, bit USB0DATPOL (it was supposed to be 1, but manufacturer Spectrum Digital set it to 0, and refused to admit they were wrong... at least their hardware schematics weren't wrong!). Maybe this will give you one idea where to start... But since your gel file, hardware, and firmware are all different, so you will probably have to look at all 3 yourself...

    Please start a new thread, since this thread was specific to AM1707 + Starterware.  These forums are very helpful, and I am confident that someone will be able to help you!
    Hope this helps,
    Jonathan
  • Hi Jonathan,

    After Install CodeSourcery GCC and CYGWin GCC, USB bulk is enumeration successfully

    Verification of USB bulk:

    Install program from http://www.ti.com/tool/sw-usb-win, execute usb_bulk_example.exe program from C:\Program Files\Texas Instruments\Stellaris\usb_examples.

    When key in x byte data in data entry, the x byte is written into device and later the x byte was read from device.

    The counter at LCD for Write and Read back also correct.

    Thus, the data transfer of USB Bulk is working fine with verification software.

    • Overall:

     This meant that USB bulk is able to connect to host PC and transfer in and out data file correctly.

    Thank you very much.

  • Hi,

    I have adapted y used the source code of "sw_am17x" to control the HCUSB 1.1 Interrupts. I can compile my aplication with no errors, but when I run it, a "Segmentation Fault" message is printed  in the console. I have debugged it using gdb, and this fault occurs in the next call to HWREG macro:

    HWREG(SOC_AINTC_0_REGS + AINTC_ECR(cnt)) = AINTC_ECR_DISABLE;

    The application runs over a Linux 3.3 embedded in a OMAP L 137, which ARM core is identical to the AM1707 and the register addesses are the same.

    How could I solve this problem? Any idea?