Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 05/14/2012 06:13 PM, aubin.rebillat@domain.hid wrote:
> Hi Gilles,
> 
> I've followed your advices and reimplemented the timer management. 
> Now it's an up counter wrapping to 0 on overflow, it uses a match 
> register to trigger the interrupt and it's never disabled.
> 
> I've also cleaned the code : suppressed linux specific calls, move 
> update_tsc to linux handler, etc... as you advised me.
> 
> Then, I tested this with both CONFIG_IPIPE and CONFIG_XENOMAI 
> disabled, and it's working fine.
> I also tested with only CONFIG_XENOMAI disabled and it's still
> working as expected.
> 
> Nevertheless, the issue is still the same. It hangs after starting
> the init program. 
> 
> After investigations, the problem is that __ipipe__mach_set_dec is 
> never called after Xenomai has taken control of the  timer. The last 
> timer update was done in rthal_timer_calibrate and it effectively 
> triggers an interrupt after MAXINT ticks (I've put a printk in the 
> linux timer handler and it's displayed after a few time).
> 
> My problem is that i don't really understand the timer management by
> Xenomai. As i understood each skin has its own timers and Xenomai
> manages to trigger them when expected. But what code is managing the
> linux timer ?
> I'm expecting to probably have errors in my ipipe code that's why i'm
> asking this, to follow the execution and see where it is broken.
> 
> Thank you very much,


If the interrupt triggers only once, it probably means that the timer
needs some acknowledgement that must be put in __ipipe_mach_acktimer.

The code managing Linux timer works and has been validated on all the
port so far. So, the thing probably at fault is the timer management
code in the I-pipe patch. Do not worry for Linux timer interrupt, only
take care of ipipe_mach_set_dec and ipipe_mach_acktimer.

Also, if some timer programming is done in linux timer interrupt, it
should not be done once ipipe_mach_timerstolen is true.

-- 
					    Gilles.