• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 99 subscribers
  • Views 1737 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.

access to 16-bit SRAM through GPMC

lidong feng
Prodigy 10 points

AM35X datasheet: the device does not provide the A0 byte address line required for random-byte addressable 8-bit wide device interfacing (multiplexed and non-multiplexed protocol). Hence, an 8-bit device must be connected to the D[7:0]/gpmc_d[7:0] data bus (rather than D[15:8]/gpmc_d[15:8]) of the GPMC controller. This limits the use of 8-bit wide device interfacing to byte-alias access.

AM35X datasheet: External asynchronous or synchronous 8-bit wide memory or device. 

I plan to access to 16-bit SRAM, picture is schematic. GPMC no A0, how does GPMC read every single byte of SRAM.  nBE0 and nBE1 can work to access single byte?

  • 0
    Guru 31670 points

    You are right. nBE0 and nBE1 will provide the single access byte. nBE1 will enable the upper byte and nBE0 will work as lower byte enable. 

  • 0 in reply to Renjith Thomas
    Prodigy 10 points

    Hi  Thomas

          Thanks a lot!   

          Our plan is that  OS nucleus  Instruction Fetch  from nor flash, data place in SRAM, we will remove DDR2. Doing this is for safety. 

           Our first version hardware can't succeed,  maybe SRAM's single byte access is our problem. So we will change our hardware in version 2.  Maybe we will make this program succeed next version.

         Thanks for your help! 

          This is V1 schematic

  • 0 in reply to lidong feng
    Guru 31670 points

    Just one more doubt. Where is NOR_A1-A16 and GPMC_A1-A4 connected to? Can you share the other side of the schematics?

  • 0 in reply to Renjith Thomas
    Prodigy 10 points

    AM35X 's Multiplexed address data mode.

    I use a  D-Type Latch to latch address line


  • 0 in reply to lidong feng
    Guru 31670 points

    This is just for my understanding. 

    What was the behavior that you saw in the previous revision of board? As you were running from NOR flash, could you connect the JTAG and see some instructions getting executed? Also using debugger were you able to see the memory dump of SRAM? 

  • 0 in reply to Renjith Thomas
    Prodigy 10 points

    I can run code which I write on nor flash,  But I can't  run OS (nucleus) on Nor.    We doubt it is reason that AM35X can't access to SRAM 's  every signal byte.  So,this morning I Fetch Instruction from Nor, data place in DDR, OS can run now. 

    LiDong

  • 0 in reply to lidong feng
    Guru 31670 points

    What was the memory usage of your code and nucleus image. Where was nucleus getting stuck? Or was it not even booting at all? What is the capacity of DDR? 

  • 0 in reply to Renjith Thomas
    Prodigy 60 points

    Hi Thomas,

    I am colleague of Lidong Feng.

    In fact In our system, we put code in Nor flash, and data in SRAM. ( from compiler point of view, we put .text and .rodata segments in rom(nor flash) , .data and .bss segments in ram (SRAM) ).

    I can debug my code from Nor flash, but data abort exception occurs when CPU accesses data from SRAM. I tested SRAM and found it can access by word mode, but can not access by byte mode.

    Another question, during compiler, how many bytes is assigned for a char type variable? one byte or 2 bytes?

    If it is 1, I think CPU can not access it since SRAM can only be accessed by word mode, right?

    thanks a lot.

     

  • 0 in reply to Zhifeng Zhang1
    Guru 31670 points

    You are 99% correct in your observation. Also the char variable is 1-byte sized. 

    But one thing I didn't really understand is that why will ARM get a data abort? Because, If you see from the SRAM side UB/LB is grounded. Even if the any address is referred its same patterns will be given to SRAM. Say for example, if I do a read access at the address 0x1000, all of the waveforms will be same except for BE0/BE1 even if the access is a byte or 2bytes as the bus is always 16-bit. So the GPMC interface gets the data back, and why it should result in a data abort. 

    Have you tried a byte access at an even(0x1000) and odd(0x1001) saw the same behavior?