• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 605 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.

RM57L843: EMIF in Asynch Mode with extended wait needs clarification

Matthias Schmitt
Expert 5520 points
Part Number: RM57L843
Other Parts Discussed in Thread: HALCOGEN

Dear Hercules team,

 

My customer is facing the following questions with respect to the RM57L843.

 

They observe a behavior which seems to be close to the one described in the EMIF#3 Silicon Errata.

But, the difference they see is that an Abort is generated by a direct access to a memory cell (which is not acknowledged and times out). Doing afterwards a read access to the EMIF register (after the Abort got handled) is working without an Abort.

Their current workaround is to handle the Abort without additional specific actions. (An empty CCS and HalCoGen project is not doing/including this Abort-handling, so the Abort leads to hang-up the S/W).

 

Issue description in the Silicon Errata (SPNZ233B):

“Issue After an EMIF time-out error when an external asynchronous memory fails to respond, a read to an EMIF register generates data abort.“

In order to include also the above mentioned effect, the Errata entry should be:

“Issue An EMIF time-out error when an external asynchronous memory fails to respond, generates data abort.“

 

Can someone please clarify if/how the above described effect is related to the EMIF#3 errata?

The workaround of the EMIF#3 errata does not work for the above described effect.

 

The bits to set or mask the EMIF-interrupt events do not seem to show any effect.

Which of the 128 interrupts at the VIM should trigger the EMIF interrupt?

Why are the EMIF Interrupt settings not visible in HalCoGen (EMIF ==> General, SDRAM, ASYNC 1…3)?

The expectation would be to find there a possibility to parametrize the EMIF-interrupts (3 Bits in INTMSKSET respective INTMSKCLR) and to find the ISR there.

 

A timeout should be visible via an Abort, as it looks like to work right now. In order to prevent checking after each EMIF-register access if a timeout happened, a interrupt should be triggered in case a timeout happens. This interrupt-event is described in the EMIF chapter of the user guide. But there is not additional description to this event with respect to the Interrupt Controller VIM documentation nor in HalCoGen.

 

Please help to clarify this topics.

 

Thanks,

BR,

Matthias

  • 0
    TI__Guru**** 196206 points

    Hello Matthias,

    The symptom is different from EMIF#3 Silicon Errata. The EMIF#3 occurs when reading EMIF register after timer-out error.

    The EMIF ISR is allocated at channel VIM #41. User needs to add their own ISR name there manually.

    Do you have the details of their EMIF configurations? How can I re-produce this issue?

  • 0 in reply to QJ Wang
    Prodigy 30 points

    Hello QJ Wang,

    I'm the customer of Mattias.

    Yes, the symptom is different to EMIF#3.

    Looking to EMIF#3 was Matthias proposal because it is very similar.

    For re-producing my situation:

    I use HALCoGen 04.07.00 and Code Composer Studio 7.3.0.00019 and started with an empty project for RM57L843.

    In HALCoGen I use EMIF ASYNC1, 2 and 3, all with ASIZE 16 Bit.

    MAX_EXT_WAIT is set t0 5, Wait Polarity is set to high for both Pins (RM57L843 has only the first one).

    For EMIF ASYNC1 I enable "Extended Wait".

    In CCS I do accesses to the corresponding addresses of ASYNC1 resp. CS2 0x60000000.

    When the wait pin is driven low everything works fine with the Timing set in HALCoGen, ASYNC1 Timings.

    When the wait pin is not driven low (kept high), the access gets extended (set by MAX_EXT_WAIT), which can be observed with an logic analyzer and CCS hangs up because of an unexpected Abort, which is not handled by the empty project.

    Fixing this empty, uncomplete Abort fixes the hang up and confirmes the Abort as cause für the problem.

    With this Information you should be able to reproduce the problem on an evaluation board. If not, please ask.

    Regards Horst  

  • 0 in reply to Horst Mayer
    TI__Guru**** 196206 points

    Hello Horst,

    I did test on HDK, without any async memory attached. I saw the problem. I will do more test to make sure it is not caused by my code or my board. I will keep you updated.

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

    Hello Horst,

    The abort in my test was caused by reading 0x6000_0000 which is invalid since there is no SRAM attached. I did several test with writing only, and I don't see the problem.

    I tried different polarities: LOW, HIGH, and I use one GIO pin to control the EMIF_nWAIT.

    When polarity is LOW, and EMIF_nWAIT pin is LOW, the write period gets extended

    When polarity is LOW, and EMIF_nWAIT pin is HIGH, there is no extended wait

    When polarity is HIGH, and EMIF_nWAIT pin is HIGH, the write period gets extended

    When polarity is HIGH, and EMIF_nWAIT pin is LOW, there is no extended wait

  • 0 in reply to QJ Wang
    Prodigy 30 points

    Hello QJ Wang,

    thank you for the answer, but I can't understand the explanation.

    When there is no SRAM attached, the Controller also generates the address signals, chip select and command (read resp. write).

    In the case of writing the data go to nowhere.

    In the case of reading the Controller reads the data from the floating data lines because they are not driven by a device. This should/could result in random data.

    Can the controller detect the floating data lines? (and generate an Abort when they are floating)

    I will also test the write accesses. I just started with read, detected the mentioned problem and stopped for clarification.

    Regards Horst 

  • 0 in reply to Horst Mayer
    Prodigy 30 points

    Hello QJ Wang,

    second answer:

    In the meantime I also tried the write acces and I can state that the write aaccess works.

    I have another explanation for the Abort at read accesses with timeout:

    The cause is not the missing SRAM.

    When I have a device connected which pulls the nWait low, read works fine.

    Now i only cut the nWAIT line so that nWAIT stays high, which generates the timeout. With this change I get the Abort. (The device is still there.)

    My explanation: Because of the timeout the controller knows that it didn't get valid data at this access and so it generates the abort!

    Is that right? Is that described somewhere?

    For a write access with timeout the controller could (should?) do the same, because it knows that the write acces must have been unsuccessful (missing acknowledge) but it doesn't! Why?

    Regards Horst

  • 0 in reply to Horst Mayer
    TI__Guru**** 196206 points

    Hello Horst,

    After I replaced the burned LDO on my SRAM test card, I will do the test again. I have ordered the part. Apologies for the delay.