This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SDRAM issue

Hi All,

We have interfaced 1 SDRAM to LPC3250 (Lower 16 bit data line) .This SDRAM is from Micron technolgies 32 MB(MT48LC16M16A2).

Now problem is that we are not sure whether ,can we run our application code from the SDRAM ,because access from processor will be 32 bit wide , since we didn't connected anything on upper data line we will read junk values .

After seeing the refrence schematics provided by NXP we concluded that there is mistake in our hardware we should have connected 2 SDRAM (one on upper 16 bit and othe on Lower 16 bit) .

Question :

Is there still some way to run our code , can we build our code with THUMB instruction (16 bit)and run the code.

Please give your valuable feedback.

Thanks & Regards
Sumit

Parents
  • But if it is configuration problem then we should not write a single location properly,Can you provide any link where we can find some code (tested) where LPC3250 is interfaced with SDRAM on 16 bit interface for cross checking our code.

    Thanks & Regards
    Sumit

Reply
  • But if it is configuration problem then we should not write a single location properly,Can you provide any link where we can find some code (tested) where LPC3250 is interfaced with SDRAM on 16 bit interface for cross checking our code.

    Thanks & Regards
    Sumit

Children
  • "But if it is configuration problem then we should not write a single location properly"

    That is not correct. There are many configuration combinations - Some of those can appear to partially work.

  • If the processor thinks the memory interface is 32 bit wide but the interface is only 16 bit wide, you obviously have a good change that a 4 byte wide write at first address of the memory will result in two of the bytes being correctly saved (since they map to the existing 16 bits) and two bytes fails to save. If you only test using 16-bit integers, you will not notice this.

    Don't be so quick making assumptions. Only assume what you can prove. What you can't prove should be downgraded to maybe a suspicion. After all, a large percentage of all software errors are caused by people who have made incorrect assumptions.