topic Re: GPIO write immediate read delay needed? in LPCXpresso IDE

GPIO write immediate read delay needed?

lpcware — Thu, 16 Jun 2016 02:12:39 GMT

Content originally posted in LPCWare by larryvc on Thu Mar 17 21:28:03 MST 2011
[LEFT][SIZE=2][COLOR=black]I used the following code and the read returned a 0.[/COLOR][/SIZE] [SIZE=2][COLOR=black]LPCXpresso1769[/COLOR] @ 120 MHZ.[/SIZE][/LEFT]

[LEFT][SIZE=2][COLOR=black]Is a delay needed after setting a bit and then reading it or should I be using a different method to accomplish this?[/COLOR][/SIZE][/LEFT]

[LEFT]LPC_GPIO0->FIOSET = (1 << 22);
MESSAGE("GPIOPIN: %08X\n", LPC_GPIO0->FIOPIN & (1 << 22));[/LEFT]

[LEFT]This worked.[/LEFT]

[LEFT]LPC_GPIO0->FIOSET = (1 << 22);
for (i=0;i<1;i++);
MESSAGE("GPIOPIN: %08X\n", LPC_GPIO0->FIOPIN & (1 << 22));[/LEFT]

Re: GPIO write immediate read delay needed?

lpcware — Thu, 16 Jun 2016 02:12:39 GMT

Content originally posted in LPCWare by larryvc on Fri Mar 18 09:48:13 MST 2011
Can anyone tell me how many cycles are needed after the write for the LPC_GPIO0->FIOPIN register is performed before a read of that register will show the bit change? Is this documented somewhere?

The first example returns 0x00000000

The second returns 0x00400000
[SIZE=2][COLOR=#0000c0][SIZE=2][COLOR=#0000c0][/COLOR][/SIZE][/COLOR][/SIZE]

Re: GPIO write immediate read delay needed?

lpcware — Thu, 16 Jun 2016 02:12:40 GMT

Content originally posted in LPCWare by rmteo on Fri Mar 18 10:01:31 MST 2011
I came across this on page 138 of the LPC17xx UM:

Quote:
[U][B]6.2 Writing to FIOSET/FIOCLR vs. FIOPIN[/B][/U]

Writing to the FIOSET/FIOCLR registers allow a program to easily change a port’s output pin(s) to both high and low levels at the same time. When FIOSET or FIOCLR are used, only pin/bit(s) written with 1 will be changed, while those written as 0 will remain unaffected.

Writing to the FIOPIN register enables [I][B]instantaneous output[/B][/I] of a desired value on the parallel GPIO. Data written to the FIOPIN register will affect all pins configured as outputs on that port: zeroes in the value will produce low level pin outputs and ones in the value will produce high level pin outputs.

Re: GPIO write immediate read delay needed?

lpcware — Thu, 16 Jun 2016 02:12:41 GMT

Content originally posted in LPCWare by larryvc on Fri Mar 18 10:05:34 MST 2011
Thanks rmteo. I will try FIOPIN.

Re: GPIO write immediate read delay needed?

lpcware — Thu, 16 Jun 2016 02:12:41 GMT

Content originally posted in LPCWare by larryvc on Fri Mar 18 10:17:52 MST 2011
I get the same result as before so there must be a setup time required before the register can be read.

Replacing the for loop with[SIZE=2] __asm volatile("nop"); returns 0X00000000 as well.[/SIZE]

Re: GPIO write immediate read delay needed?

lpcware — Thu, 16 Jun 2016 02:12:42 GMT

Content originally posted in LPCWare by larryvc on Fri Mar 18 14:44:52 MST 2011
I created a new semihosting project and copied the source files there and it worked.

I had optimization = -O3 (most) in the previous project. The code only works with optimization = -O0 (none).

Re: GPIO write immediate read delay needed?

lpcware — Thu, 16 Jun 2016 02:12:42 GMT

Content originally posted in LPCWare by Ajay on Sat Mar 19 10:40:49 MST 2011
Hi Larry,

Did you have a need to measure the rise time of the GPIO pin of the micro? What worked, changing the optimization level but keeping the NOP instruction? Also, did you have a need to optimize for code size to stay within the 128K limit of the debugger?

Ajay

Re: GPIO write immediate read delay needed?

lpcware — Thu, 16 Jun 2016 02:12:43 GMT

Content originally posted in LPCWare by larryvc on Sat Mar 19 11:29:21 MST 2011
Hi Ajay,

Unfortunately my scope died and is in for repair so I haven't scoped the pins yet. I don't think there is a problem at the pins.

I looked at the disassembly of the code produced with optimizations other than -O0 and it showed a STR immediately followed by a LDR. The read appears to occur before the data has propagated to the register. A small delay longer than a NOP (two instructions, not NOPs, worked) seem to allow enough time for data to propagate to the register and for the read to succeed with correct data.

Is this an illusion maybe caused by the debugger? I don't think so.

I'm still investigating this and will scope the pins as soon as I can get my hands on a scope. Triggering on an instruction may be difficult.

Can anyone suggest a low cost logic analyzer? One with 16 data lines and a reasonable sampling rate would be nice.

Re: GPIO write immediate read delay needed?

lpcware — Thu, 16 Jun 2016 02:12:43 GMT

Content originally posted in LPCWare by Ex-Zero on Sat Mar 19 12:58:40 MST 2011
With my 100MHz LPC1769 it's enough to delay 2 NOPs before reading back correct FIOPIN.

NOP = 1 cycle instruction, so that's 20ns overall.

  *p_array++ = LPC_GPIO0->FIOPIN;
0x00000344 <main+68>:  mov   r7, r5
0x0000034a <main+74>:  mov   r5, sp
0x0000034c <main+76>:  ldr   r3, [r7, #20]
0x0000034e <main+78>:  str   r3, [r5, #0]
[COLOR=red]LPC_GPIO0->FIOSET = (1<<0);[/COLOR]
0x00000346 <main+70>:  mov.w r8, #1
0x00000350 <main+80>:  str.w r8, [r7, #24]
[COLOR=blue]__ASM("nop");[/COLOR]
0x00000354 <main+84>:  nop   
[COLOR=blue]__ASM("nop");[/COLOR]
0x00000356 <main+86>:  nop   
[COLOR=red]*p_array++ = LPC_GPIO0->FIOPIN;[/COLOR]
0x00000358 <main+88>:  ldr   r3, [r7, #20]
0x0000035e <main+94>:  str   r3, [r5, #4]
  *p_array++ = LPC_GPIO0->FIOPIN;
0x00000360 <main+96>:  ldr   r2, [r7, #20]
0x00000366 <main+102>: str   r2, [r5, #8]

Re: GPIO write immediate read delay needed?

lpcware — Thu, 16 Jun 2016 02:12:44 GMT

Content originally posted in LPCWare by larryvc on Sat Mar 19 14:19:51 MST 2011

Quote:
With my 100MHz LPC1769 it's enough to delay 2 NOPs before reading back correct FIOPIN.

NOP = 1 cycle instruction, so that's 20ns overall.

I had assumed that 2 NOPs would not work as I had read in another post "Note: Don't use a nop behind another nop, this doesn't work. You also get a 10ns delay".:p:) So I never tested 2 NOPs in succession.

It works! So the propagation delay is >10ns and <=20ns @ 100-120 MHZ. Good to know!

Danke