RM57L843: EMIF_nWait Issue while reading

Hi Veerappan,

My apologies for the delayed response, i was stuck with other issues.

Are you still block with this issue?

--
Thanks & regards,
Jagadish.

Hi jagadish gundavarapu,

Yes, I am still stuck in that issue.

Thanks,

Regards,

Veerappan P.

First i want the below confirmation from you:

Are you controlling EMIF_nWAIT with the GPIO from the controller?

If this is TRUE, then i want to mention that usually this EMIF_nWAIT signal is designed to control by slave device not the master himself. I never saw a design like this, however doing this should not create any problem as per my understanding.

Did you make sure the below? Is your RSETUP and RSTROBE values were greater than 4?

--
Thanks & regards,
Jagadish.

Hi,

 Yes the above block diagram is correct and Yes I know EMIF_nWAIT signal is designed to control by slave device. But In our case EMIF_nWAIT is used to synchronize the EMIF and GPIO lines.

The below image is Mill bus EMIF Configuration and the SETUP plus STROBE value is greater than 4.

Thanks,

Regards,

Veerappan P.

Hi jagadish gundavarapu,

Any update?

Thanks,

Regards,

Veerappan P.

Hi Veerappan,

The reason for unlocking this thread is that it is not closed properly from TI side, so i unlocked it again.

Apologies for the incontinence.

Are you still stuck with this issue, if yes then please let me know exactly where you stuck with this now.

--
Thanks & regards,
Jagadish.

Hi jagadish gundavarapu,

Yes, whenever I do read the operation, the system enters a data entry abort when EMIF_nWait is asserted low.

Thanks,

Regards,

Veerappan P.

Is it possible to share your code for verification?

You can even send it through private message as well.

Hi Veerappan,

I verified your code, and it seems to be fine to me.

I also did debug code from my end without any slave and i didn't see any abort while executing this code.

Is this abort occurring only when slave is connected to the master?

--
Thanks & regards,
Jagadish.

Hi,

It's my mistake, I sent the wrong code. Now I will send the correct code. I have also tested it without the slave device in the RM57Lx Launchpad. Additionally, don't forget to connect the N2HET2[12] signal to the EMIF_nWAIT signal on the hardware side.

Thanks,

Regards,

Veerappan P.

Veerappan,

I tried your new code as well, still no data abort, do i need to short any of the two pins (like gio with nWAIT)? If yes then mention exact pin numbers once?

--
Thanks & regards,
Jagadish.

Hi,

Yes, the signal name is N2HET2[12], the pin is D3 to signal EMIF_nWAIT, pin is P3.

Thanks,

Regards,

Veerappan P.

Hi Veerappan,

I shorted those two pins and checked, still there is no issue from my end. I am not getting any abort in my case.

Can you try without EMIF slave device once from your end? Is that possible?

--

Thanks & regards,
Jagadish.

Hi jagadish gundavarapu,

 I tested without a slave device in the RM57Lx Launchpad, and I also sent a video to you in a private message.

Thanks,

Regards,

Veerappan P.

Hi Veerappan,

Thanks for the video, i verified your video and you are correct about the behavior.

I am suspecting this could be the reason for the data abort.

• Once you initiate a read, the EMIF expects the memory transaction to eventually complete.
• You are pulling nWAIT low here, which tells the EMIF to wait.
• But never release nWAIT(set it logic high), so that means bus cycle never ends.
• That means the EMIF waits indefinitely, and eventually the CPU detects a timeout or bus error, resulting in a data abort exception.

As highlighted above as long as EMIF_nWAIT is low the strobe period will get extend there is no limitation. That is the reason we should not continuously to hold this pin, it would be good if we hold the few EMIF cycles not indefinitely.

As you can see here in above picture also EMIF wait signal is asserted at strobe period by external slave device for few cycles and then it got de-asserted. So, it is always fine to introduce few cycles of the wait period instead of indefinitely which will create timeout for read operation and eventually generates data abort.

--

Thanks & regards,
Jagadish.