I would like to use the Peripheral Expansion Interface on the 9P 9215 module. From what I can see the module/bsp is already setup for CS0, and the Data lines to be used. However there are no examples on how to access that address space. I plan on hanging a couple of Octal UART’s off this bus. Has anybody used the expansion bus and are there any software examples of this?
I end up with answer on this from tech support. Here are some excerpts for those with similar issues:
1 In …Project\bsp\7_3\connectcore9p9215_a\customizeCache.c
Add the following entry to the end of the mmuTable[] :
//@GSI Modification enabled CS0
// start, end, pageSize, cacheMode, userAccess, phyStart, phyStop
{0x40000000, 0x40000200, MMU_PAGE_SIZE_4K, MMU_NONBUFFERED, MMU_CLIENT_RW, 0x40000000, 0x40000200} //@GSI Modification for ext bus
2 In …Project\bsp\7_3\connectcore9p9215_a\bsp.c
Comment out the first entry for CS0 and add a new entry for CS0 in the NAStaticMemoryTable[] :
Modify the timing values if required for the device connected to the bus.
//@GSI Modification enabled CS0
// Ena, CfgReg, WrEnDly, OEDly, RdDly, PgMdRdDly, WrDly, TnRndDly, BaseAddr, CsMask
{1, 0x80, 0x02, 0x02, 0x04, 0x02, 0x04, 0x02, 0x40000000, 0xff700001}, /* cs0 /
// {0, 0x82, 0x02, 0x02, 0x09, 0x02, 0x09, 0x02, 0x0, 0x0}, / cs0 */
3 Note that for an 8 bit data bus the data comes in on the high byte of the bus
AND SOME MORE:
I spoke with our engineering department and they had the following comments when I explained your situation and problem to them:
On the Peripheral Application header the data is connected this way: PERI_D[15:0] = CC9P9215_D[31:16]
Notice the connections are different for 8 VS. 16 bit interfaces.
8 bit only uses PERI[15:8] and starts with A0.
The NS9215 is not right justified as the NS9360 was.
NS9215/9210 Address/Data Bus LSB: Regardless of Endianess
A0 is always the least significant bit for 8-bit peripherals,
A1 is always the least significant bit for 16-bit peripherals,
D24 - PERI[8] is always the least significant bit for 8-bit peripherals,
D16 - PERI[0] is always the least significant bit for 16-bit peripherals,
8 bit peripherals are aligned with D31-24 - PERI[15:8]
The four external memory cycles require both A1 and A0.
16 bit peripherals are aligned with D31-16 -PERI[15:0]
The two external memory cycles require the state of A1
and not A0
Hi alevine,
thanks for your previous post! it helped me to connect the connectcore9p9215 to a dual ported RAM (actually the dp-ram is located in a fpga).
I’m utilizing CS2 instead of CS0 but that should not be a problem here. My problem however is a bit more tricky. I’m trying to use the full 16 bit data bus here.
which works when fine I run my application via the debugger, but when I run the application without the debugger connected it seems to ignore the settings made in bsp.c and gives me just twice the MSB of those 16 bit.
so instead of 0x1122 it will read 0x1111, when read as an char it’s 0x11 0x11 instead of 0x11 0x22 etc.
(the application reads those values and sends it to the console)
it really seems to ignore the settings in the NAStaticMemoryTable
hope some one reads that and is able to help here
greets
kay
I looked back at my notes.
The since I am using 8-bit the CfgReg int the NAStaticMemoryTable[] was set for 8 bit. Did you set it for 16 bit?
The register is described in:
NS9215 Hardware Reference Manual
Section:
StaticMemory Configuration 0-3 registers
Page (in my version):
251
Don’t know if that will help but thought I would mention it.
There is a dearth of application notes on using this bus from digi. i would never have figured it out without their support team.
Good luck,
Adam
Yes I did set it to 16 bit. It just really seems to ignore it.
I have a workaround running now by configuring the DP RAM to 8bit.
Well, not ideal but at least it works.
Thanks! Kay
when you run from the debugger, you application image sets up the chip selects, when running from flash the boot loader does. If you haven’t updated the boot loader (rom.bin from a release build) it won’t work properly.
Oh cool, that sounds promissing - I have not done this indeed. Thanks!