• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 29 subscribers
  • Views 940 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.

TMS570 MCU EMIF WE Signal abnormality using HalCoGen code

nestor lee
Intellectual 985 points
Other Parts Discussed in Thread: HALCOGEN

Hi TI Experts,

We encountered a problem using TMS570LS1114ZWT's EMIF, the EMIF is connected to one FPGA, when we use HALCoGen generated code, we found that each time we write to EMIF, there will be one CS signal active, and during this time, we can see 3 WE active signals on the WE pin, meanwhile, we can see the address bus data increase from 0 to 1, and then 2.

We saw that some had already solved this problem by calling a  void _mpuInit_(void) function in the sys_mpu.c file generated from HALCoGen. But we need to understand what the void _mpuInit_(void) function did, and why we need to call this function during initialization by ourselve, why don't HALCoGen generate such envokes? Is there anything we need to take care when we call void _mpuInit_(void)?

And also, we found similar posts on the e2e forum before.

http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/314999

and http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/412793

suggest to read MCU's Technical Reference Manual to set MPU to  "device" or  "strongly ordered". Can anyone tell me where to find the MPU description for "device" or "strongly-ordered" mode? I can't seem to find that section.

  • 0
    TI__Guru 65580 points
    Nestor,

    There's a silicon errata covering this issue -
    "EMIF#4 — Write to external asynchronous memory configured as “normal” causes extra WE pulses"
    See www.ti.com/.../getliterature.tsp

    If you had the DQM signals available you'd see that the extra byte "WE" are disabled. So if you had both "WE" and "BE" for each byte lane,
    it would be correct but wasting time.. It has something to do with the write buffer and how the CPU tries to optimize by making wide accesses to normal memory.. where it thinks normal memory is like a RAM. If you have an FPGA or something sensitive to 'side effects' for memory reads then this is why the Device & Strongly Ordered MPU types were created - to prevent the CPU from trying to optimize bandwidth by putting out a wider bus transaction than is necessary. That's how the MPU is related to the workaround for this issue. Errata may explain it better, and I may be a little off in the exact details of the root cause - but it definitely makes sense why the MPU is used as a workaround becuase it restricts the type of accesses that the CPU emits for that address range to the kind that the EMIF can 'handle'.

    -Anthony
  • 0 in reply to Anthony F. Seely
    Intellectual 985 points

    Anthony，

    Thanks for your quick response. I checked the errata，and found that "EMIF#4". It explained the EMIF issue and workaroud.

    My second question is where can I find the description of how to set the MPU, I cannot find the MPU setion in the MCU datasheet or TRM. And, we are afraid that using the"void _mpuInit_(void)?" function generated by HALCoGen would bring any side-effects. So we'd better look into the MPU description and understand the assembly code.

  • 0 in reply to nestor lee
    TI__Guru 65580 points
    Nestor,

    You can configure the MPU inside HalCoGen.

    The MPU is part of the CPU System Control Coprocessor - so the documentation for it is in the ARM Cortex R4F technical reference manual and as well some is in the PMSA architecture section of the ARM Architecture manual -v7AR.

    Usually the HalCoGen default settings are pretty close to 'useful' (you may need to adjust the EMIF settings for this particular case, but defaults for internal memory should be useable).

    -Anthony