ColdFire/68K Microcontrollers and ProcessorsのトピックChip select problem on 5329

Chip select problem on 5329

timw — Wed, 04 Jan 2012 23:44:38 GMT

I am having a problem on a new board with the chip selects. I have a MCF5329 board and a P E BDM pod. Just using the memory windows of the ColdFire Debugger, I am configuring chip selects 0, 1 and 2. When I set bytes in the chip select 1 and 2 areas, chip select 0 also activates. Here are the chip select configurations:

CSAR0 0

CSMR0 0x00ff 0001

CSCR0 0x0000 17a0

CSAR1 0x1000 0000

CSMR1 0x0003 0001

CSCR1 0x0000 1ba0

CSAR2 0x2000 0000

CSMR2 0x00ff 0001

CSCR2 0x0000 0ba0

CS0 is for 16 MB of Flash, 5 wait states, base address 0

CS1 is for 256 KB of Static RAM, 6 wait states, base address 0x1000 0000

CS2 is for for an FPGA, 2 wait states, base address 0x2000 0000

After configuring the chip selects, If I write to location 0x1000 0000, both chip selects 0 and 1 go active, CS1 for one pulse and CS0 for 2 pulses. If I write to location 0x200d 0000, both chip selects 0 and 2 go active. Once again, I am using the ColdFire debugger to modify the memory. These memory regions do not overlap, so I don't understand why CS0 goes active. What am I doing wrong?

Re: Chip select problem on 5329

TomE — Thu, 05 Jan 2012 07:13:14 GMT

I think I know this one.

MCF5329 Reference manual:

17.3.2 Chip-Select Mask Registers (CSMR0 – CSMR5)

Valid bit. Indicates whether the corresponding CSAR, CSMR,

and CSCR contents are valid. Programmed chip-selects do not

assert until V bit is set (except for FB_CS0, which acts

as the global chip-select). Reset clears each CSMRn[V].

Note: At reset, no chip-select other than FB_CS0 can be

used until the CSMR0[V] is set. Afterward, FB_CS[5:0]
functions as programmed.

Your code (and your programming from the debugger) should reprogram CSAR0 first and CSMR0 next. Once the Valid bit has been set in CSMR0 it should start working normally and not overlap the other ones.

Also detailed later as:

17.4 Functional Description
17.4.1 Chip-Select Operation

FB_CS0 is a global chip-select after reset and provides external

boot memory capability.

17.4.1.3 Global Chip-Select Operation
FB_CS0, the global (boot) chip-select, supports external boot memory

accesses before system initialization. Its operation differs from

other external chip-select outputs after system reset.

After system reset, FB_CS0 is asserted for every external access.

No other chip-select can be used until the valid bit, CSMR0[V],

is set; at this point FB_CS0 functions as configured. After this,

FB_CS[5:1] can be used as well. At reset, the logic levels on the

FB_D[4:3] signals determine global chip-select port size.

When you have a problem like this it is worth reading the whole chapter for the module in the Reference manual to find paragraphs like the above.

You might also have found the following similar problems in this forum with a search:

https://community.freescale.com/message/19402#19402

https://community.freescale.com/message/44920#44920

And about 20 others matching.

Tom

Re: Chip select problem on 5329

timw — Fri, 06 Jan 2012 03:25:56 GMT

I wasn't writing to CSAR0 as it was already 0. After making a change, to write CSAR0 first, I get 2 CS1 pulses and one CS0 pulse when addressing an address in the CS1 region. Before making this change, if I didn't write to CSAR0 first, CS0 pulses twice and CS1 once. So the recommendation changes the behaviour, but does not eliminate the problem. Any other suggestions?

Re: Chip select problem on 5329

timw — Fri, 06 Jan 2012 04:27:56 GMT

Looking a little closer, forget the multiple pulses. Regardless of the sequence of CSAR0 and CSMR0, accessing a location in memory for CS1, I get a CS1 pulse and some time later, a CS0 pulse. The memory access works OK, the CS0 pulse didn't seem to screw anything up. I still don't know why.

Re: Chip select problem on 5329

TomE — Fri, 06 Jan 2012 14:46:52 GMT

You have to program CS0 to be valid at some address to stop it from responding "everywhere". Possibly just the once.

You're doing these accesses from the debugger. It could be accessing all sorts of addresses as it goes about its business.

Where's the VBR pointing? Into RAM or into the boot area? The debugger might be trying to rewrite interrupt vectors.

Test this with "real code" and whatever is happening will probably go away.

Tom