The only things I can think for potential reasons why one PC104 board
wouldn't work would be:
*) board uses 5V CMOS logic thresholds (not 5V TTL) -- TTL logic is
whats specified for ISA/PC104 buses. 5V CMOS needs 3.5V input to be
classified as logic '1' -- on the TS-7xxx there will be 3.3V (close -
but not quite - so it may work part of time like you see)
*) potential hold time issues-- if your device latches the
data/address bus on the rising (de-asserting) edge of the
IOR/IOW/MEMR/MEMW strobes and has a large hold time requirement you
may have a problem. Boards should probably latch on the falling edge
of the strobe or -- better yet -- in the middle somewhere towards the
beginning. Bus cycle length is at its slowest setting by default at
around 300ns on the TS-7xxx. 300ns is a *very* slow speed by todays
standards and most devices will work with a much faster bus cycle.
This timing can be tweaked from the EP9302 SMC timing registers for
CS1 and CS2.
*) Make sure your 8 or 16 bit reads/writes in software use the ARM
ldrb/strb or ldrh/strh instructions. (i.e. compile with -mcpu=arm9
and dereference char * and short *'s if using gcc) 32 bit reads in
the PC104 address space will likely not behave as you expect since the
CPU does not break the cycle up into 2 16-bit cycles-- instead it
asynchronously toggles ADD1/ADD0 in the middle of a bus cycle 2 or 4
times as long as normal.
*) Make sure if you've got a 16-bit PC104 device you use the
0x2xxx_xxxx addresses and 0x1xxx_xxxx if you've got an 8-bit device.
An x86 processor had a neat feature of automatically knowing whether
it was talking to a 8 or 16 bit device in the middle of the bus
cycle-- the ARM doesn't.
You will likely see something obviously wrong if you can watch a bus
cycle using a scope or logic analyzer. If you do, pay attention to
the strobe length and when the databus seems to start being driven by
the peripheral after the strobe during reads. The databus lines
should be stable for 20ns or so before the strobe ends for reliable
operation.
//Jesse Off
> I would get some results that were close (such as one of two bytes
> read back were correct, the other garbage or the first byte repeated).
> Sometimes it would fail 5 times out of 100 tries.
>
> Could there be some other timing issues? Or something like that I
> could look for? I don't have the leeway to change the hardware at this
> point, but I wrote all the drivers and can mess with software to my
> heart's content.
>
> Thanks,
> Frank
>
------------------------ Yahoo! Groups Sponsor --------------------~-->
AIDS in India: A "lurking bomb." Click and help stop AIDS now.
http://us.click.yahoo.com/9QUssC/lzNLAA/TtwFAA/CFFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|