am17x support?

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

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)

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

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!!!

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)
  
  

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

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