• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 3 answers
  • Subscribers 31 subscribers
  • Views 806 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.

CCS/TMS570LC4357: Issue in accessing the complete SRAM addresses connected through EMIF

Shivam Kakad
Expert 1355 points

Part Number: TMS570LC4357

Tool/software: Code Composer Studio

Hi,

I am using the TMS570LC4357 controller, and as per my requirement i am connecting the FPGA and SRAM (CY62167EV30LL), through EMIF chip select 2 and 3 respectively.

As per my observation, 

When there is no code flashed in the FPGA, then SRAM could able to access complete addresses. i.e. from 0x64000000 - 0x641FFFFF, but when we flash the code in the FPGA, we could not properly(Unable to make the Data1 Pin to High ) able to access the first 256kb. i.e. from 0x64000000 - 0x640040000, and rest addresses are accessible.

I am not understanding, How the flashing FPGA code is affecting the SRAM though the chip selects are different for both the asynchronous devices. we observed the Chip Selects Pins on Oscilloscope, it is coming properly and even the Write enable(WE) and Output Enable(OE). The Pinmux configurations are also correct and mpu settings seems fine. we defined the region 5 and 8 for the FPGA (0x60000000 – 0x600007FF) and SRAM(0x64000000 – 0x641FFFFF) addresses respectively.

The EMIF configuration used for the FPGA and SRAM are same(we used the appropriate register for each configuration) as:

SS          (0)

EW          (0)

W_SETUP     (6)

W_STROBE    (10)

W_HOLD      (4)

R_SETUP     (6)

R_STROBE    (10)

R_HOLD      (4)

TA          (9)

ASIZE       (1)

&

emifREG->AWCC |= 0x10050001UL;

Can anyone please help me in this case?

Regards,

Shivam Kakad

(Unable to make the Data1 Pin to High )

  • 0
    TI__Guru**** 200276 points

    Hello Shivam,

    After FPGA configuration, a pin may be set to pull up, or pull down, or to remain floating (effectively tri-state) or be driven high or driven low, depending on the IO standard chosen. Please check your FPGA code.

  • 0 in reply to QJ Wang
    Expert 1355 points

    Hi Wang,

    Sorry, that i forgot to mention the details about the FPGA.

    There also we are putting it into the Tri-State.

    So. It may not be the issue.

    Regards,

    Shivam Kakad

  • 0 in reply to Shivam Kakad
    TI__Guru**** 200276 points

    Hello Shivam,

    "When there is no code flashed in the FPGA, then SRAM could able to access complete addresses..." I assume that the SRAM and FPGA use different chip selects (for example CS3 and CS2).

    CS2 (FPGA): the memory range is 0x6000_0000 ~ 0x63FF_FFFF

    CS3 (SRAM): the memory range is 0x6400_0000 ~ 0x67FF_FFFF

    1. Please probe the EMIF_DATA[0] before programming FPGA and after the code is flashed to FPGA, (CS3 is disabled, CS2 is enabled and disabled).

    2. If 0x6400_0000 ~ 0x6400_4000 is not accessible, the EMIF_ADDR[15] is pulled high all the time, please probe this pin before programming FPGA and after the code is flashed to FPGA, (CS3 is disabled, CS2 is enabled and disabled).

  • 0 in reply to QJ Wang
    Expert 1355 points

    Hi,

    Updates on this issue, Actually we required to change the Oscillator frequency from 16Mhz To 20Mhz, That we changed, but exactly the same behavior i am seeing, except the unaccessable address changed from 256kb to 512kb.(i.e. unable to write the last two data bit to 1 in the address range 0x64000000 - 0x641fe000). the oobservation is such that: 0xFFFC is able to write but not 0xFFFF in the given address range.

    Regards,

    Shivam Kakad

  • 0 in reply to Shivam Kakad
    TI__Guru**** 200276 points

    Did you probe the address pins and data pins mentioned in my last post?

  • 0 in reply to QJ Wang
    Expert 1355 points

    Hi Wang,

    On the EMIF_ADDR[15] Pin i am getting continuous high.

    Regards,

    Shivam Kakad

  • 0 in reply to Shivam Kakad
    TI__Guru**** 200276 points

    Hello,

    This is the reason that 0x6400_0000 ~ 0x6400_4000 is not accessible. Please figure out why EMIF_ADDR[15] is pulled high in your FPGA code.

  • 0 in reply to QJ Wang
    Expert 1355 points

    Hi Wang,

    here i have attached the image of memory browser about the memory address of attached SRAM through the EMIF.

    There you can see the different Memory windows that i have opened.

    and only in the window for the memory 0x64000000 (Memory Browser) and 0x64040000(Memory Browser <1>) i tried to write.

    My observations are:

    When I tried to write, "Memory Browser" at first location i.e. 0x64000000, the data as "FFFF"(Which is making the data0 Pin as 1), then instead of updating that memory location, it updated in the, "Memory Browser <1>" , "Memory Browser <3>" and "Memory Browser <5>".

    Whereas, When I tried to write, "Memory Browser" at other location i.e. 0x64000002, the data as "1234"(Which is not making the data0 Pin as 1), then it got updated in that memory location i.e."Memory Browser" along with "Memory Browser <2>" , "Memory Browser <4>" and "Memory Browser <6>".

    Again, When I tried to write, "Memory Browser" at first location i.e. 0x64000001A, the data as "A5A5"(Which is making the data0 Pin as 1), then instead of updating that memory location, it updated in the, "Memory Browser <1>" , "Memory Browser <3>" and "Memory Browser <5>".

    It is like in the Memory ranges of 256KB and 512KB the data is getting copied into the location.

    We again checked the EMIF_ADDR[15] There does not seem any issue now, it is behaving properly, as we send the data on the pins.

    Regards,

    Shivam Kakad

  • 0 in reply to Shivam Kakad
    TI__Guru**** 200276 points

    Hello Shivam,

    This phenomena may be caused by the code in FPGA. What happens if you erase the FPGA? 

  • 0 in reply to QJ Wang
    Expert 1355 points

    Yes Wang. You Might be correct. Because when we erased the FPGA code then it starts working properly.

    But How can we confirm say that it is causing because of the FPGA Code. Since, FPGA Code respond only when the chip select got detected.

    Secondly, Though, all the EMIF address lines are connected to the FPGA, we are just programming initial 10 emif address lines, which are required as per our application, which will be kept in a tri-state, when FPGA-Chip Select is not there. Remaining pins, which are not programmed, will be in by default, tri-state.

    So, what improvisation further the FPGA code is require?

    One more thing, We are disabling the Select Strobe for both the FPGA and SRAM, Does that affect? and AWCC is the common register for both the Asynchronous devices, then what could be the ideal value for that in this case?

    Additionally, we also observed that, changing the Clock Configuration the Observation Is varying, what could be the reason for that?

    Regards,

    Shivam Kakad

  • 0 in reply to Shivam Kakad
    TI__Guru**** 200276 points

    Hello,

    I am not familiar to FPGA coding, so I could not give you any suggestion.

    EMIF supports both normal mode and select strobe mode. Both mode should work. AWCC is only used when the external wait signal is required. There is no ideal value for max_ext_wait, it's up to the user depending on the application.