RM48 - EMIF - Async Connection to FPGA - 3rd nWE pulse!

stomp

Other Parts Discussed in Thread: HALCOGEN

Hi,

I have a RM48 950 on the HDK. I have connected the EMIF to a Xilinx FPGA and, as a starting point, scoped the signals when I do a basic EMIF write from RM48 to FPGA. I am writing to a FIFO and are not using any addressing scheme, other than relying on BA[1:0] from the RM48 to determine the upper and lower words of the transfer.

To my surprise I see a third write pulse with data = 0x0000 while the chip select is active. I am writing the data 0xABCD0001 to the CE2 address space.

Could anyone begin to guess what the problem is?. Is this a software setup issue?

For the purposes of setup, I have simply configured the CE2CFG register, its code is as follows:

emifREG->CE2CFG = 	(0 << 31) | /*0 Normal Mode enabled.*/
			(0 << 30) |
			(0 << 26) | /*Write setup width in EMIF_CLK cycles*/
			(3 << 20) | /*Write strobe width in EMIF_CLK cycles*/
			(5 << 17) | /*Write hold width in EMIF_CLK cycles*/
			(1 << 13) |
			(11 << 7) |
			(3 << 4) |
			(3 << 2) | /*Minimum Turn-Around time*/
			1;

Any help please?

Thanks

Stomp.

over 13 years ago

0 Anthony F. Seely over 13 years ago

TI__Guru 68920 points

Hi Stomp.

Some of the engineers on our team have also seen this recently, and the working theory is that the CPU bus is 64-bits wide.

When you write to memory - it issues an 8-byte write but there is a byte enable for each byte lane. Only the byte enables that

you are writing to should actually be asserted. And the EMIF has byte enables too - not sure if they're hooked up to your FPGA.

(these are the WE_DQM signals). These should be valid and allow you to distinguish between the real writes and the dummy writes.

Agree it's not optimal behavior and for upcoming designs we're seeing if these can be optimized out (so they don't take time).

Aside from using the WE_DQM signals on your Xilinx as qualifiers, we've also had someone report that making the EMIF region Strongly Ordered

will change the type of access that the CPU issues and you should no longer see this occurring.

Since you have an FPGA, and a FIFO in it, strongly ordered is probably a good idea anyway.

If you are using HalCoGen to generate driver code, you can change the type to Strongly Ordered on the tab "MPU"

which is located under the top-level tab "TMDXRM48HDK" . For each MPU region there is a tab called "type" that you

can adjust. I believe strongly ordered is the 'default' now in Halcogen 3.00.

Anthony

0 stomp over 13 years ago in reply to Anthony F. Seely

Genius 4675 points

Hi Anthony,

Thanks for taking the time to respond to me.

I had already set the region 5 (Base 0x60000000) to STRONGLYORDERED_SHAREABLE.

As I am using a FIFO I have tied the combination of the BA[1:0] and ADDX[1:0] to the write enable into the FIFO so as I can detect only the first two WE edges from the RM48.

I will *try* and connect the DQM signals so as they can be monitored and report back.

This is our first time using these RM48's. We have previously found a bug in HALCoGen V3.00.01 and now a possible silicon fault in the device. Is the Errata updated regularly?. Just worried about what else we might find along the way.

Regards

Stomp!.

0 Anthony F. Seely over 13 years ago in reply to stomp

TI__Guru 68920 points

Stomp,

Hi, this might be something different then. I'm wondering about alignment for example. What address are you writing to ?

If you don't mind posting the snippett of disassembly and the key CPU register values (i.e. the one being used for the pointer to EMIF memory, and the CPU instruction type that does the store (is it STR, STRB etc... ) this might give some clue.

Have to check on the errata... but sounds like you may have the workaround for the other issue already in your app.

Best Regards,

-Anthony

0 stomp over 13 years ago in reply to Anthony F. Seely

Genius 4675 points

Hi Anthony,

The issue is unaffected by the speed at which I run the EMIF module, so we can count that out too.

I am only writing to the start of CE2 address space (0x60000000).

The listing is below:

          vEMIF__WriteU32:
00000d1c:   E24DD008 SUB             R13, R13, #8
00000d20:   E58D0000 STR             R0, [R13]
145       	emifDATA->u32DataCS2 = u32Data;
00000d24:   E3A00206 MOV             R0, #1610612736
00000d28:   E59DC000 LDR             R12, [R13]
00000d2c:   E580C000 STR             R12, [R0]
148       	emifREG->INTRAW = 0;
00000d30:   E59F00BC LDR             R0, $C$CON7
00000d34:   E3A0C000 MOV             R12, #0
00000d38:   E580C000 STR             R12, [R0]
150       }//void vEMIF__WriteU32(Xuint32 u32Data)

R0 is 0x60000000, R12 is the data which in this case is 0xABCD0001.

Is there any conclusion to this issue? Other than putting it down to some sort of fault?.

Thanks
Stomp!.

0 stomp over 13 years ago in reply to Anthony F. Seely

Genius 4675 points

Hi Anthony,

I have done some more exhaustive testing and found another interesting problem with the EMIF.

During long data writes, to addx 0x6000000 randomly I find that bit zero of the data bus is the wrong value.

I am sending the following data array, with the upper nibble set to 0xABCD:

Xuint32 u32Array[] = {
			0xABCD0001,
			0xABCD0002,
			0xABCD0004,
			0xABCD0008,
			0xABCD0010,
			0xABCD0020,
			0xABCD0040,
			0xABCD0080,
	};

I am using Xillinx ChipScope at the pins between the RM48-EMIF and the FPGA. The sampling clock for ChipScope is 2x faster than the EMIF clock. In the example below D0 is a logic 0 when it should be a logic 1 (0xABCD not 0xABCC).

Given the length of clock cycles in setup and hold time of the EMIF, this is simply not a PCB fault, the RM48 did not output the D0!. I have also exhaustively checked signal integrity issues and all my waveforms are clean. RM48's EMIF is 40MHZ.

See below:

The full part I am using is XRM48L950ZWTT, with the additional date code being YFA-15A930W.

Any extra help?

Thanks.

Update:

With the EMIF clock turned down to 5MHZ, strange extra nCE's appear...

0 jianwei xie over 13 years ago in reply to stomp

Intellectual 305 points

your can try to set the sampling clock for ChipScope to 3x faster than the EMIF clock, this maybe slove your problem

0 stomp over 13 years ago in reply to jianwei xie

Genius 4675 points

Hi,

I can't speed up the Chipscope beyond 100MHZ, but I have slowed down the EMIF and also verified via a USB logic analyzer.

Irrespective of what tool I use (Digital CRO, Chipscope, USB Analyzer), I see the same results.

Thanks.

0 Abhishek Shankar over 13 years ago in reply to stomp

TI__Intellectual 2310 points

Stomp,

We looked at this problem and we observed that though the MPU setup was configured through Halcogen the config function isn't actually called by the generated code. Please place the following calls in sys_startup.c

void _c_int00()
{

/* USER CODE BEGIN (5) */
/* USER CODE END */

    /* Initialize Core Registers to avoid CCM Error */
    _coreInitRegisters_();

    /* Initialize Stack Pointers */
    _coreInitStackPointer_();

/* USER CODE BEGIN (6) */
    _mpuInit_();
    _mpuEnable_();
/* USER CODE END */

    /* Implement work-around for CCM-R4 issue on silicon revision A */
    if (DEVICE_ID_REV == 0x802AAD05)
    {
        _esmCcmErrorsClear_();
    }

This should fix your issue.

Pls let me know if the data bit related problem was rootcaused by you as yet.

0 Abhishek Shankar over 13 years ago in reply to Abhishek Shankar

TI__Intellectual 2310 points

Just to be clear the added code is the one within "USER CODE BEGIN" and "USER CODE END"

0 Petr Burian over 13 years ago in reply to Abhishek Shankar

Prodigy 70 points

Hi Abhishek,

I detected the same problem as Stomp. I have solved it according to your advice.

Now, no dummy cycles are detectable on the external emif bus.

However, I guess these dummy cycles still run inside of the processor.

Because, when I perform two immediately successive read or write cycles (2x read, or 2x write), I detect delay

between individual cycles equal to exactly twice the time needed to perform one read/write cycle.

Any advice, recommendation ?

Thank you.

0 stomp over 12 years ago in reply to Abhishek Shankar

Genius 4675 points

Hi Abhishek,

We finally got back our new hardware and added the _mpuInit() code as you suggested.

Our application now immediately vectors to void tcramClass2Error(void) and sits in a while loop.

Can you please predict what is happening that causes the _mpu code to cause the error handler to be called.

Thanks.

Arm-based microcontrollers

Arm-based microcontrollers forum

RM48 - EMIF - Async Connection to FPGA - 3rd nWE pulse!