EMC generates double read cycles for static chip selects.

[lpcware]

Content originally posted in LPCWare by Grant.Edwards on Mon Jun 10 09:58:11 MST 2013

I'm having problems getting the LPC1857 EMC configured for use with static peripherals (e.g. external UARTs with 8 or 16-bit wide parallel bus interfaces).

The write cycle configuration appears to work exactly as described in the LPC18xx user manual. However, the read cycle is usually (but not always) twice as long as I've configured. In addition, one or more address lines will change stage half-way through the "double-length" read cycle. The EMC appears to be attempting to read two adjacent addresses every time I do a single read.

The "double length" read doesn't occur all of the time. Perhaps 5% of the time, the read cycle will be the correct length and behave exactly as described in the user manual. AFAICT, whether I get a correct read cycle or a double-length read cycle is completely random. The exact same instruction reading the exact same address can generate a double-length read cycle one time through a loop and a correct read the next time.

I have disabled both page mode and buffering.

Reads are doubled both with and without "extended wait", and regardless of BLS configuration.

I've verified that the code is doing a single ldr.b instruction to read a peripheral register via an 8-bit wide chip select and an ldr.h instruction to read a peripheral register via a 16-bit wide chip select.

Since reading some peripheral registers has side effects (e.g. reading a data byte from a UART), it's not acceptable for the EMC to generate a spurious read from an address adjacent to the one I'm intending to read.

I've been fighting with this issue for a couple weeks now, and have been corresponding with our FAE, but have gotten nowhere.

If anybody has seen this issue (even if you don't know the solution) or has any ideas, please let me know.

[jizhouzhang]

EMC not generates double read cycles!

Run your program in M0APP-core, I use LPC4337.

[lpcware]

Content originally posted in LPCWare by pr242 on Tue Feb 17 17:16:47 MST 2015
I am (was??) about to try and do the same thing on a LPC4337 with an FPGA and a FTDI FT313H (I need 2 x usb device + 1 x usb host)

Those posts are certainly interesting. I assume NXP has no intention of mentioning these issues in errata.

After spending a few days looking at how to do this I'm not sure I'll continue with the NXP part. The EMC interface is really not suitable at all for peripheral interfacing for at least two reasons:

1. The burst feature.
--------------------------
As Grant indicates, making the bus wider than the access will hide this bug if you only use the lower half of the bytes.
The burst still happens but is now contained within the same memory access cycle (which is why multiple BLS lines are asserted). If you are connecting an FPGA no problem, but other devices without holes in the memory map probably can't be used.

2. Almost useless async interface with confusing timing data ( -16ns th(d)? - I assume typo -1.6ns) in the manual, which doe not mention the EMC clock timing relationships)
---------------------------------------------------------------------------------------
The lack of a reference clock makes things very messy. The only way to sync to the EMC clock seems to be from the SDRAM clock and this is not officially supported or documented.

I really wanted to use this part but now I think I'll take another look at the STM32F427. That thing has some horrible bugs (lots more than NXP parts for sure), but I get the feeling that the bugs widely understood. If only ST can finally get the sdram controller to work as advertised...

Cheers
Paul

[lpcware]

Content originally posted in LPCWare by dfuschelberger on Mon Sep 29 01:39:10 MST 2014
Hi guys,

we plan to use the LPC4312 in our new design and the EMC interface will play a major role regarding the system's performance. While googling around I came across this post and am now worried that we might also be affected by the described issue, which would most probably proof being a huge handicap in the end. I took a look at the errata sheet but found no relevant information. Is there someone who is able to provide accurate information regarding this issue?

Thanks and kind regards,
David

[lpcware]

Content originally posted in LPCWare by Grant.Edwards on Thu Sep 25 08:17:21 MST 2014
Another thing to remember is that this product line doesn't have a cache.

That significantly reduces the performance when using external memory in general and SDRAM in particular.  In several of our use cases (e.g. handling TCP connections using SSL), an LPC1830 running at 120MHz provides lower throughput than an ARM7 w/ 8KB cache running at 44MHz.

In other use cases with less locality, the 120MHz NXP provides a  50-100% throughput gain over the 44MHz ARM7.

Omitting a cache seems like a stunningly bad decision to me. But, after using this part for a while, it has become obvious that the external memory support was a last-minute afterthought. I would guess that applications that aren't using external memory would see much less benefit from a cache.

[lpcware]

Content originally posted in LPCWare by Grant.Edwards on Thu Sep 18 11:55:32 MST 2014
As far as we can tell, the bus-width mismatch work-around I described is working and does prevent the double-length read cycles.  I did watch the bus lines with a digital 'scope in "peak-detect" mode for a while, and didn't see any extended length cycles.  I reported this to NXP, but never got any acknowlegement from them that such a result was either expected or had been duplicated by them.

However, if the double-length cycle did still occur occasionally during operation of the product, we wouldn't notice.  The address lines that change state half-way through would not be connected to the peripheral, and the extended cycle time wouldn't cause any problems for our peripherals.

--
Grant

[lpcware]

Content originally posted in LPCWare by rockyh on Thu Sep 18 11:17:01 MST 2014
Thank you Grant for your hard work in determining issue and finding a workaround. Since your old posts indicated you were still experimenting with your solution, I was not sure if it finally worked.  It sounds like that we may be able to use your workaround as well.

[lpcware]

Content originally posted in LPCWare by Grant.Edwards on Thu Sep 18 10:22:47 MST 2014

---

Quote: Grant.Edwards

---

Quote: rockyh

The NXP support solution is to move the memory mapped peripheral to address line A6 onwards, "this prevents additional reads from reaching the peripheral", but will it prevent the doubling of the read cycle?

---

No.  The bus cycle is still twice as long as it should be, and the low-order address bits still increment half-way through the cycle.  The solution is simply to not connect those low-order address bits to the peripheral so that it doesn't see the address change half way through the read cycle.

---

Actually, that's not quite right.  There's no way to prevent the read-cycle doubling when you're doing N-bit reads from an N-bit bus.

If you use reads _smaller_ than the bus width, the cycle-doubling doesn't seem to happen.  For example, we connect an 8-bit peripheral to address lines [A1,A2,A3,...] and configure the bus width for 16-bits.  Then we do 8-bit reads from even addresses, and the cycle-doubling doesn't happen.  Likewise, we connect a 16-bit peripheral to [A2,A3,A4,...] and configure the bus width as 32-bits.  Then we do 16-bit reads on 4-byte boundaries.

This avoids the double-length read cycles, but you have "holes" in your peripheral's memory map.  For our use, those holes aren't a problem.  If part of your peripheral needs to be addressed as a contiguous block of locations, then the bus-mistmatch kludge won't work for you.

--
Grant

[lpcware]

Content originally posted in LPCWare by Grant.Edwards on Thu Sep 18 10:05:53 MST 2014

---

Quote: rockyh

The NXP support solution is to move the memory mapped peripheral to address line A6 onwards, "this prevents additional reads from reaching the peripheral", but will it prevent the doubling of the read cycle?

---

No.  The bus cycle is still twice as long as it should be, and the low-order address bits still increment half-way through the cycle.  The solution is simply to not connect those low-order address bits to the peripheral so that it doesn't see the address change half way through the read cycle.

---

Quote:

This long read cycle is really the problem in our application.  How to prevent this?

---

AFAIK, you can't.  After weeks and weeks of foot-dragging, I finally did get NXP to admit off-the-record that it's a bug, but they didn't give any indication that it would ever be fixed.

---

Quote:

Is there an NXP errata that describes this problem?

---

There wasn't at the time.  There may be one now, but I haven't checked.

--
Grant

[lpcware]

Content originally posted in LPCWare by rockyh on Thu Sep 18 09:39:44 MST 2014
I know this is an old topic, but I may be experiencing this same issue on 4330. The read timing is critical in our application to read a 16 bit value from memory mapped FPGA.
This post provides some workarounds, but I see that there were questions unanswered, so I would like to ask them again:

- The NXP support solution is to move the memory mapped peripheral to address line A6 onwards, "this prevents additional reads from reaching the peripheral", but will it prevent the doubling of the read cycle?  It does not sound like it would. This long read cycle is really the problem in our application.  How to prevent this?

- Is there an NXP errata that describes this problem?

Thanks.

[lpcware]

Content originally posted in LPCWare by BlackJack on Mon Mar 17 06:15:53 MST 2014

Thanks for your reply!

Unfortunately, such a hardware modification will not have a great benefit for me, because the device which I must access is a third party device. Therefore I have to access the odd and even adresses as well. In addition to that this workaround will not prevent the bad behaviour of the long read access, which is still twice along.

Best regards!

[lpcware]

Content originally posted in LPCWare by bavarian on Fri Mar 14 04:09:28 MST 2014
Yes, we know this behaviour of the memory interface on LPC1800 and LPC4300.
There is no setting in software which will prevent the LPC1857 to perform these additional reads.
On the other hand, for the operations the EMC is specified for (connection to asynchronous static memory) this behaviour is not a killer.

From the hardware point of view you could do something:
- start connecting the UART peripheral from address line A6 onwards.
- the first address in your peripheral is then reachabel on address 0x40 = b0100 0000
- additional reads will be done on A[5:0] which will then not reach the peripheral
- if you then use always an offset of 0x3E or 0x3F (0x40 + 0x3E = 0x7E) then the behaviour of the EMC is as good as it can be on this chip platform for this special use case.

So finally I would say that you can continue with the LPC1857 if you are able to make this hardware change.


The LPC1778/88 and LPC4088 (which are a different chip architecture) have an additional bit in the SYSCON block which blocks these additional unwanted reads.

Regards,
NXP Support Team

[lpcware]

Content originally posted in LPCWare by BlackJack on Fri Mar 07 04:29:19 MST 2014
Hello,

I am using the LPC1837 and I have the same problem by using the EMC for static peripherals. The peripheral which I wanna control with the EMC is also an UART with 8bit bus interface.

The write access is working fine, but the read access is not working as defined. During a read access the adress lines are changed. E.g. when I try to read from register 5 (A0=1, A1=0, A2=1) it is working, but nearly at the half way of the read access the adress is incremented by 1 (A0=0, A1=2, A2=1). Why? For better understanding please kindly have a look to the attached picture.

Unfortunately, this behaviour is not acceptable. Has anybody an idea how I can solve this problem? Otherwise I can not use the EMC and it would be only possible to realize the access manually.

Can somebody from NXP give me an statement regarding this issue (bug)?

Best regards

[lpcware]

Content originally posted in LPCWare by wilson.chen on Fri Nov 22 19:26:26 MST 2013

---

Quote: mc
Hi Wilson,
Do you care in case of SRAM whether LPC43xx performs more than once access? I believe there should be no problem.

MC

---

Hello MC

As Edward mentioned  previously:
"the read cycle is usually (but not always) twice as long as I've configured. In addition, one or more address lines will change stage half-way through the "double-length" read cycle. "
"Usually, you see both bus cycles the same as the first one in the trace: it's twice as long as it's supposed to be and address line A0 toggles from 0->1 half way through the access"

I should  take almost twice time to read one data.

[lpcware]

Content originally posted in LPCWare by mc on Thu Nov 21 06:59:23 MST 2013
Hi Wilson,
Do you care in case of SRAM whether LPC43xx performs more than once access? I believe there should be no problem.

MC

[lpcware]

Content originally posted in LPCWare by wilson.chen on Thu Nov 21 03:57:09 MST 2013

I am evaluating LPC43XX for a new project,and using EMC to access SRAM is a must function. 

When will this issue be fixed in LPC43XX or LPC18XX?

Thanks

[lpcware]

Content originally posted in LPCWare by mtesmer on Wed Nov 13 04:43:28 MST 2013

---

Quote: Grant.Edwards
There are two other features of the lpc1830 that we could possibly live without but would miss if they were gone: 1) boot from quad-spi flash 2) IEEE 1588 timestamping support in the Ethernet controller.

---

Sorry to reply for such old topic but this might be useful for author or anybody else.
Quad-SPI was implemented in LPC4088 which (as far as my little LPC knowledge is) is in fact LPC1788 with DSP capabilities. I'm not sure about second requirement while I haven't chance to dig around Ethernet controller yet.

BTW.
Is this EMC issue fixed in silicon or we still waiting for an update?

Best Regards,

[lpcware]

Content originally posted in LPCWare by rgledhill on Wed Jul 17 06:12:57 MST 2013
Hi,

Sorry, you're correct, I was looking at it from an internal perspective for the chip rather than for a fixed implementation in an existing micro - apologies.  The book talks about the ARM Cortex core and does give some examples but nothing specific to the LPC1800.

Kind regards
Richard

(For some reason I never received a notification of your reply...)

[lpcware]

Content originally posted in LPCWare by Grant.Edwards on Tue Jun 18 06:24:34 MST 2013
<div class="author-pane clear-block">
<div class="author-pane-inner">
<div class="author-pane-section author-pane-section-1">
<div class="author-pane-line author-name"><a title="View user profile." href="http://www.lpcware.com/users/bavarian">bavarian</a> wrote:</div>
</div>
</div>
</div>
<p style="padding-left: 30px;"><em>Without going into detail, I can only say that we have seen problems in previous MCU generations and we have done a patch on the memory interface IP block (coming from ARM). But unfortunately we did not take this patch over to the new Cortex generation.</em>

Firstly, thank you for your response. I would be interested in more detail, though.  When it was decided not to carry that fix over into the LPC1800 product line, how was a user expected to connect an external periphal without the fix? Since it was fixed in the LPC1700 Cortex-M3 parts like the LPC1788, why not fix it in the LPC1800 Cortex-M3 parts?

This seems to be a problem that has been known about for a long time, is there an LPC1800 errata that describes it?

<p style="padding-left: 30px;"><em>A software/hardware workaround could be the following: connect the peripheral device to address lines A8 and higher. This requires absolute addressing in software, but in hardware it's a solution which does not affect the BOM.</em>

While this will hide the incrementing address bus lines from the peripheral, it won't prevent the doubling of the read cycle length will it?  The long read cycle times may be a concern due to resource contention within the perpheral if the chip select is held too long.

We're currently testing a work-around where we configure the bus width to 2X the actual peripheral width and then always use accesses of 1/2 the bus width or smaller.  For example, for a 16-bit peripheral we configure the bus width to 32, connect address lines starting with A2, and then use 16 and 8 bit accesses on 4-byte boundaries.   This appears to prevent the double-length read cycles, but there is still a problem with the BLS lines: an 8-bit read still asserts multiple BLS lines when only one should be asserted.  We may be able to live with the BLS problem.

For an 8-bit peripheral, we configure the bus width to 16 and then use only 8-bit accesses (on even addresses). Obviously the BLS problem doesn't affect 8-bit wide peripherals.

Can somebody from NXP confirm that this work-around should be reliable in preventing the doubling of the read cycle?  I've asked our FAE, but he's been unable to provide any information or help on this problem.  He wasn't able to even confirm there was a problem until I pointed out to him how it had been fixed in the LPC1700 family.

The one problem with either work-around is that it will reduce performance in the cases where we would normally use a 32-bit access to read two adjacent 16-bit registers (such an access allows us to dequeue 4 data bytes at a time rather than just 2).

[lpcware]

Content originally posted in LPCWare by Grant.Edwards on Tue Jun 18 05:53:05 MST 2013
<div class="author-pane clear-block">
<div class="author-pane-inner">
<div class="author-pane-section author-pane-section-1">
<div class="author-pane-line author-name"><a title="View user profile." href="http://www.lpcware.com/users/rgledhill">rgledhill</a> wrote:</div>
</div>
</div>
</div>
<p style="padding-left: 30px;"><em>There are different regions of memory space, some of which are accessed as normal RAM, including these extra burst accesses, but some of which are in the "External Device" region which shouldn't be subject to these accesses.</em>
<p style="padding-left: 30px;"><em>Try (if possible) relocating your memory-mapped peripheral into this space - it's address range 0xA0000000 to 0xE0000000 as shown by the picture below.</em>

Sorry if I was unclear.  I'm not desiging a Cortex CPU core into something.  I'm using an NXP LPC1800 uController.  The external chip selects we are discussing are at addresses 0x1c000000, 0x1d000000, 0x1e000000, and 0x1f000000 -- I have no control over their location in the address map.  In the LPC1800, the region 0xa000000 to 0xe0000000 is reserved and generates a fualt when accessed.

The problem appears to be the manner in which NXP has connected the EMC (external memory controller) IP block that they licensed from ARM.  They fixed this problem in the older LPC1700 product line (which includes both ARM7 and Cortex parts), but inexplicably did not fix it in the newer LPC1800 family.

<p style="padding-left: 30px;"><em>This is all in our book ( <a href="http://bit.ly/Zm35Yx">http://bit.ly/Zm35Yx</a> ) :)</em>

Does your book discuss features and problems specific to the NXP LPC1800 product line?

[lpcware]

Content originally posted in LPCWare by bavarian on Tue Jun 18 02:19:34 MST 2013

Without going into detail, I can only say that we have seen problems in previous MCU generations and we have done a patch on the memory interface IP block (coming from ARM). But unfortunately we did not take this patch over to the new Cortex generation.

A software/hardware workaround could be the following: connect the peripheral device to address lines A8 and higher. This requires absolute addressing in software, but in hardware it's a solution which does not affect the BOM.

Regards, NXP Technical Support