• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 1495 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 bad endian

Jiri Dobry
Expert 1810 points
Other Parts Discussed in Thread: TMS570LC4357

Hello,

we are found problem on the EMIF external bus. We are using 16 bit bus configuration, but it looks like broken endianity somewhere in silicon.

Problem is byte order on external bus. Lets have this test line:

*(U16 *)0x60000000u = 0x0001u;

But during write cycle, we  see "1" on EMIF_DATA8 (ball L5) wire, not EMIF_DATA0  (ball K15) as expected. And vice versa for 0x100 value.

Used chip is TMP570LC4357BZWTQQ1 (rev.B) on Texas Hercules launchapd board.

Can you describe it better (ex errata)? Where is it crossed? Has it impact for 8bit EMIF configuration, where is LSB in this case (L5/K15) ?

Many thanks for information,

Jiri Dobry

PS: Here is used  external bus configuration:

  emifREG->CE2CFG = (0U  << EMIF_BIT_SS)       |
                    (0U  << EMIF_BIT_EW)       |
                    (0U  << EMIF_BIT_W_SETUP)  |
                    (0U << EMIF_BIT_W_STROBE) |
                    (0U  << EMIF_BIT_W_HOLD)   |
                    (0U << EMIF_BIT_R_SETUP)  |
                    (1U << EMIF_BIT_R_STROBE) |
                    (0U  << EMIF_BIT_R_HOLD)   |
                    (1U  << EMIF_BIT_TA)       |
                    (1U  << EMIF_BIT_ASIZE);      /* 16-bit bus */

  • 0
    TI__Guru 59540 points
    Hello Jiri,

    The TMS570 devices are BE32 devices. This means that the MSByte is read first or at the lower address. The results you are describing where the LSByte is at DATA8 would indicate that the external device or system you are communicating with is LE since the bytes are swapped. The EMIF is simply reading data based on the addresses provided and would provide the data however the read device/data is provided by the external entity.
  • 0 in reply to Chuck Davenport
    Genius 3315 points

    Dear Chuck,

    I guess, you have described the data reading where a slave device (external RAM, buffer,...) is involved in. But Jiri stressed the write operation (no influence of an endianess of the slave considered) with measurement directly on data bus  lines - so the EMIF behavior seems to be a bit strange...

    Best regards,

    Cheers, Jiri

  • 0
    TI__Guru**** 159305 points

    Hello Jiri,

       I can reproduce your observation on my bench. We need to investigate further on the effects of this observation. Can you tell me what type of devices you hook up to the EMIF? 

      

  • 0 in reply to Charles Tsai
    Expert 1810 points

    We are need connect to own device (VHDL on FPGA). Therefore we are flexible to solve this problem.
    But type of connected device is not significant for this question.

    Problem is target of Hercules family and TMS570LC4357 chip. It is "safety" device. We also need to use it on safety aplication. And in this case it's impossible use anything that can be detected as "hack". Therefore we need to do paperwork. We need clarification of this behavior from you side to our documentation.

    Have a nice day,
    Jiri

  • 0 in reply to Jiri Dobry
    Expert 1810 points
    But for example let me to describe simple spare device. It could be 16bit register connected to 16bit EMIF bus. Write signal into register is simple combination of (nCS | nWE). Without address decoder.
    Write 0x0001 into this register cause bit8 ="1" and bit0="0". This need clarification.
  • 0 in reply to Jiri Dobry
    TI__Guru**** 159305 points

    Hello Jiri,

      Our design team is currently running simulation trying to understand the root cause. We will update you as soon as we have more information. 

  • 0 in reply to Charles Tsai
    TI__Guru**** 159305 points

    Hello Jiri,

      I want to give you an update on LC4357 EMIF. It appears that the LC4357 EMIF is in the BE-8 (this is the native Cortex-R4/R5 big endianism format) rather than BE-32 as in other Hercules devices. if you are connecting a RAM to the EMIF then it should have no issue as the RAM is endianism neutral. If you are connecting a ASIC/FPGA you can swizzle between EMIF_DATA[15:8] and EMIF_DATA[7:0]. We are adding a note to the LC4357 TRM to clarify this behavior in the next release. 

  • 0 in reply to Charles Tsai
    Expert 1810 points

    Hello Charles,

    thanks for the information. But it realy need fix information in documentation. See to Datasheet SPNS195A Chapter 1.3 citation:

    "The TMS570LC4357 device integrates two ARM Cortex-R5F floating-point CPUs, operating in lockstep,which offer an efficient 1.66 DMIPS/MHz, and can run up o 300 MHz providing up to 498 DMIPS. The device supports the big-endian [BE32] format."

    The TRM (SPNU563) notice about endianity in several chapters. For ex chapter 1.3.1 TMS570: Big Endian (BE32). But allways talking about BE32, never about BE8 exception for EMIF.

    For "followers" I also add link to ARM documentation about BE-8 and BE-32. It if for another core because ARM documentatuob vor Cortex-Rx don't describe this diffrenece.

    Jiri

  • 0 in reply to Jiri Dobry
    TI__Guru**** 159305 points
    Hello Jiri,
    Thanks for your comment. I agree that it is a bit confusing when the device is advertised for BE-32 while the EMIF behaves as if in BE-8. The plan right now is to add notes to the EMIF section of the LC4357 TRM to state the implemented behavior. I will discuss internally to see if an errata would be a better place to clarify this discrepancy.