Hi,
here is a simple program that reproduces the issue I'm talking about, even without checking register values directly in the debugger (instructions below):
#include <stdint.h> #include <stdbool.h> #include "inc/hw_types.h" #include "inc/hw_memmap.h" #include "driverlib/sysctl.h" #include "driverlib/gpio.h" #define RED_LED GPIO_PIN_1 #define BLUE_LED GPIO_PIN_2 #define GREEN_LED GPIO_PIN_3 int main(void) { SysCtlClockSet(SYSCTL_SYSDIV_5 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN); SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF); SysCtlDelay(10); GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, RED_LED|BLUE_LED|GREEN_LED); // GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, RED_LED); while(1) { GPIOPinWrite(GPIO_PORTF_BASE, RED_LED|BLUE_LED|GREEN_LED,RED_LED|BLUE_LED|GREEN_LED); SysCtlDelay(2000000); GPIOPinWrite(GPIO_PORTF_BASE, RED_LED|BLUE_LED|GREEN_LED, 0); SysCtlDelay(2000000); } } this is used with the Tiva TM4C123 launchpad. notice there are two calls to GPIOPinTypeGPIOOutput(), one of them is commented out. to reproduce the confusing behavior, follow these steps:
1. first build the program as it is.
2. press the debug button, which will switch to debug perspective and load the program to the launchpad.
3. press the red "stop" button to exit the debug mode.
4. the program now runs in the launchpad and the LED flashes white (all R,G,B channels of the LED work). So far so good.
5. now, comment out the first call to GPIOPinTypeGPIOOutput() and uncomment the second one.
6. Again, build the program, press the debug button, and once it's loaded press the stop button.
7. The expected behavior at this point is that the LED will flash in red, as only the pin connected to the red LED is set up as output (the other pins should be at their default mode after reset, which is input mode). however, it actually flashes white (i.e. with all pins active), just as before, because the pin direction register remembers its value from the previous run and it was not reset to the default state.
8. now, turn off the power to the launchpad board and then turn on again. suddenly the LED flashes in red as the code in it was supposed to do in the first place.
this behavior is confusing, especially when debugging something much more complex than this simple example. unless I remember to manually reset the board for each test-run, the test-runs will not give a true indication of whether my code is correct or not.
Thanks for the "system reset" tip, Chester - I discovered this myself too after posting. However it's still manual and it's easy to forget to do that, especially since it "feels" ok if you don't - after all, the code does run, only with subtly altered behavior, which may go unnoticed... this could lead to nasty bugs for someone not familiar with this issue - one time it works, another time (after power cycling) it doesn't, and it feels like a problem just magically appeared or disappeared...
I found no way to do a "system reset" automatically after program load - the reset-after-program option I found did not change the behavior described above. anyone has an automated solution?
thanks,
Guy.