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.

TMS570LC4357 EMIF cs singnal looks strange

Other Parts Discussed in Thread: TMS570LC4357

Hello, Ti experts,

We are using TMS570LC4357 to control device through external bus. The asynchronous interface of EMIF is used. The VCLK3 is configured to 37.5Mhz. And other configuration as below

  emifREG->CE3CFG = ((U32)0U  << EMIF_BIT_SS)       |
                    ((U32)0U  << EMIF_BIT_EW)       |
                    ((U32)2U  << EMIF_BIT_W_SETUP)  |
                    ((U32)12U << EMIF_BIT_W_STROBE) | 
                    ((U32)2U  << EMIF_BIT_W_HOLD)   |
                    ((U32)10U << EMIF_BIT_R_SETUP)  | 
                    ((U32)20U << EMIF_BIT_R_STROBE) | 
                    ((U32)2U  << EMIF_BIT_R_HOLD)   |
                    ((U32)3U  << EMIF_BIT_TA)       |
                    ((U32)1U  << EMIF_BIT_ASIZE);     

After looking at the waveform, we find some thing different from our expect. The CS signal of write is extramly extended, but the configuration is 2 clocks.

Waveform is :

Then we try to change the mode from normal to strobe. We expect the CS signal would as long as WE. Yes, this is as our expect. Except there are two more periods of CS signal.

And the wareform is:

That is strange for us. It seems there is peroid of CS has to be low after writting. And it can not be elimated.

How could this happen? Would you mind to give us some clue?

Thank you

  • Hello,

    In normal mode, the chip select is active for the entire duration of the access. This is what you observe as well.

    In select strobe mode, the chip select is only active during the strobe period of an access, which is what the waveform shows.

    What is the issue here?

    Regards,

    Sunil

  • Hello, Sunil

    The strange part is in write operation. The configuration of hold time is 2, as same as setup time. So in normal mode waveform,  CS signal is expected to have  2 clocks extra part both behind and after WE signal.

    There is almost 2 clocks part before WE signal, but the part WE signal is much more than 2 clocks.It looks like:

    In the strobe mode, things become more crazy. There are extra CS singal without WE or OE signal. That means CS signal is pull low for neither write or read.

    That is the abnormal part for me.

    hechao 13124/inovance,

  • Hello,

    Can you please include the code that you are using to make these accesses?

    Regards,

    Sunil

  • Hello, Sunil

    Our code are sperated into several parts.

    First , the macro for addres:

    #define MVB_DEVICE_ADDR_TCM  0x64026000L
    #define MVB_REG_ADDR_TCM      0x64028000L

    Second, assign the addres to variables:

     cch_data_reg    = MVB_DEVICE_ADDR_TCM;
     cch_stat_reg    = MVB_DEVICE_ADDR_TCM + 4;

    Third, define macro for operation:

    #define cch_get_reg(address) ((CCH_BYTE)(*((CCH_VOLATILE CCH_BYTE*)address)))
    #define cch_put_reg(address, data) (*(CCH_VOLATILE CCH_BYTE*)address = (CCH_BYTE) data)

    #define cch_tx_ready() ( (cch_get_reg(cch_stat_reg) & cch_stat_txe) == cch_stat_txe )
    #define cch_rx_ready() ( (cch_get_reg(cch_stat_reg) & cch_stat_rxf) == cch_stat_rxf )

    CCH_BYTE is define as char, and CCH_VOLATILE is key word volatile

    Finally, call the macro to read or write, here is a sample for writting:

    cch_put_reg(cch_data_reg, *p_packet);

    We wish this code helpful.

  • Hello Jules,

    I replied your email with my answer.

    This delay on nCS signal is expected.

    There was a EMIF bug in revA silicon: (Device #39)

    Extra WE/OE pulses are generated in asynchronous EMIF accesses. Write: Extra WE pulses are generated for all writes (8/16/32/64bit) . There would be at most two extra WE pulses. Read: All reads (8/16/32/64 bit) behaves like 64 bits reads at the EMIF port..

     

    This bug has been fixed on revB silicon. The extra WE pulses are removed, but the nCS signal remains the same. This delay doesn’t impact your memory operations (erase/read/write/etc).