OMAP-L137 ARM Interrupts

Found a bit more information.  Seems the CPSR FIQ/IRQ bits are not changing unless I force it with JTAG.  Once force I'm at least getting an FIQ interrupt.  Code is:

At init cpsr is 0x200000D0, all disabled

 #define portDISABLE_INTERRUPTS()           \
  asm volatile (               \
   "\tSTMDB SP!, {R0}  \n\t" /* Push R0.      */ \
   "MRS R0, cpsr  \n\t" /* Get CPSR.     */ \
   "ORR R0, R0, #0xC0 \n\t" /* Disable IRQ, FIQ.   */ \
   "MSR cpsr_c, R0  \n\t" /* Write back modified value. */ \
   "LDMIA SP!, {R0}   " ); /* Pop R0.      */
   
 #define portENABLE_INTERRUPTS()            \
  asm volatile (               \
   "\tSTMDB SP!, {R0}  \n\t" /* Push R0.      */ \
   "MRS R0, cpsr  \n\t" /* Get CPSR.     */ \
   "BIC R0, R0, #0xC0 \n\t" /* Enable IRQ, FIQ.    */ \
   "MSR cpsr_c, R0  \n\t" /* Write back modified value. */ \
   "LDMIA SP!, {R0}   " ); /* Pop R0.      */

Also tried the _disable_interrupts()/_enable_interrupts() inline code from the rts library and it is similiar.  R0 has correct value, just cpsr not taking the update.

Kev

Dumb, should have seen this but too much hacking...  RTS library puts you in user mode and must be priviliged to change CPSR.  Modified after SWI and is fine now...  Now on to timer tick code.  If anyone knows any sample code for OMAP-L137 in this regard please let me know, attempting to port an open source OS since not alot of support for 137 yet.

Thanks,

Kev

Resolved all the problems and have operational, along with port of preemptive OS FreeRTOS running a couple of threads.  For the next person that has to deal with this there seems to be only one way to clear a timer interrupt.  After servicing the AINTC you have to write a 1 to the status bit in the INTCLSTAT of the timer or the interrupt in the timer will not clear.  Makes sense but not documented anywhere that I could find and accidently discovered when at the verge of giving up and was poking around with JTAG.  Basically when in periodic timer mode you will get the first interrupt but when you re-arm the AINTC (SICR) no more will occur and the interrupt status bit in INTCLSTAT stays stuck.  Easiest thing to do is read INTCLSTAT and write it back.  May have to mask off the other timer channel if unchained but if in pulse mode probably don't have to as the AINTC should already have it latched.  Something left to be tested...

Kev

Sorry to join this so late.  I'm also looking to use FreeRTOS... are you planning on rolling your changes into the freeRTOS repos somewhere, or should I plan on recreating it?

~JM

Kevin,

Thanks for all the info!  I certainly won't turn down a preliminary copy if it isn't too much trouble.  I do agree that even a stripped down linux is probably a bit much for many applications.  Although it does have the draw of easier development.  I think there is a need for supporting both types of OS.  My immediate project needs a network stack so I was planning on porting something to work on freeRTOS as well.  i was tossed up between NDK which seems tailored to the DSP but is probably smaller and less standard, and the linux driver which is tailor to linux/arm and is probably bigger than is needed.   I think a nice goal would be to port/wrap NDK to uIP, that would make the API the most compatible with the standard  freeRTOS stack.

Thoughts?

~JM

JM,

Assuming I have no fires to deal with in the morning I'll see if I can do a quick sync and test of the latest FreeRTOS.  Should be able to place something on my company's public ftp server late Tuesday or Weds.  Will let you know.  Due to the snow in the Northeast was working from home today and the demo board is powered off in my office.

I looked at the NDK myself and asked TI if anything had been done with the ARM before.  Kind of knew they hadn't but figured didn't hurt to ask.  In reviewing the source code the port didn't look too bad.  It was either replace the DSP/BIOS calls with FreeRTOS ones or move the hardware interface to another IP stack.  I was going to take a look at the ones distributed with FreeRTOS as well as some other open source ones but haven't had the time.  My current need doesn't require the stack although I have another project that either I would do the port or use Linux.  Preference is currently Linux for other reasons but I have to check the performance, also faster to market if I do my own stack but then functionality limited.  Existing processor being replaced is already an ARM9 that has ThreadX/NetX (we helped alot with the original NetX port) on it but I'm always having to write my own network service protocols.  Linux security, ssl, vpn, etc., is of interest. in our newer project.  

Only reservation I have on using the NDK is it belongs to TI and am sure we can use it for ourselves but can't place it into the open source community for others to use (not that, that is all that important either).  A wrapper could be done if it can be done cleanly since a user would have to go to TI and be licensed by them to get the NDK.

Anyways, you can contact me at my email address, kevin.halloran@ctc-control.com and I'll either email you a zip or you can use my ftp server.

Kev

I was able to sync to the latest FreeRTOS and do some cleanup this morning.  Looks like it still works [*-)].  Until it is available at FreeRTOS.org you can drop me an email.

Kev

Just looked at the freertos repository.  Barry hasn't committed your changes yet.  I'll send you an e-mail!

Thanks again!

~JM

Hi,

I also dont' want an operating system as "heavy" as Linux.

I really want the DSP to be in control the majority of the peripherals (specifically EDMA, INTC and the McASPs), and the ARM to perform some lighter housekeeping tasks (basic protocol stack-like stuff) when required by the DSP.

This seems to be different to the use-case for most of the TI tools for the L137... in which the ARM runs Linux and controls the peripherals and the DSP is bolted on the side to as an accelerator for some of the heavier processing required (nominally audio/video/speech).

So I have a couple of questions:

If I was to opt to use Linux, how many of the peripherals will it attempt to own (the INTC? Timers?).

When are the FreeRTOS changes likely to be folded in an "official" release, as this OS seems like a good match for my use of the ARM?

I'm confident using Code Composer for the DSP code, is it a good idea to try develop the ARM code using Code Composer as well?

Are there any examples of Code Composer projects for the ARM on the L137 (in the form of straight C code)?

And, probably most importantly, where is the documentation for the boot mechanisms for the device as a whole?

I can boot the DSP from a SPI Flash, and I can run programs on both the DSP and ARM using Code Composer... But I haven't been able to find any documentation detailing how to do full boot (i.e. power on -> DSP BootROM -> DSP application -> DSP enables ARM -> ARM BootROM -> ARM application)?

Thanks!

So I have a couple of questions:

If I was to opt to use Linux, how many of the peripherals will it attempt to own (the INTC? Timers?).

>Depends on the drivers loaded.  You can rebuild the kernel to remove some drivers.  Haven't looked at the source for a while but as long as interrupts are not enabled for a particular device you could take control of it from the DSP.  It is too bad that the ARM AINTC registers are not public to the DSP since if it was you could probably disable the interrupt and take control without impacting Linux (driver dependent).  TI may have more specfic information but documentation isn't the best.

When are the FreeRTOS changes likely to be folded in an "official" release, as this OS seems like a good match for my use of the ARM?

>There may never be an "official" release.  There is an initial version which I've created and will be posted at FreeRTOS.org to get people started.  If you would like it in the mean time drop me an email and I'll forward it to you.  It is a code composer ARM project.

I'm confident using Code Composer for the DSP code, is it a good idea to try develop the ARM code using Code Composer as well?

> Probably simpler, especially if using the demo board.  You could use gcc (as linux does) but then would have to deal with setting up the JTAG environment, etc...  Also with demo board/Code Composer can debug both DSP and ARM at same time.  I've run FreeRTOS on one side and some DSP/BIOS samples on the other side.

Are there any examples of Code Composer projects for the ARM on the L137 (in the form of straight C code)?

> FreeRTOS port is only example of real "complete" code that I know of, timer and UART functioning as well as handling interrupts and initialization.  TI has some internal code they used to test the registers but for the most part is DaVinci based and does not utilize everything.  You would have to ask TI Support for access for some of that code as it is not readily available.

And, probably most importantly, where is the documentation for the boot mechanisms for the device as a whole?

>It is ugly and needs some sample code from TI but this may help:  http://focus.ti.com/lit/an/sprab04a/sprab04a.pdf

I can boot the DSP from a SPI Flash, and I can run programs on both the DSP and ARM using Code Composer... But I haven't been able to find any documentation detailing how to do full boot (i.e. power on -> DSP BootROM -> DSP application -> DSP enables ARM -> ARM BootROM -> ARM application)?

>We could definitely use a simple "hello world" from both the DSP and ARM from TI showing this.  In the mean time may be able to figure alot of it out looking at Linux port/UBoot and reading above document.

Kev

For all those interested OMAP-L137 FreeRTOS project is available on SourceForge:

http://freertos.svn.sourceforge.net/viewvc/freertos/trunk/Demo/Unsupported_Demos/

Select the file OMAP_L137_kh.zip

Kev