This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Odd GPIO errors with stellaris EK-LM4120XL

My project was set up by using project.0 as a template in stellarisware, and replaced the code in its main with my own.

My error is that, for some reason, whenever I use the function GPIOWriteOut, it simply won't do it. I've set up the main to currently just write out 2 pins and enter a while loop and am using a logic analyser to measure their output, and they both remain at a previously set level. I will very occasionally get one of the pins to change, and then for the next several builds and edits it will simply remain at that level without changing, with each of my edits changing the 2 pin's levels. I've used the clean project and rebuild options in an attempt to get rid of any back door issues, but that doesn't seem to work.

  • Hello Drue

    Code post please. Normally to change a pin as GPIO and then control the output levels, the TivaWare provides for 2 API's.

    GPIOPinTypeGPIOOutput(BASE ADDRESS, PIN NUMBER,)
    GPIOPinWrite(BASE ADDRESS, PIN NUMBER, PIN NUMBER) ==> To Set the Pin to 1
    GPIOPinWrite(BASE ADDRESS, PIN NUMBER, 0x0) ==> To Set the Pin to 0

    Also an advise is to Reset the peripheral between runs.... You must use SysCtlPeripheralReset before using SysCtlPeripheralEnable. This will allow clearing off any old setting before every run.

    Regards
    Amit
  • int main()
    {
    initHardware();
    GPIOPinWrite(GPIO_PORTF_BASE,3,0);
    GPIOPinWrite(GPIO_PORTF_BASE,2,1);
    while(1);
    }

    All that was done in initHardware() was to set these pins to output and enable port F.
  • "GPIOPinWrite(BASE ADDRESS, PIN NUMBER, PIN NUMBER)"

    ...describes my problem right there actually. Thank you
  • Drue Satterfield said:
    for some reason, whenever I use the function GPIOWriteOut,

    Have been here since 2006 (LMI forum, then) and have never encountered/noted, "GPIOWriteOut()."   Might you have mis-typed or "mis-remembered?" (favorite response of US politicos - when describing past variances...)

    Be aware that your 2nd & 3rd parameters - w/in (proper) function, "GPIOPinWrite()" may address multiple bits (even all bits!) w/in that port.  This enables you to write to the entire port - in one go.   Parameter 2 - via bit "absence" - enables the "securing" of bits which are to remain unaffected by subsequent port writes.

    Your code reveals use of Port F.  Everyone misses the (badly) marked mention of PF0 (and sidekick) PB7 - defaulting to hallowed NMI - and as a result - failing to behave normally as GPIO.   Your read of MCU manual & hundreds of "crashed/burned" posters here - provides an answer.

    One last - MCU-centric point - your device is NOT equipped with PWM Generators.  (delightful that)   To realize PWM output - you may employ any of the MCU's timers - and config. them as, "PWM."   Manual does a good job there.

    Nature of your post, "strange errors" against the backdrop of many GPIO examples - may indicate that (more) MCU manual along w/Peripheral Library Guide reading will prove extremely useful.  Errors do not qualify as, "strange" when the prescribed MCU code usage is violated... (and no points are awarded for calls to non-existent functions - no matter their creative naming...)

  • Hello Drue,

    Indeed, the usage of the GPIOPinWrite is not correct. Both the 2nd and 3rd parameter must be changed to one hot for 1 pin. For more than one pin on the same port, an OR operator can be used.

    Regards
    Amit
  • Amit Ashara said:
    For more than one pin on the same port, an OR operator can be used.     

    While true - and especially useful for new users - as the number of port pins in play increases - so too the time, effort & chance of typos.

    If posters master the relationship between port pin numbers - and the resultant "bit value" - faster, easier parameter "fills" are enabled.  For example - if all of the port's pins are to be addressed (or set on) 0xFF is proper.  GPIO_PIN_0 has the value "1", GPIO_PIN_2 is "4", pins 0 & 2 (both on) is "5", GPIO_PIN_7 is "128".  One "adds" the (desired) individual, bit position values to enable multiple bits.

    For the many who employ character LCD Modules - and seek pin-saving, "4-bit operation" setting parameter #2 with 0xF0 passes only the upper nibble, 0x0F passes only the lower nibble (of the desired display or command byte.)  Be careful not to "overwrite" or alter that display/command byte - you should simply "prep it" prior to insertion into the GPIOPinWrite() function.  Be mindful that only D7-D4 are "active" w/in the LCD - thus you must perform a "4x" shift-left of the lower display/command byte nibble - prior to presentation to GPIOPinWrite() for output to your 4-bit config'ed display.

    4-bit LCD operation is not w/out peril - initialization is demanding - and has critical timing constraints - and is missed by many.  (most!)