• State
  • Locked Locked
  • Replies 14 replies
  • Subscribers 31 subscribers
  • Views 952 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.

Original question:

TMS570LC4357: TMS570LC4357

TMS570LC4357: TMS570LC4357 EMIF 16bit addr/data async(nor flash) mode

hu jiangbo
Prodigy 150 points
Part Number: TMS570LC4357

hello!

     I config the emif moudle work on normal mode,16bit data and addr,async mode,CS4,no externed wait.

     I write data to fpga by the function:(ASRAM_EMIF_CS4_START_ADDR is 0x6800 0000)

     void Emif_WrData(uint16 WrAddr, uint16 WrData)
    {

         EmifMSG.Start_Addr_wr = WrAddr + ASRAM_EMIF_CS4_START_ADDR ;
         XMEM_ps = (uint16*)(EmifMSG.Start_Addr_wr);
        *XMEM_ps = WrData;
    }

    I send the data 0x0004 to fpga's address,but the nWE pin is pulled down two times，the first time emif send 0x00 00，the second time emif send 0x00 04.see the picture:

    

    I guess the actual data 0x0004 is divided to two byte:0x00 and 0x04, then emif moudle make the 0x00 to 0x0000,the 0x04 to 0x0004,and send to fpga.

    I would like to ask how to solve this problem on the TMS570 side，not on the fpga side?

thanks!

  • 0
    Prodigy 150 points

    the init code  as follows:

    PINMUX_EMIF_OUTPUT_ENABLE(ON);

    void emif_ASYNC3Init(void)
    {

    emifREG->CE4CFG = 0x00000000U;
    emifREG->CE4CFG = (uint32)((uint32)0U << 31U)|
    (uint32)((uint32)0U << 30U)|
    (uint32)((uint32)2U << 26U)|
    (uint32)((uint32)5U << 20U)|
    (uint32)((uint32)2U << 17U)|
    (uint32)((uint32)2U << 13U)|
    (uint32)((uint32)5U << 7U)|
    (uint32)((uint32)2U << 4U)|
    (uint32)((uint32)1U << 2U)|
    (uint32)((uint32)emif_16_bit_port);

    emifREG->AWCC = (emifREG->AWCC & 0xC0FF0000U)|
    (uint32)((uint32)emif_pin_high << 29U)|
    (uint32)((uint32)emif_pin_low << 28U)|
    (uint32)((uint32)emif_wait_pin0 << 20U)|
    (uint32)((uint32)0U);

    emifREG->PMCR = (emifREG->PMCR & 0xFF00FFFFU) |
    (uint32)((uint32)0U << 18U)|
    (uint32)((uint32)emif_4_words << 17U)|
    (uint32)((uint32)0U << 16U);
    }

    the wr/rd code as follows:

    void Emif_WrData(uint16 WrAddr, uint16 WrData)
    {

    EmifMSG.Start_Addr_wr = WrAddr + ASRAM_EMIF_CS4_START_ADDR ;
    XMEM_ps = (uint16*)(EmifMSG.Start_Addr_wr);
    *XMEM_ps = WrData;
    }

    uint16 Emif_RdData(uint16 RdAddr)
    {
    uint16 RdData = 0;

    EmifMSG.Start_Addr_rd = RdAddr + ASRAM_EMIF_CS4_START_ADDR ;
    XMEM_ps = (uint16*)(EmifMSG.Start_Addr_rd);
    RdData = *XMEM_ps;

    return RdData;
    }

  • 0 in reply to hu jiangbo
    Prodigy 150 points

    I send 0x5A6B to fpga,and the wave as follows:

  • 0 in reply to hu jiangbo
    Prodigy 150 points

    I select the nor flash mode in the HCG,the picture as follows: .

    Will this choice result in the above results？

  • 0 in reply to jagadish gundavarapu
    Prodigy 150 points

    Hello：

        I enable the mpu can solve the emif's nWE signal problems as your advice.

       But enable the mpu often cause the code run away into the invects table-DataEntry. I try to resolve this problem some time,and then  cause a new problem that I cannot debug the code,the ccs error as below picture:

        the detial discribe as below:

        CortexR5: GEL Output: Memory Map Setup for Flash @ Address 0x0CortexR5: Error initializing flash programming: Target failed to read 0xFFFFFFF0
        CortexR5: Loader: One or more sections of your program falls into a memory region that is not writable. These regions will not actually be written to the        target. Check your linker configuration and/or memory map.
        CortexR5: File Loader: Verification failed: Values at address 0x00000000 do not match Please verify target memory and memory map.
        CortexR5: GEL: File: C:\Users\hjb\Desktop\Test_TMS570LC_OS1008\FLASH\Test_TMS570LC_OS.out: a data verification error occurred, file load failed.

        I try to restart CCS、PC、Development Board，and reconnect the xds100v2, but still unable to solve it. Can you tell me what the reason is？please！

    Thanks！

  • 0 in reply to hu jiangbo
    Prodigy 150 points

    hello:

        I change the ARM JTAG to debug the code,and successful.Then I use the xds100v2,it is also working.It's really strange!But，this problem can be considered resolved.

        The code often run away into the invects table-DataEntry after I enable the mpu. Can you tell me what the reason is？please！

        The mpu config is the default config by HCG as pictures below:

              

  • 0 in reply to hu jiangbo
    Prodigy 150 points

    hello:

        I find that I can not control the adrress bit0 and bit1 after enable the EMIF MPU， the code running ok when I control adress bit15-2. Is this phenomenon right？what is the reason?

        I want to know can I control the address bit 21-16 when the emif working  under such conditions：16bit data mode，async mode？if yes，how to config?

    Because I find that the nWE signal was pulled down twice  in one CS low period when I control the address bit 21-16(the emif mpu was enabled).

    Thanks very much!

  • 0 in reply to hu jiangbo
    TI__Guru**** 196926 points

    Hi Jiangbo,

    I will review your settings and come back to you later today.

  • 0 in reply to QJ Wang
    TI__Guru**** 196926 points
    hu jiangbo said:
    I can not control the adrress bit0 and bit1 after enable the EMIF MPU，

    Do you mean the address pins A0 and A1? or the logic address bit 0 or bit1?

    The EMIF address pin EMIF_A[0] always provides the least significant bit of a 32-bit word address. EMIF_A[0] is mapped to address bit[2]

    The address bit 0 and address bit 1 are not controlled by EMIF_A[0] pin and EMIF_A[1] pin. For 16-bit asynchronous device, the EMIF_BA[1] and EMIF_BA[0] pins provide the least-significant bits of the halfword or byte address, respectively.

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

    Hi Jiangbo,

    hu jiangbo said:
    I find that the nWE signal was pulled down twice  in one CS low period

    One additional WE pulse is observed on the EMIF outputs on RevA Silicon. But the problem has been fixed on RevB silicon.

    Can you configure the Async EMIF memory region to MPU device mode? 

  • 0 in reply to QJ Wang
    Prodigy 150 points

    I mean maybe the logic address bit 0 and 1,because I don't quite understand the principles.

    My development steps are as follows：

    1、write the data-0x5A6B to address 0x68000003 without enable the mpu,the code as follow: (*(uint16*)(0x68000003)) =0x5A6B;

          but the nWE signal was pulled down twice  in one CS low period, the first time send 0x5A00 to fpga,the second time send 0x006B to fpga.

           so I enable the mpu  and the mpu configuration as above shortcut pictures.

          Then I still run the  (*(uint16*)(0x68000003)) =0x5A6B; the system code will run away and into the Abort invect (dataEntry) where in the file named        "HL_sys_intvecs.asm".

    2、I try to write the data-0x5A6B to address 0x6800000C with the mpu:(*(uint16*)(0x6800000C)) =0x5A6B;

         Then the system code run normal , the nWE signal was pulled down one time,and directly send 0x5A6B to fpga.These results are exactly what I hope to see.

         Then I test run these code:(*(uint16*)(0x6800FFFC)) =0x5A6B was run ok; (*(uint16*)(0x6800FFF1)) =0x5A6B was run away;(*(uint16*)(0x6800FFF2)) =0x5A6B was run away;

         so I find I can't operate the bit0 and bit1 of the 0x68000000 in the background of enable the mpu function.

    I don't quite understand the principles!

  • 0 in reply to QJ Wang
    Prodigy 150 points

    How can I distinguish which version（RevA Silicon and RevB silicon） of my chip is?

  • 0 in reply to hu jiangbo
    Prodigy 150 points

    The symbols marked on the top of  my chip is TMS570LC4357BZWT***, it means my chip is RevB silicon.But still occurred the  nWE signal was pulled down twice  in one CS low period.

  • 0 in reply to hu jiangbo
    TI__Guru**** 196926 points

    Hi Jiangbo,

    Per ARM TRM, only the Normal Memory type attribute supports unaligned accesses.