CF on PXA270 under WINCE4.1 Hangs when Card Removed

Hello All,

I have seen a rather strange problem and am wondering if anyone else out
there has run into it. I am developing on a PXA270 under WINCE4.1. We use
the PCMCIA slot to allow cusomters to download new software via a CF card.
In the past, it has worked well, and really still does. However, there is
one particular brand of memory card, that seems to work okay on insertion,
but hangs the entire system, when removed.

The display even goes black, almost like its going into suspend.
Reinserting the card, causes everything to come back alive, right where it
left off. I have at least a dozen different CF cards that do work, so of
course my customer will insist on using this cheap one they found that does
not. I am sure most of you out there constantly get hear the same arguement
I do: "well it works on my desktop".

Anyhow, not sure I will solve this other than to tell the customer tough
luck by a different CF card. I did think it was odd behavior though and
wondered if anyone had seen anything similar.

Thanks!

umesh
Mon Aug 28 22:18:45 CDT 2006

hi,
its difficult to say like this but you might like to look into
interrupt thread priority.
but can be some other problem too.
can you check on this ,might help you out.


cheers


authorwjf wrote:
> Hello All,
>
> I have seen a rather strange problem and am wondering if anyone else out
> there has run into it. I am developing on a PXA270 under WINCE4.1. We use
> the PCMCIA slot to allow cusomters to download new software via a CF card.
> In the past, it has worked well, and really still does. However, there is
> one particular brand of memory card, that seems to work okay on insertion,
> but hangs the entire system, when removed.
>
> The display even goes black, almost like its going into suspend.
> Reinserting the card, causes everything to come back alive, right where it
> left off. I have at least a dozen different CF cards that do work, so of
> course my customer will insist on using this cheap one they found that does
> not. I am sure most of you out there constantly get hear the same arguement
> I do: "well it works on my desktop".
>
> Anyhow, not sure I will solve this other than to tell the customer tough
> luck by a different CF card. I did think it was odd behavior though and
> wondered if anyone had seen anything similar.
>
> Thanks!

authorwjf
Wed Aug 30 14:27:02 CDT 2006

Hi All,

Against my objections I am still trying to make this one particular brand of
CF cards not lock up the system when they are removed. I have done enough
debugging to say the problem is not the interrupts or their priority. I see
the OEM handler called for the PCMCIA state change notification on the
troublesome card just like on the working cards.

In fact, comparing a series of trace logs side by side, I see the sequence
is ALMOST identical. The most notable difference is in the structure
returned by PDCardGetSocket and PDCardGetAdapterState. On all the working
cards, the fNotifyEvents member of this structure is 80. On the failing
card, it is 81. Does anyone out there know where the documentation is for
this structure? I see it defined in sockserv.h, but no real explanation as
to what this values mean.

When I remove the card, the driver calls "PDCardReadAttByte" and promptly
freezes my entire platform. I lose everything, even the display.
Reinserting the card causes the system to immediately "thaw", but the trace
log shows the "PDCardReadAttByte" call that was hanging the system does not
complete but rather gets interrupted by the card detect interrupt.

If anyone out there has some experience with cardservices and this driver,
I'd sure appreciate some feedback as to what sounds like a likely culprit in
this case.

Regards!

authorwjf
Wed Aug 30 15:15:02 CDT 2006

As I continue to investigate with a broader range of cards, I am no longer
convinced I see any pattern except that the card that locks the system hangs
on the PDCardReadAttrByte function. I am confused to why cardservices call
this function anyhow since at this point it is clear to the PDD layer anyhow
that the card is not present. But this function is called none the less on
working as well as non-working cards after the card is removed. (It just
doesn't hang but rather returns zero in the case of a working card). Does it
seem like I would risk breaking anything higher up in the chain if I simply
return read data of "0" without actually trying to check the non-present
hardware in this case? I always know in my PDD if the card is not detected
so I could simply check this variable and if the card is not there not bother
trying to actually talk to the hardware.

authorwjf
Thu Aug 31 11:34:03 CDT 2006

Seems for the most part this thread has pretty much been me talking aloud to
myself. Hope that's okay. I seem to have the issue resolved and just wanted
to post the fix in case anyone else has seen this. Perhaps it is something
inherient to our board design and not an issue for anyone else out there but
just the same, I think the fix makes sense.

I am using the PDD code that came with the PXA255 BSP for the PCMCIA/CF
interface. The problem I believe showed up because the particular brand of
CF my customer is using, has some capacitance issues that cause it not to
lower the CF Ready line as promptly as most cards. Regardless, even when
using a good card, I see that cardservices calls PCCardReadAttrByte and
PCCardWriteAttrByte, even when the card is clearly not present. Why in most
cards this simply returns 0 bytes read or written, but on my troublesome card
it hangs the entire OS, I cannot say.

In the file sockpd.h, I went ahead and added a global flag bCardPresent.
Inside of socket.c, within he function PDCardGetSocket, I set this flag to
true or false, depending on whether or not the card is detected. Within the
memory.c file, I added a check to PDCardWriteAttrByte, and
PDCardReadAttrByte, to simply exit (and in the case of ReadAttrByte return
0), if the bCardPresent flag is false.

To me this seems like it should have been part of the original logic in the
first place. Even if the system doesn't lock up, why waste CPU time going
out to the actual hardware device when we should already know its not there.
If anyone out there knows any reason why my changes are a bad idea, I'd
appreciate the feedback. Otherwise, I am going to stamp this one low-fat and
ship it :)