No Access to L4-interconnect peripherie after 45 min

This is very strange behavior....

Are you only referring and working with u-boot? No kernel or other components are involved here? Is it possible for you to share the changes you have made to u-boot?

Actually u-boot doesn't touch the clocks once it has been configured and enabled during boot-up. You may want to check your PRCM register and make sure that registers are intact. You can compare the register before and after this 45mins strange value....

Thanks,

Vaibhav

In this case only u-boot is involved. The problem appeared when i was developing a test-loop to do some tests in a climate cabinet.

I made no changes in the clock settings. I made changes like using UART1 instead UART3 as Debug-Interface, EMIF and GPMC adjustments to our DDR2-RAM and Nand-Flash. I added also some additional functionality which you can call from console but this should have no impact on this.

So this behavior does not occur when you working with the am3517evm?

Thank You

I found something by myself but do not really understand it. Maybe someone can help me with that.

In /cpu/arm_cortexa8/omap3/timer.c there is the function timer_init() which is called during the boot-sequence. There the GPTIMER2 is initialized. An overflow occurs after 45 minutes. So I think this must be the source of my problem.

The strange thing is, the autoreload is activated and the TRG is configured to "no trigger".

As described before not the overflow itself causes a board-hang. The system stops if a make access to NAND-Flash, Ethernet, I2C, sd-card, ...).

Has someone a explanation for this behavior?

Thank You

So the problem occurs only when you use your test-loop, right? You may want to review your test loop before suspecting anything else. Also, I am bit surprises to see that, EVM works fine.

From u-boot perspective, I guess, timer is being used for some delay. And if I remember correctly, once we configure timer we never touch it again.

You can conform whether the issue happens only when timer overflows, reduce the overflow time and see whether you hit the issue earlier (to configured timeout).

Thanks,

Vaibhav

Found the answer!

The GPTIMER2 did not start again after reaching 0xFFFFFFFF. The timer simply stops at 0xFFFFFFFF.

So everytime a function included a udelay() call, the controller was in a endless loop.

This problem has nothing to do with our testroutines! I no, the error did occur not only in our testroutines.

To understand it right, when i set the autoreload bit this does not mean that the timer starts again after reaching 0xFFFFFFFF?

I did not modify this part of u-boot, so i think this must occur when you work with the am3517evm too.

I made a workround which calls timer_init() everytime a 0xFFFFFFFF occurs in udelay().

Thanks

Interesting....

Let me go through Timer code for this, I can not commit anything, as I am quite loaded with other things.

But good to hear that your could able to get workaround for this issue, and now you are completely unblocked.

Thanks,

Vaibhav