LPC Microcontrollers中的主题 Re: EMC generates double read cycles for static chip selects.

EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:42 GMT

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.

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:43 GMT

Content originally posted in LPCWare by wmues on Mon Jun 10 14:17:26 MST 2013

Hmmm... you may want to make a test and use the DMA controller to read a byte.

And you may want to look at the (default) MPU programming for this address area. Is there some sort of buffering/caching enabled in the MPU?

And you can post your EMC configuration code for review.

regards

Wolfgang

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:44 GMT

Content originally posted in LPCWare by Grant.Edwards on Mon Jun 10 14:48:06 MST 2013

<em> Hmmm... you may want to make a test and use the DMA controller to read a byte.</em>

I'll put that on the list of things to try, but it's not an option for a real solution.

<em> And you may want to look at the (default) MPU programming for this address area.</em>

I'm not sure what you mean by that. The configuration I'm using is the default except for the actual lengths of the bus cycles. I'll try using those at their default values also.

<em> Is there some sort of buffering/caching enabled in the MPU?</em>

Based on my reading of the user manual, no.

<em> And you can post your EMC configuration code for review.</em>

Certainly:

<pre>#define EMC_CONTROL *((volatile uint32_t*)0x40005000)
# define EMC_CONTROL_ENABLE 0
# define EMC_CONTROL_MIRROR 1

#define STATICCONFIG3 *((volatile uint32_t*)0x40005260)
# define CNF_MEM_WIDTH         0    /* bus width 0==8, 1==16, 2==32 */
# define CNF_PAGE_MODE         3    /* enable page mode (len=4) */
# define CNF_CS_HIGH           6    /* CS polarity 0=low, 1==high */
# define CNF_BLS_READ          7    /* byte lane active for 0=wr, 1=rd/wr */
# define CNF_EXT_WAIT          8    /* enable extended wait */
# define CNF_BUFF_EN          19    /* buffer enable */
# define CNF_WR_PROT          20    /* enable write protect */

#define STATICWAITWEN3     *((volatile uint32_t*)0x40005264)
#define STATICWAITOEN3     *((volatile uint32_t*)0x40005268)
#define STATICWAITRD3      *((volatile uint32_t*)0x4000526c)
#define STATICWAITPAGE3    *((volatile uint32_t*)0x40005270)
#define STATICWAITWR3      *((volatile uint32_t*)0x40005274)
#define STATICWAITTURN3    *((volatile uint32_t*)0x40005278)

EMC_CONTROL |= Bit(EMC_CONTROL_ENABLE);
EMC_CONTROL &= ~Bit(EMC_CONTROL_MIRROR);

// configure CS3

STATICCONFIG3 =
    (0 << CNF_MEM_WIDTH) | // bus width 0==8, 1==16, 2==32
    (0 << CNF_PAGE_MODE) | // enable page mode (len=4)
    (0 << CNF_CS_HIGH)   | // CS polarity 0=low, 1==high
    (0 << CNF_BLS_READ) | // byte lane active for 0=wr, 1=rd/wr
    (0 << CNF_EXT_WAIT) | // enable extended wait
    (0 << CNF_BUFF_EN)   | // buffer enable
    (0 << CNF_WR_PROT)   | // enable write protect
    0;

STATICWAITOEN3 = 0;    // 15 max   CS->OE delay: N*8.333ns
STATICWAITRD3 = 4;    // 31 max   CS length: 2*(N+1)*8.333ns
STATICWAITTURN3= 2;    // 15 max   bus turn around after read

STATICWAITWEN3 = 0;    // 15 max   CS->WE delay: (N+1)*8.333ns
STATICWAITWR3 = 5;    // 31 max   WE length:    (N+1)*8.333ns

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:44 GMT

Content originally posted in LPCWare by Grant.Edwards on Mon Jun 10 15:03:31 MST 2013
<p style="padding-left: 60px;"><em>And you may want to look at the (default) MPU programming for this address area.</em>
<p style="padding-left: 30px;">I'm not sure what you mean by that. The configuration I'm using is the default except for the actual lengths of the bus cycles. I'll try using those at their default values also.

I tried using the default configuration for everything, and I get the same result: reads are almost always 2X the configured length, with the address lines toggling to the next address half way through the bus cycle.<em>
</em>

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:45 GMT

Content originally posted in LPCWare by Grant.Edwards on Mon Jun 10 15:10:29 MST 2013

I've attached a 'scope screenshot showing what I'm talking about.

The trace shows two read cycles on external static CS3 and was generated by two "ldrb" instructions that are each reading address 0x1f000000. 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. A few percent of the time, you see a correct cycle -- as seen in the bus cicle on the right half of the trace.

Again, the two cycles show in the trace were generated by identical ldrb instructions.

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:46 GMT

Content originally posted in LPCWare by wmues on Tue Jun 11 00:53:07 MST 2013

What you see is perfectly legal...

If you look in the user manual, chapter 19.7.21, Register StaticConfig, Bit "B" (Buffer Enable): there is a hint [2] "EMC may perform burst read access even when the buffer enable bit is cleared".

In LPC178x, the same memory controller is used, see user manual, chapter 9.10 "Memory mapped I/O and burst disable".

For LPC178x, they have added a special bit "EMC burst control" in the SCS register to turn these EMC bursts off. For the LPC185x, they seem to have forgotten to fix this.

(I am VERY happy that I have selected the LPC178x for my project. Everything works).

What can you do?

I would program the EMC memory width to 32bit, but only use 8 bit for the IO interface. So all your UART registers will have an address increment of 4. For every read access, the EMC will fetch 32bit, and you use only 8. If you have luck, the EMC will only burst 32 bits, and you are happy.

If this will not work: switch to the LPC178x!

best regards

Wolfgang

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:46 GMT

Content originally posted in LPCWare by Grant.Edwards on Tue Jun 11 07:54:09 MST 2013
<p style="padding-left: 30px;"><em>If you look in the user manual, chapter 19.7.21, Register StaticConfig, Bit "B" (Buffer Enable): there is a hint [2] "EMC may perform burst read access even when the buffer enable bit is cleared".</em>

Thanks! I somehow missed that footnote. That's certainly a show-stopper if you're trying to use the EMC for memory-mapped IO. It seems rather dishonest of NXP to hide such a major flaw in a footnote.<em></em>

<p style="padding-left: 30px;"><em>I would program the EMC memory width to 32bit, but only use 8 bit for the IO interface. So all your UART registers will have an address increment of 4. For every read access, the EMC will fetch 32bit, and you use only 8. If you have luck, the EMC will only burst 32 bits, and you are happy.</em>

No such luck. Even with the memory width configured for 32-bits, the EMC still does two reads. The only difference is that it increments the address by 4 instead of by 1 as it did with the memory width configured for 8 bits. I think I'm sunk.

<p style="padding-left: 30px;"><em>If this will not work: switch to the LPC178x!</em>

That's not an option: the 178x doesn't have an SDRAM controller. (does it?)<em>
</em>

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:47 GMT

Content originally posted in LPCWare by wmues on Tue Jun 11 08:24:16 MST 2013

I am running the LPC178x in QFP-208 package with:

one 16bit SDRAM at 78 MHz Clock

- a SD card

- 16bit LCD 480x272 Pixel

- one I2C, two SPI (one for a serial 128MB flash)

- Using the ADC for resistive Touch

- an external Port Chip (8bit) hooked onto D16-D23 and A15 (Pins which are not used for SDRAM!)

In the internal flash is a bootloader, code is in serial flash, and copied to SDRAM for execution.

Bootloader programming is done via ISP (V24). Serial Flash programming is done in bootloader from SD-Card.

It's a 2-sided PCB, running most of the wires on layer 1.

I can give you some code for sdram init and sdram calibration (these functions are not simple).

I have thrown the 185x in the trash as soon as I have seen the first errata.... lucky me.

The 178x is a very fine machine..

regards

Wolfgang

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:47 GMT

Content originally posted in LPCWare by wmues on Thu Jun 13 12:38:14 MST 2013

You may get a working solution with the 185x with the following aproach:

- add an external OR-Gate to the Output of /RD, A0, A1 (this will be enough, I think).

- Use the output of the OR gate as /RD to the peripheral.

- Use A2.... as address bus for your peripheral.

- Make all your accesses to the peripheral with A0,A1 == 0.

- If the CPU is doing a 2nd read cycle, A0 and/or A1 will be != 0, and the /RD pulse will be filtered out.

best regards

Wolfgang

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:48 GMT

Content originally posted in LPCWare by Grant.Edwards on Thu Jun 13 13:03:52 MST 2013

Interesting -- I was misled by NXP documentation. If you go to the LPC1788 documentation page, there are two user manuals one is the generic 17xx manual and it never mentions sdram. That's the one I was looking at.

I see from the lpc17[78]x manual that it also has an Ethernet controller (which we require). 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.

I don't remember that the LPC17[78]x family was one of the ones presented to us by the FAE after we sent a list of requirements. Since we required support for external flash (we need at least 4MB of flash), perhaps he only recommended parts that had flashless versions.

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:48 GMT

Content originally posted in LPCWare by Grant.Edwards on Thu Jun 13 13:53:48 MST 2013
<p style="padding-left: 30pa;"><em>You may get a working solution with the 185x with the following aproach:</em>
<p style="padding-left: 30px;"><em>- add an external OR-Gate to the Output of /RD, A0, A1 (this will be enough, I think).</em>
<p style="padding-left: 30px;"><em>- Use the output of the OR gate as /RD to the peripheral.</em>
<p style="padding-left: 30px;"><em>- Use A2.... as address bus for your peripheral.</em>
<p style="padding-left: 30px;"><em>- Make all your accesses to the peripheral with A0,A1 == 0.</em>
<p style="padding-left: 30px;"><em>- If the CPU is doing a 2nd read cycle, A0 and/or A1 will be != 0, and the /RD pulse will be filtered out.</em>

That's sort of what we're testing right now. For our 16-bit peripherals we connect A2,A3,A4,etc. Then we do 16-bit accesses with A0==A1==0. Even if the address does increment half-way though a double-length cycle, it doesn't matter since the peripheral only sees the "correct" address throughout the entire cycle. There's no need to try to filter CS/OE as long as the address seen by the peripheral is unchanged throughout the cycle. [When the EMC does a double read, it doesn't generate two CS pulses and two OE pulses, it generates a single, double-length cycle where the address increments in the middle of the cycle.]

However, further testing shows that when the bus width is greater than the access width, the address _doesn't_ increment and the cycle length isn't doubled. So for our 16-bit peripheral we configure the bus width to 32 (and still access it with A0==A1==0). Likewise, for an 8-bit peripheral we connect A1,A2,A3 and only access it with A0==0. With a bus width of 16 and 8-bit reads, we don't see double read cycles there either.

The one place we still have a minor issue is when we do an 8-bit read from the 16-bit peripheral. The EMC always asserts both BLS0 and BLS1, even though the peripheral requires that for an 8-bit read only one of the BLS lines is asserted. For now, it looks like we can get by without having to do 8-bit reads from our 16-bit part.

After several weeks of asking them, we finally did get NXP to admit that they've known about this problem for ages, and that they had fixed it in the ARM7 families (including the newer M3-based members of the ARM7 families). But, nobody at NXP can tell us whether or not this bug is fixed in the Rev C LPC1830 die that's coming out in a few weeks. The smart money is betting that it isn't fixed.

So, for the moment, we've got a work-around that isn't too painful. It's still rather baffling that NXP thought that the EMC doing read-ahead like that would not cause problems for some peripherals.

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:49 GMT

Content originally posted in LPCWare by mc on Thu Jun 13 22:01:00 MST 2013

<em><span style="font-family: Roboto, sans-serif; font-size: 14px; background-color: #ffffff;">If you go to the LPC1788 documentation page, there are two user manuals one is the generic 17xx manual and it never mentions sdram. That's the one I was looking at</span></em>

Hi Grant,

The user Manual named LPC17xx belongs to LPC175x/6x series of microcontrollers.user Manual

at <a href="http://www.nxp.com/documents/user_manual/UM10470.pdf">http://www.nxp.com/documents/user_manual/UM10470.pdf</a> belongs to LPC177x/8x. Please look into this user manual.

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:50 GMT

Content originally posted in LPCWare by rgledhill on Tue Jun 18 00:55:39 MST 2013

Hi,

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.

Try (if possible) relocating your memory-mapped peripheral into this space - it's address range 0xA0000000 to 0xE0000000 as shown by the picture below.

This is all in our book ( <a href="http://bit.ly/Zm35Yx">http://bit.ly/Zm35Yx</a> ) :)

Let me know how you get on...

Cheers

Richard

Hitex (UK) Ltd

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:51 GMT

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

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:51 GMT

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.

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

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:52 GMT

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).

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:52 GMT

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...)

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:53 GMT

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,

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:54 GMT

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

Re: EMC generates double read cycles for static chip selects.

lpcware — Wed, 15 Jun 2016 18:14:54 GMT

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