Writing to GPIO reg

[lpcware]

Content originally posted in LPCWare by graynomad on Sun Jul 08 07:50:10 MST 2012
I told you guys there would be questions

I finally received my Xpresso boards, plugged one in and downloaded the few 1000 lines of code I've been writing while waiting for hardware. Blow me down if most things seem to work, software timers with callback functions, all sorts of stuff I've written to get a feel for the system.

And then I hit a brick wall on something that should be a non-event.

I don't seem to be able to write to GPIO0, any of it but let's look at the direction reg.

The actual code uses indexes into lookup tables of pointers etc etc, the debugger verifies that this is working but to get to the nitty gritty the end result is this

   LPC_GPIO0->DIR = 0x80;

Which I think sets P0:7 as an output.

Single stepping and viewing the reg in the debugger shows that the value is not written. The ASM code is as follows (some comments are mine)

     LPC_GPIO0->DIR = 0x80;
movs r3, #160   ; 0xa0
lsls r3, r3, #23   ; 0xA0 << 23 == 0x50000000
movs r2, #128   ; 0x80
str r2, [r3, #32]  ; r3 + 32 ==  0x50000020

Surely this is writing 0x80 into address 0x50000020 AKA the GPIO0DIR register but the debugger still shows 0 in the reg.

I also can't write anything to that (or indeed any) register using the debugger, I can type a value and hit enter but it reverts to 0.

BTW so far I love this system, the above code of course had bugs, one that caused a hard fault, I look back up the stack frame and quickly find a bad index into a list of pointers to functions. That would have taken all night and more to find using printf-debugging on an Arduino or similar.

[lpcware]

Content originally posted in LPCWare by js-nxp on Mon Jul 09 17:30:25 MST 2012

---

Quote:
Yep, P0:7 is the LED.

---

:o Need my glasses adjusted :o I thought you said GPIO0:0

[lpcware]

Content originally posted in LPCWare by graynomad on Mon Jul 09 07:26:05 MST 2012

---

Quote:
Have you looked at the diagram for the board?        

---

Yep, P0:7 is the LED.

---

Quote:
And which LPCXPRESSO are we talking about?

---

LPC1227.

---

Quote:
You should first switch the function of those pins to GPIO before setting the direction

---

Done.

---

Quote:
Check the IOCON registers. As Serge already said, there are some pins  especially on Port 0, which don't have the GPIO function as default.        

---

Done.

---

Quote:
Have you enabled the clock for the GPIO and IOCON block ?

---

---

Quote:
Is the clock for the GPIO peripheral enabled ?

---

[B]That's it.[/B]  Thank you guys. For future reference on the LPC1227 the code is

    // Enable clock for GPIO port 0.
    LPC_SYSCON->SYSAHBCLKCTRL |= (1<<31); 

Note that the IOCON clock (bit 16) was already set, not sure where yet  but presumably in the start up code or somewhere. I'll hunt that down,  and also look into what other clocks I need.

---

Quote:
That is the most common trap in Cortex Mx development, there is almost nobody that did not yet step in

---

Now I can join that not-so-exclusive club

Thanks again everyone.

[lpcware]

Content originally posted in LPCWare by frame on Mon Jul 09 05:01:31 MST 2012
ArnesB's second hint is much more important:
Is the clock for the GPIO peripheral enabled ?

That is the most common trap in Cortex Mx development, there is almost nobody that did not yet step in. And, it is usually NOT noted in the respective reference manual section of the peripheral unit, but only in the system control/clock generation section.
All peripheral clocks are off after reset, and writing to unclocked peripheral registers has the described effect, i.e. none.

[lpcware]

Content originally posted in LPCWare by js-nxp on Mon Jul 09 00:59:15 MST 2012
In my case I'm talking about the LPC1114 Xpresso. :)

[lpcware]

Content originally posted in LPCWare by ArneB on Mon Jul 09 00:40:29 MST 2012
It would be helpful, if you can mention, which LPC controller you are using...

Just two hints:
- Have you enabled the clock for the GPIO and IOCON block ?

// Enable GPIO clock for the LPC11xx family...
LPC_SYSCON->SYSAHBCLKCTRL |= ((1<<16) | (1<<6));

- Check the IOCON registers. As Serge already said, there are some pins especially on Port 0, which don't have the GPIO function as default.

[lpcware]

Content originally posted in LPCWare by serge on Sun Jul 08 23:28:37 MST 2012
And which LPCXPRESSO are we talking about?
Anyway GPIO is not the standard function of P0. You should first switch the function of those pins to GPIO before setting the direction and eventualy the pull-ups or pull-downs.
I do hope Zero agrees with me?

[lpcware]

Content originally posted in LPCWare by js-nxp on Sun Jul 08 23:10:47 MST 2012

---

Quote:
but I still can't change anything in GPIO0.

---

But that's the reset pin also used by JTAG so it may be locked in other strange modes. ie locked to JTAG unless you change pin mode, don't know if it is even possible without losing JTAG.

Have you looked at the diagram for the board?

[lpcware]

Content originally posted in LPCWare by graynomad on Sun Jul 08 21:38:05 MST 2012

---

Quote:
You are not alone

---

Thanks, it sure feels that way sometimes out here in the boonies. I'm hoping one of the NXP or CR guys will have an answer but it's still Sunday over there I guess.

My code does look like yours so I'm stuffed for the time being.

Update...

I can write into the P0:7 IOCONFIG register, both in code and in the debugger so there's nothing fundamentally wrong with things I guess, but I still can't change anything in GPIO0.

[lpcware]

Content originally posted in LPCWare by js-nxp on Sun Jul 08 16:31:59 MST 2012
You are not alone http://knowledgebase.nxp.com/showthread.php?t=2636

I just had a look at my GLCD code which I ported from the "other" compiler (both types of chips with the X and without) and I can't figure out what I did after 6 months. :confused:

some code snippets

 #define GLCD_DB_DDR  LPC_GPIO2->DIR
 #define GLCD_DB_PORT LPC_GPIO2->DATA
 
 #define GLCD_SET_DB(x) GLCD_DB_PORT = x
 #define GLCD_INPUT() GLCD_DB_DDR = 0x00;     
 #define GLCD_OUTPUT() GLCD_DB_DDR = 0xFF;

I needed the macro to make the rest of the code unchanged, so it looks as if your code should work.