Mod54415 Multiple Chip Select

Discussion to talk about software related topics only.
Post Reply
egage
Posts: 4
Joined: Thu Jun 05, 2014 7:19 am

Mod54415 Multiple Chip Select

Post by egage »

Hi all,

I hooked up some 573 and 574 to add some GPIO to the system. In all I need something like 32 Inputs and 32 Outputs and another 32 mixed GPIO. Since this monster is 32 bits and has 3 chip selects that I can use, I figured I could do it. So I started with the inputs everything went well and is working perfectly (well haven't tried to connect all 32 bits but the first 8 bits are working fine). I used 0x1000000 as base address for CS1(inputs). After that I tried the outputs. And this is where I noticed something strange. I used 0x11000000 as base address CS4(outputs). Both csmr are set to 0x00000001 so, from what I understand of the documentationof the coldfire core, the address range for the inputs is supposed to be 0x10000000 to 0x1000FFFF and the range for the outputs is supposed to be 0x11000000 to 0x1100FFFF. However, everytime read from any address reserved for the chipselect, all chip select are asserted at the same time. So if I have only the inputs if works... if I have only the outputs it works but as soon as both are connected the input overwrites the outputs.

I based my code from the Databus-IO-Expansion Application note:
http://www.netburner.com/support/docume ... ion-5/file

Thing is the example for the code is made for 5234 5270 and 5282 modules. So I had to adapt it the the 54415. But since I didn't find much example about how to do it with this particular module, I Wonder if there is something to know about the chip selects or about how to get data from external parallele devices.

when I write to the port I use:
*(unsigned int *)(ADDR_IO_OUTPUTS) = Value;

when I read to the port I use:
return *(unsigned int *) (ADDR_IO_INPUTS);

Is there another way to do it with the MOD54415 that would make the chip select work as they should?

Just for more information, I use 7 serial ports, ethernet and the EFFS FAT file system on this module. So far everything runs smoothly except the GPIO expention that I'm trying to implement.

CS1 is configured as follow:
csar = 0x10000000
cscr = 0x00000010
csmr = 0x00000001

CS4 is configured as follow:
csar = 0x11000000
cscr = 0x00000010
csmr = 0x00000001

I know that in the example they are shifting the address to the right 16 bits... but from what I read of the doc AND from what I've tester so far... for the 54415 this register is 32bits so no shifting

Thanks in advance for your help!
Last edited by egage on Thu Jun 05, 2014 2:21 pm, edited 1 time in total.
rhopf1
Posts: 37
Joined: Mon May 12, 2008 5:57 am

Re: Mod54415 Multiple Chip Select

Post by rhopf1 »

See MOD54415.pdf in /nburn/docs/platform it list available memory addresses.

I'm working on a project and plan to use 0xC2000000 but is untested.
egage
Posts: 4
Joined: Thu Jun 05, 2014 7:19 am

Re: Mod54415 Multiple Chip Select

Post by egage »

Thank you for your quick answer. From the document you refered me to I can see that 0x02000000 to 0x3FFFFFFF is available for application so I guess it should work. I just tried changing the base address to 0xC2000000 though... but I still have the same problem...
mbrown
Posts: 61
Joined: Tue Jan 29, 2013 7:12 pm

Re: Mod54415 Multiple Chip Select

Post by mbrown »

The Flexbus on the MOD54 is a little different from the 70 and the 82 in that the data and address bus is shared on the chip. This means it takes one cycle to write the address, then one cycle to write the data. There are latches on the module to capture the top 16 address bits during the address latching cycle then hang onto them so that the flash knows the appropriate address you're talking to, the 16 data bits are driven on those lines during the chip select assertion part of the cycle. Since the data and address lines are shared with the on module flash, using the bus in 32 bit mode will have unexpected memory access consequences. You can work them out, but it's almost always easier to think it out in 16 bit mode that you know should work.

The other things of note in your code are the number of wait states you have and possibly the slew rate. You've got the number of wait states set all the way to 0. This might work, but I think the lowest I've ever got working was 3 wait states. I usually test external hardware with the maximum number of wait states and then turn the number down until it either stops working or I'm at full speed. Lastly, the slew rate should already be pretty high due to the the bus being shared with the flash, but you can also play with different settings in the srcr for the flexbus in the gpio module.

These are the settings I think should work, but I don't have the hardware in front of me to test it.

sim2.cs[1].csar = CS1_BASE_ADDRESS;
sim2.cs[1].csmr = 0x00000001; // 64k block, set valid bit
// sim2.cs[1].csmr = 0x03FF0001; // 64MB block, set valid bit
sim2.cs[1].cscr = 0x0000FD80; // Max wait states, auto-acknowledge, 16 bit mode
egage
Posts: 4
Joined: Thu Jun 05, 2014 7:19 am

Re: Mod54415 Multiple Chip Select

Post by egage »

Well, i've tried every wait time settings possible. Whatever wait time setting I use, I have the same result... all chip select are asserted at the same time every time I read from or write to any address that is available for chips selects.
rnixon
Posts: 833
Joined: Thu Apr 24, 2008 3:59 pm

Re: Mod54415 Multiple Chip Select

Post by rnixon »

I'm not sure I understand your last post, but the way a chip select works is that each compares it's address configuration settings to the address you read/write to. If you configure multiple chip selects in the same address space then they would indeed all go active at the same time. There is usually a minimum block size as well, I'm not sure what that is on your platform, but I think its 64k on other platforms. For example, your chip select blocks need to be 64k apart. But again, you need to check the manual for your processor to see if there is a minimum and how big it is.
egage
Posts: 4
Joined: Thu Jun 05, 2014 7:19 am

Re: Mod54415 Multiple Chip Select

Post by egage »

That's exactly why I have a problem... because the chip selects doesn't seem to behave as you discribed. I've made some more tests and I'm more and more confused:

Test1:
Inputs
sim2.cs[1].csar = 0xC2000000;
sim2.cs[1].cscr = 0x00002110;
sim2.cs[1].csmr = 0x00000001;
So address range: 0xC2000000 to 0xC200FFFF

Outputs
sim2.cs[4].csar = 0xC2800000;
sim2.cs[4].cscr = 0x00000010;
sim2.cs[4].csmr = 0x00000001;
So address range: 0xC2800000 to 0xC280FFFF

In main loop:
unsinged int test = *(unsigned int*)(0xC2800000);

Results:
The input is read perfectly,
The output display the inputs..... shouldn't...
The scope shows CS1 and CS4 asserted...... only CS1 should be asserted

Test2:
Basicaly I tried to disable the inputs Chip Select and read from this address anyway

Inputs:
sim2.cs[1].csmr = 0x00000000;

Outputs: same as Test 1

In main loop:
unsinged int test = *(unsigned int*)(0xC2800000);

Results:
The input is read whatever is on the bus so... pretty much anything,
The output still displays the inputs..... shouldn't...
The scope shows CS1 and CS4 asserted...... no chip select should be asserted
Test3:
Last test I did was to disable the two chip selects and still try to read at the same address. What I noticed with the scope is that even with no chip select enable ... all chip select are asserted when I read or write from the address. I tried more addresses to read from all available for chip select and the result is the same.
From my experience with chip select using other MCU... the chip selects are not supposed to be asserted unless they are enabled... and of course unless you read/write to an address within the address range programmed in the corresponding registers.


EDIT:

Wow just fixed it! Apparently it was an noise issue. I don't know exactly why it was behaving this way it is the first time I know to do somthing of the sort. The way to fix the problem is to add a capacitor between the GND and the your chip select. I used 0.01µF and it seems to have fixed the problem.

Thank you all for your help... I guess this thread could be moved to hardware then sorry I didn't know it was an hardware problem when I started this thread.


EDIT 2:

0.01µF seems to be a bit much... work better with 1.2nF
Post Reply