• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 98 subscribers
  • Views 588 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

char pointer problem on omap l138

ayusman mohanty
Prodigy 210 points

Other Parts Discussed in Thread: OMAP-L138

 

Hi Everyone

 

I am currently working on OMAP-L138 custom board with DDR2(2Gbit, X16) at 150Mhz. I am facing some strange problem while declaring and using a string.In my code i have the following lines:

1.char a[ ]="hello";

2.printf("%s", a);

Output of the code:  ehll.o

Now while executing the 1st line , i can see that a memcpy() function is being called which transfers "hello'" from a source to a destination address. In this function itself while copying each char from the source to destination the address where it is stored changes.

This is the Source Screenshot at address 0xc109f912:

This is the destination screenshot at address: 0xc0f7ff0e

I have ran some simple memory copy statements and it works in the same way.Whenever I initialize them as char pointer it copies to the wrong location.For all other cases i.e short or int  pointers it works fine. Can anyone plz suggest how to solve this problem? Is it beacuse char is stored as 8 bit and integer as 16/32 bit. The same code works fine on the evaluation board.

 

 

Regards

Ayusman

  • 0
    TI__Mastermind 27585 points

    Can you check the DQM signals on your custom board? That looks like the behavior you would see if DQM0 and DQM1 were swapped. For 16/32 bit accesses, both DQMs are always active for each read/write. For 8 bit accesses, only one DQM is active for the write, but both are active for the read, which is why you would see the characters swapped.

    Jeff

  • 0 in reply to jc-ti
    Prodigy 210 points

    Jeff

     

    Thanks a lot.Swapping DQM0 and DQM1 solved the problem. I have done a thorough checking of my schematics and symbols and everything looks fine.Somehow the DDR is reading DQM0 as DQM1 and vice versa. Can there be any other issue? I even probed at the OMAP and DDR and I am getting correct waveforms.

     

    Regards

    Ayusman

  • 0 in reply to ayusman mohanty
    TI__Mastermind 27585 points

    You might want to check the layout files themselves. We have previously seen a customer where their schematic showed DQM0 and DQM1 hooked up correctly, but their board layout files had them swapped.

    Also your post is very similar to this one: http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/89025/328655.aspx#328655 Is this the same issue or a separate one?

    Thanks

    Jeff

  • 0 in reply to jc-ti
    Prodigy 210 points

    Jeff

    I have seen the board files.They look fine.I guess somehow the DDR2 pins are swapped but this case is very rare in ASICs. Also the other post also concerns the same issue.

     

    Regards

    Ayusman

  • 0 in reply to ayusman mohanty
    TI__Mastermind 27585 points

    The best way I can think to confirm this would be to set up a test that writes only to the lower 8 bits of the memory, with no readbacks. If you put a scope on the DQM pins, you should see the DQM[0] going low for each write, and DQM[1] staying high the entire time. If you see the opposite behavior then there is an issue. Are you seeing this across multiple boards and devices or just one setup?

    Jeff

  • 0 in reply to jc-ti
    Prodigy 210 points

    Jeff

    I did a similar test setup in CCS.I was writing to char pointers. When accessing the lower byte I got DQM0 going low and for higher byte DQM1 going low. But still I was getting the values swapped. But after swapping the DQM lines it worked properly. I have seen this issue so far in the 3 boards I have populated. I assume since the DQM0 and DQM1 lines are driven by OMAP and OMAP is generating them correctly so the issue must be with DDR. Can this be possible?

    Ayusman

  • 0 in reply to ayusman mohanty
    Prodigy 210 points

    Jeff

    It came to my mind that the same problem can be also solved by swapping DDR_A0 and DDR_A1 bits. Then it will provide the same result as swapping DQM bits.Can you tell me is there any way in CCS we can see exactly what values does the OMAP DDR2 controller sets via EMR,MR etc registers.

    Ayusman

  • 0 in reply to ayusman mohanty
    TI__Mastermind 27585 points

    If you want to see the address values that come out of the DDR controller, the only way is to probe the bus itself.

    Have you verified that swapping A0 and A1 fixes the issue? I would think even if the address pins were swapped when writing data, they would still be swapped when reading back so the data wouldn't be corrupted like you are seeing.

    Can you use the CCS memory window to try some experiments? In the memory window you can change the data type to 8, 16, or 32 bit accesses. Try writing values in each access mode and refreshing the memory window to read them back. The 8 and 16 bit accesses output identical addresses and only the DQM signals change to specify which byte is being written to.

    Jeff

  • 0 in reply to jc-ti
    Prodigy 210 points

    Jeff

    I am sorry I got confused for a moment. Swapping A0 & A1 lines will not solve the problem.If A0 and A1 were swapped then 16 bit acces will never work properly  Actually 16- bit and 32 bit access are fine using in CCS. It is just that 8 bit access is getting swapped.Reading them from memory is fine.Its while writing that it gets swapped. I have probed at OMAP and it is generating DQM correctly and layout is fine.Can there be a possibilty that any other setting we are missing out or something??

    Ayusman

  • 0 in reply to ayusman mohanty
    TI__Mastermind 27585 points

    The only other way this could happen is if DQ0-7 were swapped with DQ8-15, but I assume that this is not the case.

    Can you try changing the software timings and PLL frequencies to see if that affects anything? It looks like the controller is behaving correctly from what you've told me, so it is either related to the board or the specific memory you are using.

    Jeff