I am in the process of target board hardware/software debugging.
My system uses Au1100 chip and I use Windows CE .NET (4.2).

A lot of peripherals work fine and this is good thing :-)
The problem I have now is I do not see ANY activity on
the PCMCIA bus - actually it is CF in my case...

I drive CF_RESET pin on the card to be LOW and then try to read
"tuples" from ATTRIB area of the CF card with the original BSP
code but I got complete junk data...
I have tapped logic analyzer to several signals: PCE0, PCE1,
ROE, POE, CF_A0-A10 (address bus in CF connector) and several other
signals on the connector side, behind drivers/buffers and I see
nothing happens when I read the card. The only signals change
is RESET, CF_DETECT (when I insert the card) and RDY/-BSY telling
me the CF is ready... then: only silence...

On the software side, I have assigned RESET, CF_DETECT and RDY/-BSY
pins to be driven by GPIO200, GPIO22 and GPIO21 respectively and
I set sys_pinfunc bit 18 to 0 to have PREG, PCE1, PCE2, PWE functions
instead of GPIO207:204 (standard setting for PCMCIA) and also
bit 17 to 1 to have access to GPIO200. I have also verified there
is PCMInitialize function called to fill TLB with three 16M-byte
large virtual memory pages to match PCM_IO, PCM_ATTR, PCM_MEM
physical addresses - this code is from the original BSP...
Bits set in EntryHi and EntryLo0, EntryLo1 looks good and match
both virtual addresses hardcoded in bootloader header files and
physical addresses of PCMCIA interface controller area...

The problem is that when PCMTuplePtr (set to virtual 0x1E00 0000
mapped to 0xF 4000 0000 physical address of the Attribute Memory area)
is read in PCMReadFirstTuple nothing happens on the bus... including no
activity on chip-selects and junk content of memory is read like this:

Tuple Code=0x00
00
0E 08 0E 08 0E 08 0E 08 0E 08 0E 08 0E 0A 83 0E
80 06 00 00 00 3E 83 0E 80 42 19 00 50 7C 8C 0E
80 00 00 00 00 0A 00 00 00 00 00 00 00 0A B3 00
C0 3E 00 00 00 EC 83 0E 80 0D 00 00 00 0A 00 00
00 04 00 00 00 04 00 00 00 04 00 00 00 0A 00 00
00 00 00 00 00 04 00 00 00 0D 00 00 00 FC 9F 01
80 00 00 00 00 FC 9F 01 80 21 09 81 99 8C 67 0E
80 31 04 86 18 21 00 00 00 61 08 22 6A 22 60 52
56 14 60 40 00 7C 8F 05 80 21 00 00 00 00 00 00
00 7C 8F 05 80 8C 8F 05 80 04 00 00 00 FF FF

Tuple Code=0x00


Tuple Code=0x0A


Tuple Code=0x0A

[program is looping thinking it reads from CF memory]

Is there anything I could miss in regards to PCMCIA/CF setup?
Do you know any other ways to debug this problem?

Re: PCMCIA/CF - no activity on the bus by Pszemol

Pszemol
Wed Dec 03 11:45:12 CST 2003

I just verified Au1100 PCE0 and PCE1 pins and tracks associated with
these pins are good from the hardware point of view. I changed value
of sys_pinfunc bit 18 from PC to GPIO and I drove pins GPIO205 and
GPIO206 normally assigned to PCE0 and PCE1 with my debugger...
Signals follow the GPIO2 registers setting and buffered signals on
the CF connector follow signal values so I am more convinced now it
is problem somehow related to the software rather than the hardware...
Any ideas?

"Pszemol" <Pszemol@PolBox.com> wrote in message news:bqkgf5.1q4.0@poczta.onet.pl...
> I am in the process of target board hardware/software debugging.
> My system uses Au1100 chip and I use Windows CE .NET (4.2).
>
> A lot of peripherals work fine and this is good thing :-)
> The problem I have now is I do not see ANY activity on
> the PCMCIA bus - actually it is CF in my case...
>
> I drive CF_RESET pin on the card to be LOW and then try to read
> "tuples" from ATTRIB area of the CF card with the original BSP
> code but I got complete junk data...
> I have tapped logic analyzer to several signals: PCE0, PCE1,
> ROE, POE, CF_A0-A10 (address bus in CF connector) and several other
> signals on the connector side, behind drivers/buffers and I see
> nothing happens when I read the card. The only signals change
> is RESET, CF_DETECT (when I insert the card) and RDY/-BSY telling
> me the CF is ready... then: only silence...
>
> On the software side, I have assigned RESET, CF_DETECT and RDY/-BSY
> pins to be driven by GPIO200, GPIO22 and GPIO21 respectively and
> I set sys_pinfunc bit 18 to 0 to have PREG, PCE1, PCE2, PWE functions
> instead of GPIO207:204 (standard setting for PCMCIA) and also
> bit 17 to 1 to have access to GPIO200. I have also verified there
> is PCMInitialize function called to fill TLB with three 16M-byte
> large virtual memory pages to match PCM_IO, PCM_ATTR, PCM_MEM
> physical addresses - this code is from the original BSP...
> Bits set in EntryHi and EntryLo0, EntryLo1 looks good and match
> both virtual addresses hardcoded in bootloader header files and
> physical addresses of PCMCIA interface controller area...
>
> The problem is that when PCMTuplePtr (set to virtual 0x1E00 0000
> mapped to 0xF 4000 0000 physical address of the Attribute Memory area)
> is read in PCMReadFirstTuple nothing happens on the bus... including no
> activity on chip-selects and junk content of memory is read like this:
>
> Tuple Code=0x00
> 00
> 0E 08 0E 08 0E 08 0E 08 0E 08 0E 08 0E 0A 83 0E
> 80 06 00 00 00 3E 83 0E 80 42 19 00 50 7C 8C 0E
> 80 00 00 00 00 0A 00 00 00 00 00 00 00 0A B3 00
> C0 3E 00 00 00 EC 83 0E 80 0D 00 00 00 0A 00 00
> 00 04 00 00 00 04 00 00 00 04 00 00 00 0A 00 00
> 00 00 00 00 00 04 00 00 00 0D 00 00 00 FC 9F 01
> 80 00 00 00 00 FC 9F 01 80 21 09 81 99 8C 67 0E
> 80 31 04 86 18 21 00 00 00 61 08 22 6A 22 60 52
> 56 14 60 40 00 7C 8F 05 80 21 00 00 00 00 00 00
> 00 7C 8F 05 80 8C 8F 05 80 04 00 00 00 FF FF
>
> Tuple Code=0x00
>
>
> Tuple Code=0x0A
>
>
> Tuple Code=0x0A
>
> [program is looping thinking it reads from CF memory]
>
> Is there anything I could miss in regards to PCMCIA/CF setup?
> Do you know any other ways to debug this problem?

Re: PCMCIA/CF - no activity on the bus by Pszemol

Pszemol
Wed Dec 03 18:36:51 CST 2003

Never mind - I have it figured out.
CF works and I am able to load os-image from it!
I had MEM_STCFG3/RCE3 registers misconfigured...

I am so glad my board is booting image and showing
nice Windows CE .NET desktop on the LCD display :-)))
Now the rest should be very easy to tune up...

Cheers,
Pszemol.

"Pszemol" <Pszemol@PolBox.com> wrote in message news:bqkica.4fs.0@poczta.onet.pl...
> I just verified Au1100 PCE0 and PCE1 pins and tracks associated with
> these pins are good from the hardware point of view. I changed value
> of sys_pinfunc bit 18 from PC to GPIO and I drove pins GPIO205 and
> GPIO206 normally assigned to PCE0 and PCE1 with my debugger...
> Signals follow the GPIO2 registers setting and buffered signals on
> the CF connector follow signal values so I am more convinced now it
> is problem somehow related to the software rather than the hardware...
> Any ideas?
>
> "Pszemol" <Pszemol@PolBox.com> wrote in message news:bqkgf5.1q4.0@poczta.onet.pl...
> > I am in the process of target board hardware/software debugging.
> > My system uses Au1100 chip and I use Windows CE .NET (4.2).
> >
> > A lot of peripherals work fine and this is good thing :-)
> > The problem I have now is I do not see ANY activity on
> > the PCMCIA bus - actually it is CF in my case...
> >
> > I drive CF_RESET pin on the card to be LOW and then try to read
> > "tuples" from ATTRIB area of the CF card with the original BSP
> > code but I got complete junk data...
> > I have tapped logic analyzer to several signals: PCE0, PCE1,
> > ROE, POE, CF_A0-A10 (address bus in CF connector) and several other
> > signals on the connector side, behind drivers/buffers and I see
> > nothing happens when I read the card. The only signals change
> > is RESET, CF_DETECT (when I insert the card) and RDY/-BSY telling
> > me the CF is ready... then: only silence...
> >
> > On the software side, I have assigned RESET, CF_DETECT and RDY/-BSY
> > pins to be driven by GPIO200, GPIO22 and GPIO21 respectively and
> > I set sys_pinfunc bit 18 to 0 to have PREG, PCE1, PCE2, PWE functions
> > instead of GPIO207:204 (standard setting for PCMCIA) and also
> > bit 17 to 1 to have access to GPIO200. I have also verified there
> > is PCMInitialize function called to fill TLB with three 16M-byte
> > large virtual memory pages to match PCM_IO, PCM_ATTR, PCM_MEM
> > physical addresses - this code is from the original BSP...
> > Bits set in EntryHi and EntryLo0, EntryLo1 looks good and match
> > both virtual addresses hardcoded in bootloader header files and
> > physical addresses of PCMCIA interface controller area...
> >
> > The problem is that when PCMTuplePtr (set to virtual 0x1E00 0000
> > mapped to 0xF 4000 0000 physical address of the Attribute Memory area)
> > is read in PCMReadFirstTuple nothing happens on the bus... including no
> > activity on chip-selects and junk content of memory is read like this:
> >
> > Tuple Code=0x00
> > 00
> > 0E 08 0E 08 0E 08 0E 08 0E 08 0E 08 0E 0A 83 0E
> > 80 06 00 00 00 3E 83 0E 80 42 19 00 50 7C 8C 0E
> > 80 00 00 00 00 0A 00 00 00 00 00 00 00 0A B3 00
> > C0 3E 00 00 00 EC 83 0E 80 0D 00 00 00 0A 00 00
> > 00 04 00 00 00 04 00 00 00 04 00 00 00 0A 00 00
> > 00 00 00 00 00 04 00 00 00 0D 00 00 00 FC 9F 01
> > 80 00 00 00 00 FC 9F 01 80 21 09 81 99 8C 67 0E
> > 80 31 04 86 18 21 00 00 00 61 08 22 6A 22 60 52
> > 56 14 60 40 00 7C 8F 05 80 21 00 00 00 00 00 00
> > 00 7C 8F 05 80 8C 8F 05 80 04 00 00 00 FF FF
> >
> > Tuple Code=0x00
> >
> >
> > Tuple Code=0x0A
> >
> >
> > Tuple Code=0x0A
> >
> > [program is looping thinking it reads from CF memory]
> >
> > Is there anything I could miss in regards to PCMCIA/CF setup?
> > Do you know any other ways to debug this problem?