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.

Slow rising rate when switching PINMUX8 EMA_D[15] and GP3[7]

Hi,

TI DSP C6748 is used in our product now. Three devices are connected to DSP via EMIFA: FPGA(CS5), FLASH(CS2), and Dual-Port RAM(CS4). Our hardware design needs the following configuration: when accessing FLASH, bit 0~3 of PINMUX8 is set to GP3[7]; on the other hand, when accessing FPGA, bit 0~3 of PINMUX8 is set to EMA_D[15]. The GP3[7] is set to INPUT. It is found that the rising rate is slow when switching GP3[7] to EMA_D[15] and that will lead to incorrect results in FPGA. 

Attached images show the signals in scope for debug: Channel 1 is our internal debug signal, channel 2 is pinmux8 EMA_D[15]/GP3[7], channel 3 is chip select signal, and channel 4 is write enable signal. A slow rising rate of EMA_D[15] ( channel 2, DSP_LD15 ) is observed when DSP_nAWE and DSP_nCE5 signals are triggered. This will lead to incorrect results in FPGA. Can you help to give any advice for us to improve it? Thank you.

  • Weili,

    I hope you have connected two device under EMIFA port (FPGA & FLASH) and observed the slow rising at signal PIN GP3[7] when you switching GP3 [7] to EMA_D [15] in the PINMUX8 register and also you  observed the same when DSP_nAWE and DSP_nCE5 signals are triggered.

    Please explain are you seeing the slow rising edge in both the cases ?

    Have you tried reproducing the same issue in the C6748 LCDK board? You can probe the GP3 [7] pin at J14.18 Pin.

    Have you tired clearing the Rising Edge Interrupt Register for GP3 [7] pin?

    What about PCB Trace Length for the GP3 [7] pin ?

    Have you tried add some delay in between switching from GP3 [7] to EMA_D [15] in the PINMUX0 register?

    Regards

    Antony

  • Hi Weili,

    Have you resolved this issue?

    please help me to close this discussion if you resolved this issue.

    Regards

    Antony

    • --------------------------------------------------------------------------------------------------------
      Please click the Verify Answer button on this post if it answers your question.
      --------------------------------------------------------------------------------------------------------

     

  • Hi Antony,

    Sorry for the late reply. According to your advice, we do some tests below

    (1) Please explain are you seeing the slow rising edge in both the cases ?

    An measerment is performed for comparison: we stop DSP by CCS and manually switch EMA_D[15] to GP3[7]. We see slow rising rate in this case (from 0v to 3.3v and the rising time is 2.5 us). Is it normal or not?

    (2)  Have you tried reproducing the same issue in the C6748 LCDK board? You can probe the GP3 [7] pin at J14.18 Pin.

    Sorry we don't have this board.

    (3) Have you tired clearing the Rising Edge Interrupt Register for GP3 [7] pin?

    First we checked the two registers: SET_RIS_TRIG23 (0x01E2604C) and CLR_RIS_TRIG23 (0x01E26050). Both of them are 0x00000000. Is it correct?

    (4) What about PCB Trace Length for the GP3 [7] pin ?

    Sorry we don't have any information about it.

    (5) Have you tried add some delay in between switching from GP3 [7] to EMA_D [15] in the PINMUX0 register?

    Yes, we add some delay when accessing GP3 [7] and EMA_D [15] and it reduces error obviously. 

    Any advice or suggestions will be greatly appreciated. Thank you.

  • Weili,

    We can’t reproduce this issue in our board

    Moreover it’s a board level issue the maximum output current source by the I/O pin -6mA .Please check all your 3 loads and their  minimum input current requirements (Ii) and the input capacitance of each device includes PCB trace length. These are all some of the contributing factors for increase in rise time.

     Please refer the datasheet for the I/O electrical characteristics and EMIFA SDRAM Loading Limitations

    Try to isolate some loads and check once .I hope you already fixed by adding some delay between switching from GP3 [7] to EMA_D [15]

    Regards

    Antony 

  • Hi Antony,

    The test of adding delay between switching GP3[7] and EMA_D [15] was performed last week and  no error was found after several million read/write cycles. We think the results are reliable, and thank you for the good advice. 

    Weili