• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 552 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.

Issue with EMIF (RM46L852ZWT / Asynchronous SRAM)

baptiste besson
Prodigy 150 points
Other Parts Discussed in Thread: HALCOGEN

Hi,

I am using an ARM RM46L852ZWT on a TI developpment kit.

I am trying to use the EMIF module to communicate with an external 8-bit asynchronous SRAM.

I have set up the EMIF module using HALCoGen 03.06.00.

My settings are :

  • enable EMIF Async1 / Disable others
  • EMIF clock = 110 MHz
  • EMIF Asynch1 : normal mode, extended wait disable, ASIZE = 8 bits, Setup=2, Strobe=3, Hold=2 for read and write, TA=0

I have alos checked in R4-MPU-PMU settings for Region 5 (EMIF Chip Select 2 asynchronous memory region)

  • Enable MPU region
  • Base address  = 0x60000000
  • Type = strongly ordered sharable
  • Permission = read/write in privilege mode / read/write in user mode

I have started with a simple test programm just to write correct data in the EMIF external memory for chip select 2 starting at address 0x60000000.

The external SRAM is not connected and I am just checking signals on the EMIF port with an oscilloscope.

I have tried writting bytes, short and int and it seems to works pretty well. I have ckecked data bits, CS, WE.

Bit value and signal timing are OK with my settings.

BUT, when I am looking at the address on the EMIF address bus, nothing changes except BA[0] !

It looks like I am alternatily writting at address 0x60000000 and 0x6000001.

Does someone have any idea how to figure it out ?

Here is my HALCoGen and CCSv5 projects : 6445.10-EMIF Project.zip

Here is somme screenshots of my signals (10 tests for writting byte, short or int) : 1321.10-EMIF ScreenShots.zip

Thanks.

Bapt

  • 0
    TI__Guru 68920 points

    Bapt,

    Looking at your test case, it seems you're only writing to addresses 0x60000000, 0x60000004, and 0x60000008 although since you are writing some short and some int, the 8-bit emif will break these up into individual 8 bit accesses so you would expect to see a write to 0x60000001 on the bus as well.

    Just spot checking then, I see one screenshot where more than just BA[0] is toggling  (02-address_0x12345678.png which also shows A[1]).   However I don't think A[1] is correct in this picture for a write to address 0x60000000.

    Still, with just these addresses being used I think you only need to look at BA[1:0] and A[1:0] and I would not expect activity on A[7:2].   Do you have a different expectation?

     

  • 0 in reply to Anthony F. Seely
    Prodigy 150 points

    Hello Anthony,

    Thank you for your quick answer.

    I found two errors in my previous test program :

    1. I did not use BA[1] so I was checking BA[0], A[1], A[2], A[3], A[4], A[5], A[6] and A[7]
    2. I forgot to enable the EMIF device in HALCoGen.

    I have corrected this and I am now checking the following addresses pins :

    BA[0], BA[1], A[0], A[1], A[2], A[3], A[4] and A[5] that I should connect to pins A[0] to A[7] of my SRAM.

    I have tried writing unsigned int at the following addresses :

    1. 0x12345678 to address 0x60000044
    2. 0x89ABCDEF to address 0x60000028
    3. 0xCDEF89AB to address 0x60000058
    A[2], A[3], A[4] and A[5] are correct. BA[0] as well. During the 4 consecutive byte writes, BA[0] goes low/high/low/high.
    HOWEVER : 
    1. BA[1] is always high
    2. A[0] and A[1] are always low
    It seems very strange behaviour to me.
    Any idea ?
    Sincerely yours,
    Bapt
  • 0 in reply to baptiste besson
    Prodigy 150 points

    Hello Anthony,

    I have found the solution.

    There are some EMIF address and control signals that are multiplexed with N2HET2 signals. For applications that require the use of these N2HET2 signals, it is inconvenient if the EMIF starts driving these address and control signals as output after reset is released and before the application can configure the I/O Multiplexing Module registers. Therefore, these EMIF signals are blocked from being output by default. This is done by using the bit 31 of the system module General Purpose Control Register (GPREG1). This bit is cleared (0) by default. In this condition, these EMIF/N2HET2 terminals are configured as inputs and pulled down. An application that requires the EMIF functionality must set the GPREG1[31] bit. This causes the EMIF address and control signals to then be output on the EMIF/N2HET2 terminals when the EMIF functionality is selected via the IOMM output  multiplexing control registers.

    Thank you for your help.

    Bapt.