NetBurner Community Forum

I can guarantee that memcpy is correct... what I will note is that the pointer math is going to slow things down. What happens if you increase the delay from Addr latch to CS active? what happens if you slow down the internal ack (or are you running with external ack)?

-Dan

Unless you have fixed the A0 issue its not going to map correctly....

Your copy does byte reads/writes, memcopy does 32 bit reads/writes...
If you have the bus setup for 16bit access the bus controler automatically splits the 32 bit accesses up into two 16 bit accesses....

My guess is that if you use 16 or 32 bit read/writes in a loop with pointers you will see the same problem....
Also with A0 incorrectly hooked up the memory will be half the size you expect and will wrap around....


PAul

A0 is NOT connected!

Using pointers, I verified that data is being transferred as bytes, even though CSCR is configured for a 16-bit port size.

If memcpy() is using 32-bit transfers, that would explain the pattern I posted earlier.

So the question is, if I've correctly configured the port for 16-bits, why don't the memcpy() 32-bit transfers convert to 16-bit transfers, and why don't
the byte-wide pointer transfers convert to 16-bit transfers.

It seems like the port size configuration bits (CSCR:[7:6]) are having no effect. [7:6] = 10 = 16-bit port size.

Am I reading the manual correctly?

In Reference Manual MCF54415RM.pdf, paragraph 20.4.3, Figure 20-4 shows data byte alignment for the various port sizes.

The bytes count from left to right as byte 0, byte 1, etc, with byte 0 always assigned to data bus bits 31:24.
Is byte 0 the MSB or LSB?

I have a sinking feeling that we screwed this up.

Sorry I saw A0--A14 on your original post and got the
sense of RAM vs Module backwards I read Module as Ram Module....

So you have the address connected correctly....


8 bit buses connect to D31..D24
16 bit busses connect to D31..D16

So if you on D0..D15 then those bits are only active in 32 bit transfers...

I'm not sure which question you're answering. Why memcpy() only does a 32-bit transfer even with a port size of 16-bits, or whether data bit D0 is transferred on D16 or D24 of the Mod54415 module when using a port size of 16-bits?

If you have 16 bit devices they should be connected to D31..D24 and ignore D0..D15
A0 is unused externally with 16 bit devices.



Full set:
**************************8 bit device**************
8 bit device connects to D31..D24

8 bit access occur as single events.

16 bit access occur as 2 events

32 bit access occurs as 4 events.


**************************16 bit device**************
16 Bit device connects to D31..D16
A0 is not used externally.
8 bit reads appear as 16 bit read with the internal logic deciding to pick the
byte off of D31..D24 (even address)or D23..D16 (Odd address)

8 bit writes put the appropriate data on D31..D24 or D23..D16 depending.
The BEx lines reflect the valid byte lane.

16 bit reads and write appear as single transactions on D31..D16

32 bit Reads/writes appear as two 16 bit transactions on D31..D16 with A1 changing between accesses.


32 Bit devices connect to D31..D0 Nothing but a 32 bit device connects to D0..D15
A0,A1 are not used externally.
8/16 Bit reads appear as 32 bit read with internal logic selecting the correct bytes.
32 bit read/write appear as single bus transaction.

8 bit writes put the appropriate data on the correct lane and signal with the BE0..Be3 lines which bytes should be valid.
16 bit writes put the appropriate data on the correct lane and signal with the BE0..Be3 lines which bytes should be valid.