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!
StarterWare support is not available for AM17x. For the list of supported Socs please refer http://processors.wiki.ti.com/index.php/StarterWare.
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!
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
Thanks and regards,
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.
- 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)
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"
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)
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 ?
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
2. (in 1. above) added StarterWare's system_config/armv5/am1808/startup.c to project, with minimal changes to allow compile
3. added to project system_config/armv5/am1808/cgt/exceptionhandler.asm
4. Finally, there are remaining linker errors: unresolved symbol _SysCfg RegistersLock, first referenced in ./startup.obj
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!!
Update (2013-04-15): fixed some silly errors in tests/uart_sw/uart/.project and updated the included readme file.
My build/system configuration:
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 farThe StarterWare AM1808 uartEcho example can be ported to AM1707 through the following steps:
In response to Madhvapathi Sriram on potential issues for porting from AM1808 to AM17x:
Some preliminary work on usb_bulk_dev.
Current status when USB0 is connected to a Windows 7 PC:
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():
I'm especially unsure about step 2, but it seems to get results? Arguments for/against swapping D+/D-:
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 .
We have not tested with windows 7. it would take some time for us to check this. Can you try with windows XP?
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
Windows XP x86 USB hosts (same result for 2 separate computers, as well as vmware player + xp mode)
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
With a Windows XP USB host, here are the results:
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)"
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
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.