IMX6S clock halts for 24 minutes

[b_de_nooij]

Hello all,

we are developing an embedded system around a technexion EDM board based on the IMX6s processor.

http://www.technexion.com/index.php/products/edm/edm-som/edm1-cf-imx6

We use this module with an lvds screen, 2 uarts (1 for console, 1 for serial touch), spi1 and spi2

Using yocto 1.5 and a slightly modified wandboard-solo environment, we created a system with kernel 3.0.35

Now we observe some strange behavior. At very random times (say once or twice every week), the system 'hangs', there is no communication over the spi buses and the screen is not updated)

After 24 minutes (always 24), the system resumes as if nothing happened and the system clock at this point is 24 minutes behind. (i.o.w. it has been halted for 24 minutes)

It has also been observed that using the serial touchscreen (connected to /dev/ttymxc1) "awakens" the system when it is in it's 24 minute sleep period.

It looks like the CPU is in some kind of WFI mode, but I am unable to confirm this.

So far we have been unsuccessful in reliably reproducing the issue or even increase the frequency of it's occurrence.

I am wondering if the issue mentioned here:iMX6 / v3.0.35 / system hang-up problem could be related, but I am not sure.

We are testing the new kernel (3.10.17) now, but I would like to know the root cause of the observed problem.

Does anyone have a clue?

Het bericht is bewerkt door: Bastiaan de Nooij

After migrating to the 3.10.17 kernel, the problem no longer occurs....

[CommunityBot · Accepted solution]

This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

[federicoloda]

We are working with kernel Linux3.0.35-4.1.0 + xenomai 2.6.4 on ARM Imx6s and weare facing a very similar problem: at random time the user interface locks and also the main thread slow down (we can see our watchdog under main thread expiring). 

We go deeply and we found the date command and hwclock command (made with serial console) returns two different times. The system date follow the hwclock for about 10~20 minutes then the system date switch back again (we don't know if at the same as before)

We notice also the command "cat /proc/timer_list" give back all next_events was scheduled in the past

Timer List Version: v0.6
HRTIMER_MAX_CLOCK_BASES: 3
now at 105225868014163 nsecs

.......

active timers:
 #0: <80d05e60>, tick_sched_timer, S:01
 # expires at 104075730000000-104075730000000 nsecs [in -1150138014163 to -1150138014163 nsecs]
 #1: <8e771a80>, hrtimer_wakeup, S:01
 # expires at 104075736565408-104075736615408 nsecs [in -1150131448755 to -1150131398755 nsecs]
 #2: <8f001a80>, hrtimer_wakeup, S:01
 # expires at 104075764916408-104075764984514 nsecs [in -1150103097755 to -1150103029649 nsecs]
 #3: <8fae9a80>, hrtimer_wakeup, S:01
 # expires at 104077575167741-104077580167738 nsecs [in -1148292846422 to -1148287846425 nsecs]

and together with the system date also the "now" counter flow back periodically

Have someone have an idea about this behaviour ? also in this case the problem can be something like WFI mode ?

[franciscoperez]

Hi, if you experiencing this issues look for this thread:

iMX6 / v3.0.35 / system hang-up problem

And here are my bottom comments about it:

After trying to apply the suggested patch to 3.0.35 kernel we got some issues booting (We are running Android). Looking at the patch on itself it seems that we could get the same effect sending the "enable_wait_mode=off" parameter (sent from u-boot to kernel on the command line).   We went that route and all issues of CPU Stall/Hangs, Clock stopped by minutes etc seems have gone away...

Look for other threads about the effects on disable that parameter to see if it could work for you.  In our case power consumption was not an issue as is not a mobile solution.