M5235BCC EVB - Help using the Chip Select Module on the BUS Port

[TJHague]

Hi,

I am using the M5235 Business Card Controller EVB.  I am attempting to use the Chip Select Module for an output via the BUS port ( D[31:24], A[15:0], etc.)  At the present time the goal is just to figure out how to get an output so that we can apply it once we fully know how to use the board.  I have written a program but this has led to a few questions:

1.) Am I going about programming this in the right way (code attached)?  If not, what is the correct way?

2.) When we hook it up to a scope we see an output.  Could this be from something else other than my program using the Data Bus?
     We have noticed that when transferring applications to the board and typing in the terminal the Data Bus gives an output as well.  This is what has led us to the above question.  If it is/could be something else displaying the output, how would we go about fixing it?

[EDIT]:  I forgot to mention, I am using the QuadrOS + OpenTCP RTOS.

Thanks,
-Tyler


Message Edited by TJHague on 2008-07-03 09:27 PM

[TJHague]

It would also appear that I forgot to mention, the Chip Select pins are constantly reading at 3.3V, so there appears to be no indication that it is working.

[SimonMarsden_de]

Hi Tyler

Here's a suggestion...

The Chip Select pins are multiplexed with GPIO functions. It could be that your code to initialise the chip selects is correct, but the signal is never reaching the physical pin because it's set for GPIO.

Configuration of the multiplexing is done through the Pin Assignment Registers. The one for the chip selects is PAR_CS.  You need to make sure that you have something like:

    MCF_GPIO_PAR_CS = MCF_GPIO_PAR_CS_PAR_CS7 |
                      MCF_GPIO_PAR_CS_PAR_CS6 |
                      MCF_GPIO_PAR_CS_PAR_CS5 |
                      MCF_GPIO_PAR_CS_PAR_CS4 |
                      MCF_GPIO_PAR_CS_PAR_CS3 |
                      MCF_GPIO_PAR_CS_PAR_CS2 |
                      MCF_GPIO_PAR_CS_PAR_CS1;

...to set all the Port CS pins to their chip-select functions.


Hope this helps.


Simon

[TJHague]

Hi Simon,

Thanks for helping.  I'm still a little lost though.  I put the code you suggested into my program and didn't view anything different over the oscilloscope.

I'm wondering if I'm not putting the data in correctly to be transferred (if I understand it correctly, if no data is being transferred, then the chip select pin would not assert).  Does assigning a pointer to the memory address and then assigning it a value work?  Is there a better way to do this that I am not thinking of?

Thanks,
-Tyler

[stzari]

Hi Tyler,

- I think that you should first look for (or find out - check all CS and DRAM controller registers) the memory map for your module.
Then select a free memory region and retry.

- In your code you have initialized CS1 at 0x10000 (64k) with a length of 16M. You need to either put the base address to a 16M boundary or reduce the length of the memory block

- (this is a guess, since I don't know your memory map): Usually the first memory block is configured as DRAM (starting at 0 with a len of x MB), so you would get undefined behaviour if you program a chip select into the same memory area.

HTH
    stzari

[TJHague]

Hi stzari,

I went through and made the length more reasonable, but I did not see any change.  Although, I did some messing with the code and I am pretty sure that the output over the Data Bus that I am seeing is the data that I put in.  It would seem that the main problem that I am having now is that I can't figure out why the Chip Select pin will not assert.  I have been reading through the reference manual and searching online and cannot find out how to do this.  Any suggestions?

Thanks,
-Tyler

[stzari]

Hi Tyler,

Did you move the memory block for CS1 as suggested ?
I had a look into the memory map for the M5235BCC (see Page 16 of the manual) and this shows (at least for dBUG) that the first 16Mbyte are used by the SDRAM.
In the MCF5235RM it is stated that you get undefined behaviour if memory blocks overlap between DACR and CSAR (Chapter 16.3.1)

Did you also check that you would see a change on CS1 by initializing it as GPIO (see ch. 12) and then toggling it ?

HTH
    stzari

[TJHague]

Hi stzari,

I have tried moving the CS1 to few different spots.  So far I have tried 0x00010000, 0x00000000, and 0x20000000.  0x200000000 is "internal SRAM, user space" so it should be a good block to use, right? 

When I toggled between GPIO and the Chip Select Function, there was no change.

Thanks,
-Tyler

[stzari]

Hi Tyler,

1. If you want to access memory at a location using CS1 you have to setup this memory location without any ambiguities. So you have to move CS1 to a FREE location in memory (not DRAM, not flash, not IPSBAR, not internal SRAM ...).

2. With toggling CS1 I meant that you should set it up as GPIO (PAR_CS) then as Output (PDDR_CS) and then driving different levels (PODR_CS or PPDSDR_CS/PCLRR_CS). See Chapter 12 in the RM for a description on how to do this.

HTH
   stzari

[TJHague]

Well, I finally found the problem.  Turns out that you were right Stzari, it was the memory location I was using.  I had tried a few, it just turns out that I had not tried any of the right ones.  The one that ended up working was 0x80000000.  I hadn't tried that before because it is labeled as reserved which led me to believe that it should not be used.  Thanks for all of your help .

[francois_boucha]

Hi all

btw... is there an elegant way to place an adress on A[31:0] in a coding perspective?  And to read from data bus also?

franck