LPC4357 bad EMC read access

[robertmorrison]

I have been programming the nxp lpc4357 processor on a custom board for a couple of years without problems, but recently I seem to have encountered a read access problem using the EMC port pins.  I have address 0x1c000000 configured as an 8 bit interface that talks to an 8 bit interface on an FPGA.  I traced back a read access failure to the port pins, where a single character read (verified by looking at the assembly ldrb instruction) is showing that the address is changing in the middle of this access.  This wouldn't necessarily cause a failure (two consecutive address byte reads) except that the data from the second half is getting loaded rather than the data from the address in question.  Here is the configuration of the static memory read EMC registers:

   LPC_EMC->CONTROL  = 0x00000001;   // turn off EMC reset
   LPC_EMC->STATICCONFIG0  = 0x00000080;   // set for 8 bit bus, enable nwe
   LPC_EMC->STATICWAITRD0  = 0x00000005;   // 5 cycle wait states
   LPC_EMC->STATICWAITPAG0 = 0x00000001;
   LPC_EMC->STATICWAITWR0 = 0x00000003;    // must be set to 3 (31ns)
   LPC_EMC->STATICWAITTURN0 = 0x00000001;   // 1 cycle turnaround

Here is the test code that reproduces the problem in the actual code:

   result_read = *(char *)(0x1c000028);
   return(result_read); 

The result_read actually contains the data from 0x1c000029.

I've attached a waveform that shows the unexpected address change in the middle of a read cycle.  If I set that access to a word 16 bit address, it does the same thing for two cycles--four consecutive addresses.  It's acting like some kind of page mode is running, but even there it doesn't store the data in the right locations.  (Note that I have the page mode bit in the STATICCONFIG0 register turned off).  I attached a waveform that shows the EMC_a0 line changing in the middle of the read access.

Why am I seeing this behavior?

[bernhardfink]

Hi Robert,

this read burst is a "normal" behavior of this IP block from ARM. We used it in several LPC devices and it is working perfectly fine when an standard SRAM is connected to it. Reading more than one value at a time and store them in buffers is most of the time an advantage for the overall performance. If the next value is requested by the ARM then it is alread in the buffer and can be taken from there without addressing the SRAM again.

For a connection to an FPGA this behavior is nasty, but can't be avoided. You need to design the interface in such a way that these consecutive reads don't hurt..

In this posting you can read a lot about it:  EMC generates double read cycles for static chip selects. 

Hopefully you will program the NXP LPC4357 processor for further couple of years without problems :-)

Regards,

Bernhard.

[cc_lu]

Hi Bernhard,

I have same issue when using LPC4357 EMC with FPGA.

I think this is not "normal" behaviour. LPC4357 EMC can just work fine with SRAM, others device like UART...etc, it will be wrong function.

Is this a  bug for LPC4357 EMC?

[bernhardfink]

Hi Herbert,

let's phrase it this way:  a connection of an SRAM or NOR flash is exactly what this IP block has been designed for.

That's why I would still say that it is a normal behavior and it helps to increase the performance of an SRAM or NOR flash connection.It is for sure not a bug.

For hardcoded UART devices you definitly run into a problem, but if you connect an FPGA you have some room for designing the FPGA memory map in such a way that the useless burst reads don't matter.

As there is a 32-bit read when you request just a byte, you can simply create your memory map on the FPGA in such a wyy that your byte memory locations are 4-byte aligned.

Example:

0000   register 1

0001   dummy

0002   dummy 

0003   dummy

0004   register 2

0005   dummy

0006   dummy

0007   dummy

0008   register 3

   :

   :

Regards,

Bernhard.

[cc_lu]

I have understood the design of EMC original.

But why this limitation of EMC have not any contents in the user manual or datasheet?

[robertmorrison]

Hi Bernhard,

I agree with the concept of caching an extra read on the EMC bus for

performance reasons. I fixed the problem on my FPGA which was reading the

wrong byte to the lpc4357.

However, I believe it would have been wise to have made this a

selectable behavior on the processor. You are correct that prefetching

memory on the EPC wil be more efficient for sequential accesses, but for

any other type of access, such as registers, flags, structure elements,

etc, the accesses will result in longer latency and in my case this

significantlly decreases performance (a very large percentage of my

processor operations go through the FPGA).

Robert

[cc_lu]

Hi Robert,

Can you tell me how to fix the problem with FPGA?

Thanks!

[bernhardfink]

Hi Robert,

I can only agree to this. But modifications on licensed IP blocks like this one are not easy to realize, that's most likley the reason why we didn't make it.

Regards,

Bernhard.

[cc_lu]

Hi Bernhard,

Is the licensed IP blocks designed for all LPC series? Does it include i.MX series?

Thanks!