[Gumstix-users] R: SPI repeated messages on Overo

[Federico B. <fed...@da...>]

Thank you for your reply, I'll contact them.

Just a note: it is not 25Hz, but 75Hz. Indeed 6ms are 150Mhz, so a square
wave on GPIO is half a period and is 75Hz.

I cut off everything not needed in my code, and I still am experiencing the
same problem, even without stress loading with dd. I just have to wait a
little longer.

If someone is interested into it, I can post it here (less than 200 code
lines).


--
Federico Belvisi



> -----Messaggio originale-----
> Da: Ned Forrester [mailto:nfo...@wh...]
> Inviato: venerdì 12 novembre 2010 15:55
> A: General mailing list for gumstix users.
> Cc: Federico Belvisi
> Oggetto: Re: [Gumstix-users] SPI repeated messages on Overo
> 
> You might want to post your question to:
> 
> spi...@li...
> 
> That is where the SPI developers discuss drivers.
> 
> As long as you are sure that your protocol driver is only sending one
> (or a few) spi_async requests each 6ms, then I agree that it sounds
> like
> this might be a controller driver bug.  I don't use OMAP, so I can't
> help with that.
> 
> On 11/12/2010 09:31 AM, Federico Belvisi wrote:
> > Hello all,
> >
> >
> >
> > I am developing a kernel driver for ltc244x AD series. It is an spi
> driver.
> > During developing, I think I've found a bug in omap spi driver.
> >
> > My driver is  quite simple. In probe function I start an hrtimer.
> Every 6ms
> > (more or less) "timer.function" is called (I restart hrtimer using
> > hrtimer_forward_now() in my timer.function). This function
> sends/receives 4
> > bytes via spi_async call. My "complete" function reads rx_buffer and
> > elaborates. I have an irq function but as of now I disabled it. I
> simply
> > want to have a constant time between spi reads (sort of, I know this
> is not
> > real time etc.).
> >
> >
> >
> > When I insert module, everything works fine. Communication is going
> on, with
> > 6ms (varying) between messages. My messages last 51us each one. I
> have an
> > SPI sniffer connected to my Chestnut 40 pin header and I can see spi
> > messages.
> >
> >
> >
> > I run some "dd if=/dev/urandom of=/dev/null" via ssh (2 different
> ssh) to
> > stess-test the hardware during SPI communication. The problem
> manifests
> > itself after some minutes: SPI starts sending messages without delay.
> This
> > generates too much traffic on SPI and definitely hangs down my Overo.
> I
> > double checked my code, I added in my "timer.function" call (which is
> the
> > one called every 6ms) a simple gpio (147, for the records) switching.
> > Oscilloscope shows 25Hz steady on that pin, so my function is called
> > correctly at that frequency. On spi sniffer messages arrives with no
> delay.
> > Every 52us a repeated message is sent.
> >
> >
> >
> > I am pretty sure that they are repeated messages because usually the
> first
> > byte my driver sends in every message is cycling between 0xA0, 0xA1,
> 0xA2,
> > 0xA3. When I have the error condition, the same message (for example
> 0xA0)
> > is repeated many times, in fact it is repeated between timer.function
> (which
> > is still called at 25Hz). After that, it switches to 0xA1 and goes on
> > repeating itself.
> >
> >
> >
> > I'm no kernel expert, but seems that the problem is not hrtimers
> related.
> >
> >
> >
> > I am running kernel 2.6.33 from Sakoman git, using OE. I tried
> omap2_mcspi.c
> > from head (2.6.37-rc1?) but the problem is still here. Maybe it is
> related
> > with
> >
> >  https://github.com/scottellis/overo-adc-mcp3002 cleanup null ref.
> >
> >
> >
> > Is there some of you who has already seen this problem or knows a
> solution?
> >
> >
> >
> > After a minute with spi rushing, this message appears on console:
> >
> >
> >
> > BUG: soft lockup - CPU#0 stuck for 61s! [omap2_mcspi:11]
> >
> > Modules linked in: ltc244x
> >
> >
> >
> > Pid: 11, comm:          omap2_mcspi
> >
> > CPU: 0    Not tainted  (2.6.33 #2)
> >
> > PC is at mcspi_wait_for_reg_bit+0x40/0x58
> >
> > LR is at msecs_to_jiffies+0x20/0x28
> >
> > pc : [<c0265d78>]    lr : [<c0064368>]    psr: 20000013
> >
> > sp : cf93bf00  ip : 00000000  fp : fa09804c
> >
> > r10: fa098044  r9 : fa098050  r8 : ced44c43
> >
> > r7 : fa098044  r6 : 00000001  r5 : c056eb20  r4 : 0000a2c0
> >
> > r3 : 00000002  r2 : 00000064  r1 : 00000028  r0 : 0000a324
> >
> > Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> >
> > Control: 10c5387d  Table: 8ed38019  DAC: 00000017
> >
> > Missed ticks 8
> >
> >
> >
> >
> >
> > --
> >
> > Federico Belvisi
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> ---------
> > Centralized Desktop Delivery: Dell and VMware Reference Architecture
> > Simplifying enterprise desktop deployment and management using
> > Dell EqualLogic storage and VMware View: A highly scalable, end-to-
> end
> > client virtualization framework. Read more!
> > http://p.sf.net/sfu/dell-eql-dev2dev
> >
> >
> >
> > _______________________________________________
> > gumstix-users mailing list
> > gum...@li...
> > https://lists.sourceforge.net/lists/listinfo/gumstix-users
> 
> 
> --
> Ned Forrester                                       nfo...@wh...
> Oceanographic Systems Lab       508-289-2226 Office / 774-392-5352 Cell
> Applied Ocean Physics and Engineering Dept.
> Woods Hole Oceanographic Institution          Woods Hole, MA 02543, USA
> http://www.whoi.edu/
> http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
> http://www.whoi.edu/hpb/Site.do?id=1532