• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 888 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.

TMS570LS3137: TMS570LS3137: issue on EMIF's connection with asynchronous RAM

ting zha1
Prodigy 70 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN,

Dear TI expert,
Background:
(1)We tried to use 16-bit R/W mode to connect an asynchronous RAM chip(MR4A16B), EMIF_BA[1] is connected to A0-bit;
(2)Hardware design refered to TRM Figure 17-8 b) blockdiagram;
(3)HALCOGEN: 90MHz vclk3, 16-bit, non-page R/W mode, CS[2], other configuration DEFAULT;

Issue we discoverd in debugging:
When we only wrote data:0x0102 to address:0x60000000
We found:
Address: 0x60000000~0x6000000F
Data we read: 01 02 01 02 01 02 01 02 01 02 01 02 01 02 01 02；

Meanwhile, at following address, we read the same data group as below:
0x60000100~0x6000010F,
0x60000200~0x6000020F,
0x60000300~0x6000030F,
0x60000400~0x6000040F,
0x60000500~0x6000050F,
0x60000600~0x6000060F,
0x60000700~0x6000070F

According to ERRATA EMIF #4 Version D(Litera4101.HAL1_CCS.zipture Number: SPNZ222B),
The configuration of Region 5 is: Start address"0x60000000"，Size：64M， type：STRONGLYORDER_SHAREABLE. permission：PRIV_RW_USER_RW_EXEC.
We tried all other types of congfiguration. Results are the same with result above.

According to description and attemptation above, we are really looking forward to require any suggestions or ideas from TI experts.

Any kind of reply will be great!

My e-mail: zhat@sciyon.com

  • 0
    TI__Guru**** 199016 points

    Hello Ting,

    1. To write data to Asyc EMIF memory correctly, the memory has to be configured as device type or strongly-ordered type using MPU.

    2. Please lower the EMIF clock speed. The EMIF clock is configurable. Increasing the VCLK3 divider will lower the EMIF clock frequency.

  • 0 in reply to QJ Wang
    Prodigy 70 points

    Sorry, the progress of updating this question has been delayed for a while.

    1. strongly-ordered is a default configuration in R4-MPU-PMU region 5; also we has changed other types and It doesn't seem to affect.

    2. VCLK3 in 20M/45M/90M are performed and it also has no effert.

    Additionally, further information about this debug as:We just tried a single 16_bit write operation.CS[2], OE, WE, UB ,LB and DATA lines look like working according to the timing waveform(TMR figure17-11), 

    BUT EMIF_A/EMIF_BA works abnormally. EMIF_BA[1],EMIF_A0~EMIF_A2 always keeps 0, EMIF_A6~EMIF_A8 always keeps 1, EMIF_A3~EMIF_A5 could perform high/low level as required.

    Attachment pictures are print-screen of oscilloscope: CS[2] with other control signal.

    My question is : is any other configuration for this EMIF application in asynchronous R/W? Why do some address bits look like in stuck situation？

  • 0 in reply to ting zha1
    TI__Guru**** 199016 points

    Hello,

    Checked your HALCoGen configuration:

    1. Your memory is configured as 8-bit rather than 16-bit. Doesn't match with MR4A16B which is 16-bit.

  • 0 in reply to QJ Wang
    Prodigy 70 points

    well, in EMIF_CE2CFG ASIZE is revised as 1 in debug code(could be seen in the screenshot of IDE register ).

  • 0 in reply to ting zha1
    TI__Guru**** 199016 points

    OK, you modified the memory width manually. Please check the following address signals in your PCB layout:

    1. EMIF_BA[1], EMIF_A0, EMIF_A1, and EMIF_A2 are shorted to GND

    2. EMIF_A6, EMIF_A7, and EMIF_A8 are shorted to 3,3V

  • 0 in reply to QJ Wang
    Prodigy 70 points

    I can confirm that these address bits are not shorted to GND or VCC on the PCB wiring. When the power is off, the address line to VCC is about 8.4M ohms, and the address line to GND is high impedance. In addition, the pin multiplexed with N2HET, when configured as N2HET, can also perform level inversion as required. Therefore, I would like to know whether this may be another anomaly similar to SILICON Errata D, EMIF # 4

  • 0 in reply to ting zha1
    TI__Guru**** 199016 points

    Hi Ting,

    It is not related to EMIF#4 since you use device mode for 0x60000000 memory region.

  • 0 in reply to QJ Wang
    TI__Mastermind 49120 points

    Can you check whether the mpuInit() function is called during the device initialization? This is not done automatically by the start-up sequence generated by HALCoGen, and needs to be manually called.

  • 0 in reply to Sunil Oak
    Prodigy 70 points

    Thanks for your replying, _mpuInit_ () and _mpuEnable_ () have been added in the initialization part of the application.

    like this before the data write:

    //.......

    _mpuInit_ ();

     _mpuEnable_ ();

    emif_ASYNC1Init();

    ....

    while(1)

    {

    //write data to 0x6000000 test

    ...

    }

    //......

    In addition，a test is being performed today, the purpose is to test whether the pin altering in NHET application. Configure the C4 pin as the NHET2 [11] function (EMIF_ADDR [6] / RTP_DATA_13 / HET2_11). Only when the PSL is selected as pullup, the actual output can execute the level altering, and cannot be executed when pulldown or not selected. In our connection of EMIF application, there is no external pull-up / pull-down in address and data lines. Will this affect?

  • 0 in reply to ting zha1
    TI__Guru**** 199016 points

    No, pull-up or pull-down is not required for EMIF address signals.

    Please check if EMIF_FUNC bit (bit 31 of GPREG1) is set. Setting this bit is to enable the EMIF functions to be output. This bit is not used in other devices: TMS570LC43x, TMS570LS20x, 

  • 0 in reply to QJ Wang
    TI__Guru**** 199016 points

    Just wrote a test case for you to test your async memory:

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/312/5734.TMS570LS3137_5F00_SRAM_5F00_Ting.7z

  • 0 in reply to QJ Wang
    Prodigy 70 points

    Thank you for your reply. After EMIF_FUNC bit (bit 31 of GPREG1) is set to 1, M-RAM can read and write normally. Thanks to all experts who provided suggestions, this problem was temporarily resolved and closed.