Connecting external SRAM to MCF5249 144-QFP

[OskarA]

Hi,

I'm currently working on software upgrades for a product based on MCF5249 processor in a 144-QFP packaging. The product hardware is connected to an external SRAM (http://download.cypress.com.edgesuite.net/design_resources/datasheets/contents/cy7c1021cv33_8.pdf) that has never been used before. The original developers connected an LCD screen to CS1, and the cypress SRAM to CS2. Development environment is Green Hill Multi.

Problem is when I move a char* into the external sram and try to sprintf a string to that variable. If I strcpy or memset the region, it behaves as expected (abcdefghij becomes abcdefghij). But if i sprintf the string "abcdefghij" to the cypress sram, I get "bbddffhhjj".

Can anyone explain this behavior, and how I might solve it? I am leaning towards initialization/setup error, but might be wrong? Is this possible at all?


Message Edited by OskarA on 2008-06-13 12:45 PM

[OskarA]

Thanks for the answer! Yes, it looks like you're correct, the BHE and BLE pins are connected to 0v. Does this mean it's impossible to write bytewise?

The hardware in question is already delivered to several customers, so changing the hardware layout is not a feasible option afaik . Hence, I'm looking for other possible software options. Some of the options I've come up with so far:

1. Would it be possible to configure the processor to not handle the CS region at lower than 16 bit size (ie, use entire 16 bit words for 8 bit bytes)?

2. Would it be possible to interdict read/writes to a specific CS somehow? Interrupt generation, etc?

3. Rewrite sprintf to handle the situation (basically doing the 1st option the long way in software, requiring lots of weird memory handling etc)?

Can anyone comment on the feasibility of these options?

[admin]

What I did in a similar situation was this:
a) write a subroutine for byte-wise writes to the SRAM (read word, change byte, write back word)
b) make sure that all write accesses to the SRAM are done with this subroutine
Naturally, this solution will not allow writing to SRAM with standard library functions (memcpy, sprintf), with pointers or by placing variables into SRAM. But you could get away with this if you only have a few large buffers in the SRAM (hopefully, not too much code to convert to use this approach).

[admin]

This sounds very much like improperly connected 16-bit SRAM. I don't know what the external memory interface on the MCF5249 looks like, but I've seen things like this on other microcontrollers. Most 16-bit SRAM's allow byte-wise writes, but sometimes (due to laziness or incompetence) they are set up to only allow word-wise writes. That's when you experience simptoms like the ones your describe.
You should check the connections to the SRAM. Changes to the PCB might be required. Again, I am not familiar with the MCF5249, so it could be a case of software misconfiguration.

Regards,
 - scifi