MPC8347 Unwanted Data Mirroring on 2 LCS (both using UPMs)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MPC8347 Unwanted Data Mirroring on 2 LCS (both using UPMs)

1,572 Views
VictorPictor
Contributor I
Hi,
 
I am using a rev. 3.1 MPC8347.  I have a 4MB dual-ported SRAM chip (IDT70T35) on LCS1 and and another 4 MB dual-ported SRAM chip (IDT70T35) on LCS3.  Both are configured to use UPMs.
 
My problem is that if I write something (byte, half-word, word, etc..) with the MPC8347 e300 in the lower half (first 2MB) of any of these chips memory mapped areas (as per my ORx/BRx settings), it also shows up in the lower memory map of the other chip (i.e. the intended write worked, but it also "wrote to the other chip" at the same chip offset).  What is strange is that if I write something in the upper half of any of these chips, the write is done correctly in that it only shows up in the chip I intended to write (as per my ORx/BRx settings)??!?!
 
I have checked all my ORx, BRx, LBLAWBARx amd LBLAWARx settings ad nauseum for overlap.  Everything seems fine.  I have even verified with a scope as to whether the chip select lines going to these two IDT70T35 chips are being activated properly by the MPC8347.  Yup, everything checks out. 
 
This seems to suggest that the local bus mirroring is happening within the MPC8347 somehow?!?!
 
Has anyone had a similar problem?  If so, could you possibly help me out with this MPC8347 mystery?
 
 
Thanks....
0 Kudos
3 Replies

447 Views
genuap
NXP Employee
NXP Employee
what are your ORx and BRx settings? Can you share?

Also, what do you have the law set to? Are you using the MMU?

 ... Paul

0 Kudos

447 Views
VictorPictor
Contributor I
Hi,
 
The ORx/BRx and LAWx settings for my MPC8347 local bus peripherals are as follows:
 
BootRom Flash (GPCM):
OR0: 0xFF00_0FF4
BR0: 0xFF00_1001
 
4 MB DPRAM Chip #1 (UPMA):
OR1: 0xFFC0_1000
BR1: 0x3000_1881
 
Unused LCS (nLCS[2] (AP25) pulled high):
OR2: 0x0000_0000
BR2: 0x0000_0000
 
4 MB DPRAM Chip #2 (UPMB):
OR3: 0xFFC0_1000
BR3: 0x3040_18A1
 
For IMMR Space (note that I move IMMR very early in bootcode from 0xFF40_0000 to 0xFD00_0000 to avoid overlap with bootrom NOR flash on LCS0).  And yes, I am following the recipe on how to move the IMMR as wrtten in the EARM UM (and the EARM UM Errata for page 5-6):
LBLAWBAR0: 0xFD00_0000
LBLAWAR0: 0x8000_0013
 
For bootrom flash (NOR) on LCS0:
LBLAWBAR1:  0xFF00_0000
LBLAWAR1: 0x8000_0017
 
For DPRAM chip #1 on LCS1:
LBLAWBAR2:  0x3000_0000
LBLAWAR2:  0x8000_0015
 
For DPRAM chip #2 on LCS3:
LBLAWBAR3: 0x3040_0000
LBLAWAR3:  0x8000_0015
 
 
 
As for the caching/MMU, I eventually use both (i.e. to I+D cache to copy executable faster out of flash to DDR, RTOS enables the MMU and caches formally during RTOS boot).  However, if I set a HW breakpoint early in my bootcode with my JTAG ICE, before the RTOS even starts to boot and before I enable the cache (i.e. all MMU registers are 0x0000_0000 except for hash2 which is 0x0000_FFC0) but after I've configured all my LCSs, UPM machines and LAWs, I see the data mirroring problem on my two DPRAM chips by poking/peeking with my JTAG ICE.
 
 
Any clues as to what could be causing this problem so early in the boot-up process would be greatly appreciated?  Please note that I always boot with an HRESET.
 
 
 
Victor.
 
 
 
0 Kudos

447 Views
VictorPictor
Contributor I
It seems that the problem has to do with the fact that each DPRAM chip has two chip select lines (nCS and CS).  According to the DPRAM data sheet, a chip is selected if nCS=L and CS=H and this chip is safely deselected if nCS=H and CS=L.   The nCS=H and CS=H combination is "not allowed" that can lead to undefined behavior.
 
What seems to be happening is if one DPRAM chip is selected (nCS=L and CS=H) and being written to, the other DPRAM's UPMx on a different LCSx is inactive and is putting the inactive DPRAM's nCS and CS pins to the forbidden "nCS=H  + CS=H" combination, causing an inadvertant write to the supposedly deselected chip, causing the mirroring.
 
Would anyone know how I could reprogram the UPM and/or apply some glue logic to keep CS=L between write or read transactions on a DPRAM chip that is supposed to be deselected between transactions by the UPMx?   As this is supposed to be a high speed device (133 MHz), I am not sure that using an inverter would be a reliable work-around (or to use a GPIO as the CS).
0 Kudos