Realignment of existing memory map in coldfire(MCF5206)

3,053 Views

We have requirment to add NOR flash and Ethernet controller into existing Controller(MCF5206EUM) in expansion board.(Note: Expansion board is plugged on main board and main board will not change). Current system has PAR value of 0001 to use A27-WE0, A26-WE1, A25-CS5, A24-CS4(refer MCF5206EUM/D, rev.1 Table 8-8). We want to realign existing memory map and insert NOR flash & Ethernet controller into memory by moving other peripheral into available unused memory.

- Can you suggest any impact by realign existing memory map, considering existing hardware design?
- Is there a way to create additional chip select in controller using PAR?(Note: In current design, any change in PAR value is resulting in system crash or boot issue)
- We want to use unused memory range and can it be addressable? Current memory map details: DRAM(4M), SRAM(1M), BBRAM1(1M), BBRAM2(2M), Flash CHIP1(128K), empty1(1.876M), I/0(1k), empty2(3K), EEPROM(4K), empty3(~3G).
For example, Can we move BBRAM2(2M) into empty3 and use BBRAM2 for other peripheral?

1 Solution

2,504 Views

You may need to provide a schematic.

There are eight chip select decoders and pins, but you only have six in use (the other two are being used for WE0 and WE1).

Any decoder can decode any combination of the upper 16 address bits. Each decoder can decode any power-of-two size from 64k to 4G, starting at the same power-of-two address boundary.

The MBAR can be written to put the peripherals at any starting address with a resolution of 1k. The RAMBAR allows the 8k static RAM to be at any 8k address.

You list 10 addressed devices, but you're only using 6 chip-select pins. That must mean the board has external hardware further decoding one or more of the chip-select pins. There no way for anyone to be able to guess what that is without details. External decoders will divide the chip-select decode into fixed blocks depending on the address lines they're decoding.

This is all very simple hardware engineering. You need to get an engineer to look at the schematic and redesign it for you.

> Is there a way to create additional chip select in controller using PAR?

You can have two extra chip selects as long as no device is using the WE0 and WE1 pins. It looks like they are used.

The most important thing is this. Which chip-select pins are connected to the expansion connector? You have to start by using one of those if you don't want to modify the main board.

You shouldn't have to think about "moving peripherals around" in the address map. The decoders are very flexible, and the code shouldn't depend on specific addresses.

Tom

View solution in original post

12 Replies

2,505 Views

You may need to provide a schematic.

There are eight chip select decoders and pins, but you only have six in use (the other two are being used for WE0 and WE1).

Any decoder can decode any combination of the upper 16 address bits. Each decoder can decode any power-of-two size from 64k to 4G, starting at the same power-of-two address boundary.

The MBAR can be written to put the peripherals at any starting address with a resolution of 1k. The RAMBAR allows the 8k static RAM to be at any 8k address.

You list 10 addressed devices, but you're only using 6 chip-select pins. That must mean the board has external hardware further decoding one or more of the chip-select pins. There no way for anyone to be able to guess what that is without details. External decoders will divide the chip-select decode into fixed blocks depending on the address lines they're decoding.

This is all very simple hardware engineering. You need to get an engineer to look at the schematic and redesign it for you.

> Is there a way to create additional chip select in controller using PAR?

You can have two extra chip selects as long as no device is using the WE0 and WE1 pins. It looks like they are used.

The most important thing is this. Which chip-select pins are connected to the expansion connector? You have to start by using one of those if you don't want to modify the main board.

You shouldn't have to think about "moving peripherals around" in the address map. The decoders are very flexible, and the code shouldn't depend on specific addresses.

Tom

2,504 Views

Tom,

Thanks for support in resolving issue.

Current status of chip select: CS1 (Flash Memory), CS2(BBRAM), CS3( SRAM), CS4 ( Memory mapped Ethernet IO), CS5 ( Memory mapped Peripheral IO). We have CPLD to derive chip select in combination with address lines for peripheral also like UART, CAN and others. As told before WE0 & WE1 is used.

We have limited signal available to expansion board that is CS2, R/W, INT8, RESET,D31-D0 and MA27-MA0 and all three devices(NOR flash, SRAM and Ethernet controller) should be addressed using limited signal.

Our challenge is to have chip select signal for all devices with above limitation and other required lines R,W, EN and so on... for individual device.

Meanwhile, We will study hardware as per your suggestion and explore any possibility.

Regards,

Manjunath

2,504 Views

> CS2(BBRAM)

> expansion board that is CS2, R/W, INT8, RESET,D31-D0 and MA27-MA0

So the BRAM is on the expansion board?

> We have CPLD to derive chip select

Using which chip select as input to the CPLD? Or do you have multiple chip selects going into the CPLD?

If you have CS2 going to the expansion board (and nowhere else) then you can use any of MA27-MA0 and that chip select into a CPLD on the expansion board, or you can even use a fast version of the 74HC131 for 8 outputs (from 3 address lines) or the 74HC154 for 16 decoded outputs (of 4 address lines).

The peripherals all need to be the same speed (or all run at the speed of the slowest device). More importantly, they all have to have the same signal timing and bus width to share a chip select. If they need different timing or width then it gets a LOT harder. You might need to change the main board to do it properly.

Tom

2,504 Views

Tom,

We have expansion board without CPLD. Now CPLD exists on main board which derive chip selects for devices like CAN, UART and others. As per hardware schematic CS2 & MA24 is available for expansion board which can be used as chip select along with decoder. Challenge we are facing is on firmware side and currently all chip select is done during boot up through CSAR, CSMR and CSCR for 0 - 5 chip selects and other two lines can't be used as chip select due to already being used as WE0 & WE1.

We need your support in understanding how to achieve chip select for devices (flash, RAM, Ethernet) in Coldfire 5206EUM along with modification in linker files.

Any example on controller will help us to resolve our issue.

Regards,

Manjunath

2,504 Views

I don't understand your problem.

You need a hardware engineer to design the hardware, and to check and make sure that all of the timing requirements of all of the new chips can be met by their design. It is VERY likely you'll have to reprogram the chip select decode "on the fly" when accessing different chips through it. This is possible as anything can be done in software. But not everything SHOULD be done.

Then you need a programmer (preferably also an engineer who understands hardware) to modify the code so it can address these peripherals. Then it will need a lot of new driver code to make those peripherals work, especially the Ethernet controller.

I don't know what sort of Ethernet controller you are going to select that you can operate over a simple data bus without DMA. You really need a new main board with a CPU chip that has built-in Ethernet. Re-reading your original post indicates you already have "CS4 ( Memory mapped Ethernet IO)", so I guess you already have a controller and code, and the purpose is to add a SECOND ethernet controller.

Your best choice for an "Ethernet controller" might be a completely separate microcontroller, like any of the Coldfire chips. The smallest one looks to be the MCF51CN128 with Ethernet and FlexBus. You would then need to connect the two CPUs together through a dual-port-RAM, like these:

Dual - Port SRAMs - Cypress

(I wrote the above before I realised you already seem to have an existing Ethernet controller and you have an interrupt available).

> Challenge we are facing is on firmware side and currently all chip select is done during boot up

So what? It doesn't have to be set up then. The firmware can easily be changed to set up the new peripherals. There's just new code to be written.

> along with modification in linker files

The one thing that shouldn't need to change much is the linker file. Everything else has to change, but I don't see what that should. If you have different "blocks" of memory defined in the linker file, then changing an address is as simple as changing the old address to the new address. What more would you want? I can't see how you could have used up the 4G address space. There has to be a spare Gig or so of address space in there you can program CS2 to decode, and have all the new peripherals show up there.

In case it helps at all I typed "address decoder hc131 example" into Google and the first match is this:

http://research.cs.tamu.edu/prism/lectures/mbsd/mbsd_l16.pdf

Rereading your posts it looks like:

I'm trying to work out your chip select and memory map from your posts, but there's not enough information. Could you please make a complete list like this:

Chip Select Address Size Function

CS0 ????? ????? Boot Memory/Flash

CS1 8M 128k Flash

CS2 5M 3M BBRAM (but there are 1M and 2M BBRAMs?)

CS3 4M 1M SRAM

CS4 ????? ?? Ethernet

CS5 10M-4k 1k Peripherals (CPLD UART etc)

RAMBAR ???? 8k Internal SRAM

MBAR ???? 1k Internal Peripherals

CPLD ???? ?? Peripherals decoded by CPLD

Is the CPLD driven from a Chip Select or does it separately decode the bus signals? If CS2 is sent to the expansion connector, does it also select BBRAM chips on the main board? Is there any selection logic to declare an address range within CS2's range that does not select any motherboard BBRAM chips? How are the 1M and 2M BBRAM chips selected? Are there any bus buffers between the CPU bus and the expansion connector? Does the current system have BBRAM chips on an expansion board, and you're intending to replace that board perhaps?

Tom

2,504 Views

Just for completeness, there is a design example of how to connect the CS8900 to the MC68302 in the CS8900A Ethernet Controller Technical Reference Manual - AN83. It does use one of the MC68302's chip selects so it's probably of no use in this situation but it does show the other glue logic required for the ISA bus interface.

Shaun

2,504 Views

> It does use one of the MC68302's chip selects so it's probably of no use in this situation

Why do you say that? A simple decoder chip on the extension board is all it needs to take that single chip-select and give you 4, or 8 (74138), or 16 (74154) separate chip selects. This has been standard hardware design practice since 74xx chips came out in the 1960's and 1970's. Here's a functional list:

https://en.wikipedia.org/wiki/List_of_7400_series_integrated_circuits

Here's my previous post showing standard address decoding:

http://research.cs.tamu.edu/prism/lectures/mbsd/mbsd_l16.pdf

Google finds this specific example (using RD and not chip-select, but it is the same principal):

http://tanmayonrun.blogspot.com.au/2011/06/addressing-5-rom-chips-each-of-4-kb.html

Another one, half way down this page:

http://www.ece.unm.edu/~jimp/310/slides/8086_memory2.html

Tom

2,504 Views

> Why do you say that?....

Because of a poor choice of words on my behalf Tom :smileywink:. Yes I am aware of how to do address decoding, prior to microcontrollers we never had internally generated chip selects and generally used 74138's as you say, or maybe a PAL/GAL for anything more complicated. What I meant was the the design example that I gave did not show how to do this as it was using a MC68302 internally generated chip select, it was only showing the other glue logic required to interface to the CS8900 that manjunath is using. You had already given enough examples in your post covering the generation of chip selects.

Regards, Shaun

2,504 Views

What sort of hardware is "CS4 ( Memory mapped Ethernet IO)"? The main board is very old, so is this some sort of 8-bit ISA-bus Ethernet chip, or what?

Tom

2,504 Views

Tom,

Thanks for your support.

CS4 is Memory Mapper Ethernet IO and currently we have CS8900 Ethernet controller (ISA bus, not 8 bit).

Main board is very old and development stopped some 7 years back. We have legacy tools, diab compiler and single step debugger both runs windows XP. Don't have proper debugger to analyze anything and no supported document on product.

We tried to use address decoder for CS2(which is available to expansion board) before, but any change in CSAR, CSMR for CS2 results in system crash. Still we are working on same to understand what exactly is cause of crash.

Current list available to us:

Chip Select Mapped Memory Start Address

CS0 Boot Flash

CS1 Flash Memory 0x00800000

CS2 Extended BBRAM (Expansion Board) 0x00600000

CS3 SRAM + Onboard BBRAM 0x00400000

CS4 Memory mapped Ethernet IO 0x00A00000

CS5 Memory mapped Peripheral IO 0XD0000000

CS6 Unused

CS7 Unused

CS6 & CS7 is not available due using A26 & A27 as WE0 & WE1 as PAR[ 3:0] = 0001

Peripherals decoded by CPLD: CAN, PC16552, LEDS, Test and some IO devices.

Linker file details:

MEMORY

{

vect: org = 0x00000000, len = 0x00000400

rom: org = 0x00000400, len = 0x000ffc00

bbram: org = 0x00600000, len = 0x00300000

ram: org = 0x00200000, len = 0x00160000

enetio: org = 0x00A00300, len = 0x00000100

enetmem: org = 0x00A01000, len = 0x00001000

inout: org = 0xd0000000, len = 0x00000800

mcfram: org = 0xe0000000, len = 0x00002000

sim: org = 0xf0000000, len = 0x00000200

cacheram: org = 0x00400000,len = 0x00100000 /* 0x00100000 Changed in 4.05.02 */

}

Regards,

Manjunath

2,504 Views

There's nothing in that part of the linker file you supplied for the Flash at 0x00800000. Where is that range defined?

It would have helped a lot if you'd have filled out the example table I provided with sizes and addresses in the one, tied to chip selects. You should also decode the CSMR values to list the decoded sizes. I've asked a lot of other questions you've ignored too.

The Linker shows 2M of "BBRAM" at 00600000, but your table shows Flash starting 2M above the start of that, at 00800000. They can't overlap.

> but any change in CSAR, CSMR for CS2 results in system crash

You would have to change the CS2 CSAR and "bbram:" in the linker file at the same time to match each other. That assumes the code is well written, and that the ONLY way that the code (boot code and application code) refers to that memory is via the linker definitions. If you're unlucky then there's a "#define" in there pointing something directly to 0x00600000 that is also used, or used instead. If you're unluckier, there might be more than one of these. Even worse, there could be a whole bunch of ones pointing to different addresses within 0x006nnnnn.

The code might even assume the onboard BBRAM and the offboard one have contiguous addresses and look like the one memory system.

> no supported document on product.

Your first job is to reverse-engineer the product and write that documentation.

If the code is well written then you can move any peripheral anywhere in the memory map as long as the linker definitions match the chip select decode.

You will need to move CS2 out of the way (as long as it doesn't require contiguous motherboard and expansion BBRAM) to makie enough room for your Flash. There's at least 3G spare. You'll need a decoder on the expansion board that breaks the CS2 space into regions decoded for the replacement BBRAM, extra NOR Flash and Ethernet.

> CS8900 Ethernet controller (ISA bus

Is that the one that's on the main board, the one you intend to use on the extension board or both?

Do you need two (slow and ancient 10BASE-T) Ethernet ports, or are you upgrading from 10BASE-T to 100BASE-T?

That's a little-endian chip (on a big-endian CPU, always very difficult to program) using the 16-bit ISA-Bus protocol. You'll have to wire the BBRAM and Flash to use the same bus timing. That could be difficult.

I can't give you any more help. This needs a proper hardware engineer to design this thing. I'm just doing this as a hobby.

Tom

2,504 Views

Tom,

Thanks for your support.

Your guidelines should help us in resolving all the issue. We working on hardware design and checking on software implementation also.

Thanks for your valuable inputs which helped in concluding few open points.

Regards,

Manjunath