PICkit 2 again with HPS stack

Hans Petter Selasky hselasky at c2i.net
Tue Oct 16 09:43:56 PDT 2007


On Tuesday 16 October 2007, Xiaofan Chen wrote:
> On 10/16/07, Hans Petter Selasky <hselasky at c2i.net> wrote:
> > On Saturday 13 October 2007, Xiaofan Chen wrote:
> > > On 10/13/07, Hans Petter Selasky <hselasky at c2i.net> wrote:
> > > > Resource temporarily unavailable maps to EAGAIN
> > > > according to "man errno". From what I can see from the log
> > > > you have provided this means that the "msleep()"
> > > > call in "ugenread" timed out.
> > > >
> > > > What timeout have you programmed in your PICkit ?
> > >
> > > It is 1000ms. I change it to 10000ms but this does not help.
> >
> > Do you see this timeout ? Does the code actually wait 10 seconds ?
>
> I think so.
>
> > In the file "ugen.c" in the function "ugen_open_pipe_read()" you will
> > find a "case UE_INTERRUPT:". Some lines further down you will find:
> >
> >                   /* first transfer clears stall */
> >                   sce->read_stall = 1;
> >
> > This you can set to "0". Then recompile and install the "ugen" module
> > and/or kernel.
> >
> > Does your USB hardware work now ?
>
> Yes with the changes, PICkit 2 is happy again under Linux.
>
> ===[mcuee] ~/Desktop/build/mypk2 # sudo python testpk2.py
> set Configuration 1
> claim Interface 0
> Turing power on by USB interrupt write
> Sending version command by USB interrupt write
> Getting version command by USB interrupt read
> (2, 10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
>

Hi,

> Thanks a lot. So it seems there is still a bug in the firmware. Maybe two.
> The first one caused the stall (why?).

I think that the clear-stall command will flush the FIFO of the interrupt 
endpoint.

Is it possible that you can open the interrupt endpoint which is a 
file, /dev/ugenX.X, before sending the version command ? So that we don't end 
up clearing the stall after sending the command, but before.

> The second one is still related to 
> dealing with clear stall feature request. Right?

Yes.

--HPS


More information about the freebsd-usb mailing list