ARM7TDMI Instructions Taking 50-100 Clocks

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I'm running an Atmel ARM7TDMI on a prototype board I wire-wrapped and
am monitoring the system with an oscilloscope. By comparing the clock
pulses to the read/write pulses, I'm finding that single-byte store
and read operations are taking literally 50-100 clocks. Naturally this
is unacceptable for any purpose, and is obviously a sign of something
being majorly wrong. I've read all the literature on the ARM I can
find including all of Atmel's documentation and white papers. Does
anyone have any idea what this might be?

Re: ARM7TDMI Instructions Taking 50-100 Clocks
Quoted text here. Click to load it

Does this implementation of the ARM7 also include programmable timing for
its memory interface (duration of reads, writes etc). I know the two devices
that I've used allow this.

Re: ARM7TDMI Instructions Taking 50-100 Clocks says...
Quoted text here. Click to load it
I think you've got it.  The AT91R40807 that I used starts up the
system with 8 wait states on CS0.  One of the first steps in the
boot process is to set an appropriate number of wait states for the
speed of the memory actually in use.

Another factor may be in the reading and storing of single bytes.
On a system with 16-bit memory width, single-byte reads and stores
can take some extra cycles while the bytes get properly aligned.
Storing a single byte may become a read-modify-write operation.

The OP didn't say whether the 50 to 100 clocks was the length
of a single read or write cycle, or the time for a complete
read-modify-write cycle.

Mark Borgerson

Re: ARM7TDMI Instructions Taking 50-100 Clocks

Quoted text here. Click to load it

If you run the AT9155800A at 32 kHz then your performance will drop
It would help if you told us which chip and clock frequency you use.
Best Regards,
Ulf Samuelsson
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline