RE: Unable to access EMIF ASYNC1 on RM48 HDK - help needed

Anila,

Check the pinmux. If the GIO function is not the first function in the pin name, you also need to program the pinmux to give it control over the pin.

Yes I am talking about GIOA port specifically. I initialize it in the halcogen, and the behavior is as i mentioned. In the dout register, the particular gio value changes, but no change on oscilloscope, always remains high. Any help would be highly appreciated.

Regards

Anila

Do you see the same bit in DIN changing when you change DOUT?

Where are you looking with the oscilloscope? (physically, which connector which pin).

Which specific GIOA pin are you having an issue with?

Some of these pins may be connected to other logic or routed through switches on the HDK.

Hi Anthony,
Thanks for the reply, i was able to fix that.

Now back to Async memory access problem. My device is not a memory device, but it has 64 KB of onchip SRAM and i have interfaced it in 16 bit mode. I initialized the async1 interface using halcogen and try to access the onchip ram like this:

uint16 *ptr = 0x6000_1000;

for count = 0 to 100
*ptr = count;
ptr++;
count++;

In the memory viewer, what is observed is data is written like this:
1 1 3 3 5 5 and so on
I also observe this that instead of writing one word at a time 2 words are being written. The even data i.e. 2 4 6 are written and then on next access, they are overwritten.
Can you please help me what's the problem?

Many thanks
Anila

Anila,

Please look at the silicon errata, especially EMIF#4.  Likely you have this issue.

-Anthony

Anthony, i have used CS2. Errata mentions EMIF4.
Even then, can you please tell me how to configure the memory as "device type" or "strongly ordered type" in the mpu? What changes are required?

Thanks & Regards
Anila

No, EMIF4 means 'EMIF Errata #4" not chip select 4. So it applies to nCS2..

The MPU settings are available in HalCoGen on the Device tab, under the "R4-MPU-PMU" subcategory.
Each region has a 'Type' that you can select from.

You should read about how the MPU works first though in the ARM Cortex R4 Technical Reference Manual;
it is available on ARM's support website.

Many thanks Anthony. This is really helpful.
Will get back to you after trying to fix this.

Regards
Anila

Hi Anthony,

As per the work around for EMIF#4, i changed the mpu settings to strictly ordered, then to device type, but no change happens in the memory access. How to fix this? Can you please suggest anything?

Secondly i am using RM48 HDK Rev E, the part no installed is RM48L952ZWT, which suggests its revision C.

Regards

Anila

Are there any specific function calls for mpu required?
Anyone had any success with accessing async EMIF?

Anila,
Did you change the mpu setting from strongly-order and then to device type for the EMIF region? If this is what you did then it is wrong. You should just change to strongly-order for the EMIF memory region and stay in strong-order for your entire application as a workaround.

Hi Charles,
I made the changes in halcogen where the default was already strongly ordered and it was not working, so changed it to device type, it didn't work either. What to do?

Regards
Anila

Hi Anila,

 For the code segment you have below can you show the disassmbly and examine if there are any STMxx (store multiple) type of instructions? Please see below errata. Also see this post for additional details. 

uint16 *ptr = 0x6000_1000;

for count = 0 to 100
*ptr = count;
ptr++;
count++;

Anila, make sure to call _mpuInit_() which initializes and enables mpu!

Hi Joe,

I made the above function call, it improves the writing but still two words are written and then overwritten.
Still the result is 1 1 3 3 5 5 7 7 9 9 ... What to do?

Help from TI is needed, because my interfaced peripheral will not work, any other workaround?
Any suggestions what should be done or checked?

Thanks & Regards
Anila

Hi Charles, I have attached the disassembly, please check.
No success in getting the desired result. Can TI suggest any solution?

Thanks & Regards
Anila

Hi Anila,
OK, I don't any STM instructions so it is not the errata DEVICE#B064. You seem to say that after you enable mpuInit() then things improve. Does this mean that all along you never enable MPU in the first place? After you call mpuInit() you said it improves the writing. What is the improvement?

Earlier I suggested to configure the EMIF region in strongly-order mode and you said it didn't work in either strongly-order or device mode. I wonder if this observation is made in the absence of calling mpuInit(). Can you please in HalCoGen configure the EMIF region in strongly order mode and enable mpuInit() and then try again? I just want to make sure you have truly tried the workaround as suggested in EMIF#4 errata. If this is still not working then it is news to me.

Hi Charles,

By improvement, i mean without calling mpuInit, sometimes 4 words were being written, i saw this while single stepping, and sometimes data written was erratic.

After calling mpuInit, the writing behaviour becomes consistent, instead of one word, always two words are written.

Secondly, in halcogen both 8000_0000 & 6000_0000 regions are by default initialized to strongly-ordered. So i didn't change those settings. However, some of the sub regions are dusabled, please tell me do i need to enable thosew sub regions.

Regards

Anila

Except for the sub regions, i think i have tried the work around as it should it. The emif driver is generated from halcogen, i call the mpuInit, and then access memory but the result is two words written instead of 1.
If you can suggest anything, please do let me know.

Regards & Thanks
Anila

Hi Anila,

I don't know what is wrong at the moment. Can you please check and try below things?

1. Check your hardware connection. Do you have your external device connected as shown in the TRM for the 16-bit memory?

  2. Can you check the ASIZE bits in the CEnCFG register? Do you have the right size that is matching your external device?

  3. You said you read 1,1,3,3,5,5 and etc in the memory browser. Have you tried to read the same addresses with your code rather than the debugger? How do they come out?

  4. Can you try to perform the same operations from the SDRAM which is on the HDK? Do you see the same problem?

  5. Can you try to use the DMA to write/read to the EMIF async memory? Will you see the same problem? 

Hi Charles,

Okay ill reply to all your queries, for now i can assure you the hardware connections are as mentioned above. In the past i have used the on board sdram, it works absolutely fine.

Can you please tell me, in the halcogen do i need to enable the sub regions which are disabled by default in mpu settings?

Regards
Anila

Anila,

 No, you don't need to enable the subregion. Just keep the default halcogen as below.

Hi Charles,

2. Yes ASIZE = 1 in CE2CFG. Even if Async1_init is not called, i get the same result? Why is that so? The external device is  configured in 16-bit mode.

3. I read back the data into an array, result is same 1 1 3 3 5 5.

4. SDRAM absolutely works fine, result is 1 2  3  4  5  ...

5. Have not tried DMA, any sample code for that.

Regards

Anila

1. Have checked and rechecked my schematics, they match the TRM. Will physically check the connections and then let you know.

What i am observing is this the EMIF is always writing 32 bits instead of 16 bits. Could it be that something has gone wrong with the HDK?

Regards
Anila

Anila,

What CPU instruction are you executing when you see the 32-bit write?

Have you attached probes to the EMIF signals to get a waveform view of what the interface looks like?

Since we've already discussed the ERRATA I think these would be the next steps.

Hi Charles,

Yes my hardware connection is exactly as above. However the asynchronous peripheral that I am using doesn't have byte enable signals, so I kept the nDQM[0:1] signals of RM48 EMIF not connected. Please tell me what to do?

Regards
Anila

Hi Anthony,

Attached is the disassembly of the code.

Yes I attached the probes to nCS2, nWE etc, I observed them going low for a very short while, should I look for something specific? 

Any suggestions what to do next?

Regards & Thanks

Anila

Hi Charles,

1. Yes
2. Yes
3. They come out same without the debugger as well.
4. SDRAM works perfect.
5. Need the DMA sample code.

Regards
Anila

Please post a picture of the strobes, nCS[2], nWE.
Also please post the DQM[] as these are the byte enables.
It is possible that there are two strobes but one has none of the byte enables (DQM[]) active.
The STRH is correct for a 16-bit write.

Hi Anthony,

Please see the attached.

D0 = nCS2

D1 = nWE

D2 = nDQM0

D3 = nDQM1

My asynchronous memory does not have byte enable signals, so nDQM[0:1] are disconnected on the daughter card.

The first snapshot is with custom timings as per the device datasheet of the asynchronous peripheral.

The second snapshot is with the default timings in the HalCoGen for Async1.

Hoping to hear from you soon.

Regards

Anila

Thanks Anila,

If there is only a single write strobe then this matches the STRH because the EMIF is x16.

So you shouldn't be seeing a write to two different locations in your async device just based on this.

Unless you can capture *two* WE pulses based off the execution of the single STRH instruction ...
my conclusion would be that there's some incompatability on the circuit level between the external device and the EMIF.

What is the external device part #? [or please paste a link to the datasheet]

-Anthony

Thanks Anthony.

What might is the reason for both nDQMs going low?

Is it that the EMIF works accurately only with memories which have byte enable signals? Because the TRM doesn't mention how to connect the nDQM signals if there are none in the peripheral interfaced.

Regards

Anila

Anthony,

Okay I'll try to look deeper into it. Since this was captured while executing a while loop, will try to figure out more.
Can you please tell me will there be a gap between the two WE pulses, if yes how much?

Regards
Anila

Yes there is a gap.
It will depend on your asynchronous timings.
The async timing is broken into three regions:
Setup, Strobe, Hold

In your case WE\ is the strobe and it is asserted only during the strobe period.

You really should already 'see' the 2nd WE on this plot of the issue were the CPU making a 32-bit write, because the gap would be

Setup, Strobe, Hold, Setup, Strobe, Hold
WE\ Gap WE\

So that gap is only going to be 1 Hold + 1 Setup and you can see that those times are pretty short by looking at the access you did capture.
(they are the time before and after WE\ is low where CS\ is low but WE\ is high...)

-Anthony

Thanks Anthony.

Yes I watched the two write pulses by using a 32-bit integer, your above explanation is correct.

16-bit access is still the same. Can you please tell me how to decode the address for 16-bit access i.e. considering the following physical interface:

RM48 ---> Memory

BA1 --->   A0

A0    --->   A1

A1    --->   A2

A2    --->   A3

for 16-bit access, 16-bit pointer would be used so all the addresses would be even. Now for an address 0x6000_1002, how should this be decoded, will the last byte 0x02 appear on  A6 A5 A4 A3 A2 A1 A0 BA1 = 0 0 0 0 0 0 1 0?

And if the above decoding is true, then does it mean that BA1 will always be 0 for 16-bit access?

Waiting for the reply.

Thanks & Regards

Anila

Anila,

No for a 16 bit access BA[1] holds the halfword address bit and BA[0] winds up holding one of the very upper address bits.
Your mapping above looks correct.

If you only see one write strobe though I don't see how this would result in a 32-bit write unless there is a problem in hardware
or the chips are not compatible.

For 0x6000_1002, A6 A5 A4 A3 A2 A1 A0 BA1 = 0 0 0 0 0 0 0 1

The byte address ends in '2' so ends in 0 0 1 0.

But the last '0' in position 2^0 is a don't care for a 16-bit memory address.

Instead, the 2^0 position comes into play only for 8-bit writes in which case one of the DQM lines
would be inactive to pick the correct byte lane.

This should be talked about in the EMIF TRM chapter.

Hi Anthony,

Many thanks for this explanation, its quite helpful.

I have almost figured out what's the problem with my interface.

Though the TRM explains the 16-bit addressing, but it needs more detail like the one you have explained here. I think TI should add detailed address decoding in the EMIF chapter, for asynchronous memory as well.

Many thanks for the replies.  I might get back on this soon.