MCF52233 and external RAM

[RValls]

Hi all. I have a doubt regarding the MCF52233: can it manage anyhow an external RAM, so I can expand the 32 kb of the uC?

I have this doubt because I have run out of in chip RAM, but I have an external SPI EEPROM, which I want to use as a RAM memory, so I haven't got to change the board nor the program.

It would be fine if I can manage it using the .lcf, and (maybe?) handling the exception error to access to the external memory.

Can something like this be done?

Thanks in advance,

Ruben

[TomE · Accepted solution]

For external memory you really need the MCF5225x (in 144 pin package) with the 8-bit "Mini Flexbus" or the MCF5227x with the full Flexbus.

The 5223x chips all have 32k RAM, but some models have 256k of FLASH.

> I have an external SPI EEPROM, which I want to use as a RAM memory,

> so I haven't got to change the board nor the program.

What's so hard about changing the software? The normal thing to do at this point is to find out where the software is wasting memory and to fix it and make it more efficient. You can often trade off FLASH use against RAM use too. There may be a lot of "constant data" which is being copied into RAM when it doesn't need to be. There may be word-flags that can be packed into bits or bytes. There may be data that can be simply compressed. The code can be rearranged to allow a smaller stack. There's almost always a way to use RAM more efficiently. That means more employment for us programmers too :smileyhappy:.

Why not provide details on why you've run out of memory? What has changed? That may give clues to better suggestions.

> It would be fine if I can manage it using the .lcf, and (maybe?) handling the

> exception error to access to the external memory.

That is going to be stunningly slow. It would be better to explicitly manage the ERPROM like a disk drive than to trap accesses.

If you've added a function than needs "more RAM" and can use the slow EEPROM instead, then make it use the EEPROM explicitly. Remember also that you can wear out the EEPROM, so you have to limit the writes.

But emulation assumes the Coldfire chips can "trap and emulate" memory accesses. That would require something like a "virtual machine emulator" able to trap instructions accessing particular addresses, decode the instructions, emulate them and then continue. That requires a "non-existent memory access trap" or a Bus Timer (so the bus timeout can trap the CPU).

This chip has an "IPS Bus Timeout Monitor", but it looks like it only monitors "IPS Bus Addresses", which are probably cycles that match on the IPSBAR Register and NOT any other addresses in the chip. It may trap on some of the "Reserved" ranges in the 1G IPS address space, but you'll have to test this. The only documentation is:

The IPS controller implements a bus timeout monitor to ensure that every IPS bus cycle is properly terminated within a programmed period of time. The monitor continually checks for termination of each IPS bus cycle and completes the cycle if there is no response when the programmed monitor cycle count is reached. The error termination is propagated onto the system bus and eventually back to the ColdFire Core.

That doesn't say it will TRAP the instruction. It says it will "complete the cycle". It may signal an error during the cycle, or it might signal too late (for it to be emulated). it doesn't say WHICH error gets back to the core either. The manual also warns:

Accessing reserved IPSBAR memory space could result in an unterminated bus cycle that causes the core to hang. Only a hard reset allows the core to recover from this state. Therefore, all bus accesses to IPSBAR space should fall within a module’s memory map space.

So it might not work anyway.

There's a far bigger problem though.

There's nothing in this chip to capture the Address and the Data of the failed write. If you knew exactly which instruction generated the trap you could disassemble it, emulate it, back out any register increment/decrement operations (difficult) generate and work out where the data came from that was written and then copy that. This is NOT easy!

There's a far bigger problem though.

3.3.4.1 Access Error Exception

The V2 ColdFire processor uses an imprecise reporting mechanism for access errors on operand writes. Because the actual write cycle may be decoupled from the processor’s issuing of the operation, the signaling of an access error appears to be decoupled from the instruction that generated the write. Accordingly, the PC contained in the exception stack frame merely represents the location in the program when the access error was signaled.

So you can't even know which instruction failed. There's no way back from this.

That means you could emulate reads from ROM (which you've got plenty of) but not writes to RAM which is what you want.

Then there's the possibility of using the registers in the Debug Module to trigger a Debug Interrupt on an address range access. The problem here is that there are no registers provided to capture the ADDRESS and DATA of the write (like the PPC-based CPUs like the old MPC860 have), so you still can't write to the emulated RAM. These chips don't have MMUs and don't have virtual traps. So you just can't do that sort of thing.

You're going to have to change the chip or change the software.

[RValls]

Though it has passed a lot of time, thank you for your detailed answer.

Yes, that is what I was thinking, just changing the chip would be the easiest way, but I wanted to know if there was any other possibility that I hadn't seen to have more RAM using the same chip.

By the way, I have managed to free some RAM space and didn't even needed to change the hardware :smileygrin:

Thank you again and best regards,

Ruben