OMAP-L138: ARM core appliation is not working properly in OMAP-L138

Ashish Maheshwari

Part Number: OMAP-L138
Other Parts Discussed in Thread: TMDSLCDK138,

Dear Team,

We made our own hardware board for our application (not all features of TI's evaluation board) by referring TI’s TMDSLCDK138 evaluation board's BOM and schematic.

TI’s evaluation board version: OMAP-L138/C6748 LCDK-PCB-004 and kit revision number is blank

Ti’s evaluation board schematic and BOM: OMAP-L138 LC DEV KIT VER A7E.pdf and OMAP-L138 LC DEV KIT VER A7E_BOM.xls

One difference in digital section between both boards is that instead of W971GG6KB-25 Winbond SDRAM (as it get obsolete) we used IS43DR16640B-25DBLI ISIS SDRAM

Now we are facing one serious issue regarding the operation of ARM core in our own board.

Our ARM application is not working properly with 300 Mhz processor speed and 150 Mhz for DDR2 (SDRAM) of OMAP-L138 in our board. Program hangs after some time. So to find the exact issue we drilled down our code to read only RTC time.

We run the program (program logic is mentioned below) independently on each processor of OMAP-L138 at a time at 300 Mhz processor speed and 150 Mhz for DDR2 (SDRAM) and found the following results

ON OUR BOARD:

a) ARM: When we run in ARM core we found that RTC time ‘second’ gets missed and ‘LED’ glows after 4-5 minutes. After every 2-4 minute interval the 'second' missed happens. We ran it for 40 minutes.

b) DSP: When we run in DSP core we found that program is working fine and no RTC time ‘second’ gets missed. We ran it for 40 minutes.

ON TI’s EVAL BOARD:

c) ARM: When we run in ARM core we found that program is working fine and no RTC time ‘second’ gets missed. We ran it for 40 minutes.

d) DSP: When we run in DSP core we found that program is working fine and no RTC time ‘second’ gets missed. We ran it for 40 minutes.

NOTE: Then we reduce the DDR2(SDRAM) speed to 102 Mhz instead of 150 Mhz and 300 Mhz processor speed in ARM core and run the RTC program and found that the program is working fine. We ran it for 40 minutes

Our final goal is to run both the processor (ARM and DSP) of OMAP-L138 at full speed i.e. 456Mhz processor speed and 150Mhz DDR2 (SDRAM) speed

Program logic: RTC Access only, (We are using Non-Os program)

In this program we set the RTC on interrupt mode and in interrupt we clear interrupt flag and set one flag.

We check the flag in main and perform following operations

a) Read the RTC time ‘second’ parameter

b) Take the difference between current ‘second’ and previous saved 'second'

c) If difference is >1 second means ‘second’ has skipped then glow ‘LED’ to indicate error and increment the 'second' skipped counter

d) Save the current ‘second’ value

Please suggest solution as this is very urgent

Thanks in advance

Ashish

over 7 years ago

0 Cvetolin Shulev-XID over 7 years ago

TI__Guru 65405 points

The team is notified. They will post their feedback directly here.

BR
Tsvetolin Shulev

0 Mark M over 7 years ago

TI__Mastermind 30380 points

HI Ashish,

Sorry for the delay, did you find a solution to this problem?

Have you extensively tested the DDR2 at the higher clock speeds? DDR2 issues can cause system to hang.
PCB routing is often the cause of DDR2 issues, especially at higher speeds.

Regards,
Mark

0 Ashish Maheshwari over 7 years ago in reply to Mark M

Intellectual 670 points

Hello Mark,

Thanks for your reply

No, we couldn't find the solution to this problem

To test the DDR2, we wrote one program which write and read byte to all the locations of SDRAM and ran the program on each core independently and found that write and read is successful in both the cores

Please tell us that if there is any other method to test the DDR2

Regards,

Ashish

0 Mark M over 7 years ago in reply to Ashish Maheshwari

TI__Mastermind 30380 points

Sorry again for the delay.

DDR can be stress tested by writing specific patterns as fast as possible. Hotter temperatures also stress it.

Does your RTC program use DDR at all?
You say no OS is used, so does your linker place any objects into DDR memory region?

Can you disable the DDR and see if the RTC error occurs?
I wonder if there is noise from the DDR coupling into the RTC somehow (power, clock coupling, or ground bounce).

Let me ask around about DDR and RTC on this device.

Regards,
Mark

0 Ashish Maheshwari over 7 years ago in reply to Mark M

Intellectual 670 points

Hello Mark,
Thanks for your reply

Will you please tell us which pattern to write, we wrote 0xAA to SDRAM at all the location in a sequential manner,

MARK: Does your RTC program use DDR at all?
Yes, our complete code is executed from DDR2 as we have mentioned .text, .data and other components from DDR2 in .cmd file

MARK: Can you disable the DDR and see if the RTC error occurs?
Please let me know how can we disable DDR2

MARK: I wonder if there is noise from the DDR coupling into the RTC somehow (power, clock coupling, or ground bounce)
Please tell how can we test your above statement

Regards,
Ashish

0 Mark M over 7 years ago in reply to Ashish Maheshwari

TI__Mastermind 30380 points

Hi Ashish,

Ashish Maheshwari said:

Will you please tell us which pattern to write, we wrote 0xAA to SDRAM at all the location in a sequential manner,

The old starterware software: http://www.ti.com/tool/starterware-dsparm

I found an old DDR_STRESS_TEST project in starterware_01_08_01_24 that writes 0x1FFFFFFFU words with four stres tests. It writes 0x55, then 0xAA, then 0x55 again, and then 0x55+index into these words. It uses the DMA to push the data in and out as fast as possible.

I'm not sure where you can still download this old version. I'm asking about it.

Starterware is no longer being developed, but you can find the latest version here (without this stress test): http://processors.wiki.ti.com/index.php/StarterWare

=-=-=-=-

Ashish Maheshwari said:

MARK: Does your RTC program use DDR at all?

Yes, our complete code is executed from DDR2 as we have mentioned .text, .data and other components from DDR2 in .cmd file

Can you try running the same code from internal RAM? And then skip the init of DDR to isolate whether the issue is with RTC or DDR. As a second step, keep the program runing from internal RAM and initialize DDR to see if the DDR is causing noise on the RTC. If the program only fails when run from DDR, then it points a finger at the DDR stability. Test the full DDR space by running a stress test (from internal memory) on the DDR. Write to and Read from DDR. Repeat the read a few times to check for stability.

Internal memory in the .cmd file should be like this...

IRAM_MEM : org = 0x40300000, len = 0x1C000 /* RAM 0x1FBFF*/

=-=-=-=-

Ashish Maheshwari said:

MARK: Can you disable the DDR and see if the RTC error occurs?

Please let me know how can we disable DDR2

Do not place any sections in DDR space in the .cmd file. Do not initialize DDR. Run the RTC test and see if it still has the issue with ARM core.

=-=-=-=-

Ashish Maheshwari said:

MARK: I wonder if there is noise from the DDR coupling into the RTC somehow (power, clock coupling, or ground bounce)

Please tell how can we test your above statement

To see the noise, you would have to probe the RTC power supplies and crystal signals with and without DDR enabled, using active probes to capture any noise or crosstalk or ground bounce.

Alternately, you can disable DDR and run the RTC test from ARM to verify RTC operates without DDR running. And you can also run a non-RTC based test running from the DDR at 102MHz and 150MHz to isolate whether the issue is with RTC or with DDR.

Hope this helps, and sorry for the delay,
Mark

0 Ashish Maheshwari over 7 years ago in reply to Mark M

Intellectual 670 points

Dear Mark,
Thanks for your reply

I will try your mentioned tests when i will get time as i am busy in some other tasks and get back to you with the results

I had tried the same RTC program at 102 Mhz DDR speed and processor speed at 300 Mhz and found it is working fine

Regards,
Ashish

Processors

Processors forum

OMAP-L138: ARM core appliation is not working properly in OMAP-L138