OK, what silly mistake have I made this time..?
I have just downloaded uVision4. Got a simple bit of code to flash and LED on and off.
However, I cannot single step through the code. When I hit Start/Stop Debug session, all other option get greyed out. .
I seem to have gone through all the project options as well as copying my code to a new project. It looks like my problem is similar to Benjamin's (recently posted). tried all his fixes and still nothing works
Here is my code:
#define at91sam7s256 #include <at91sam7s256.h> #define LED (1<<0) // PA0 #define BUTTON1 (1<<19) // PA19 static void initialize( void); int main(void) { volatile long input; volatile int n; volatile AT91PS_PIO pPIOA = AT91C_BASE_PIOA; initialize(); while(1) { input = (pPIOA->PIO_PDSR) & BUTTON1; input = 0; input = BUTTON1; if (((pPIOA->PIO_PDSR) & BUTTON1) == BUTTON1) { pPIOA->PIO_SODR = LED; } else { pPIOA->PIO_CODR = LED; input = (pPIOA->PIO_PDSR) & BUTTON1; } } } static void initialize(void) { //Turn on the peripheral clock. Without this on, inputs do not actually register in the PDSR register volatile AT91PS_PMC pPMC = AT91C_BASE_PMC; // pointer to PMC data structure volatile AT91PS_PIO pPIOA = AT91C_BASE_PIOA; pPMC->PMC_PCER = (1<<AT91C_ID_PIOA); // enable parallel IO controller clock pPIOA->PIO_PER = (LED | BUTTON1); // Set PIO to control LED and button. // Initialize Input pPIOA->PIO_ODR = BUTTON1 ; // Disable outputs for INPUT pins. (not needed as all pins default input on reset) pPIOA->PIO_PPUER = BUTTON1; //Pullup Enable (not needed as all pullups are enabled on reset) // Initialize Output pPIOA->PIO_OER = LED; // Enable output for LED. pPIOA->PIO_SODR = LED; // Turn LED off. pPIOA->PIO_PPUDR = LED; //Pullup disable }
Please let me know
Thanks
Did you do this?
Erase the entire device and try it again.
I did do this - all my own work - with a large amount copied from someone else.
I have tried erasing the flash - both with the jumper setting on the board and using the 'erase full chip' in the utilities menu.
Single stepping does not work at all. It looks like it is trying to work if I do Debug -> Stop, once I have started a Debug session. At least then, the Single Step mode is highlighted, but it still does not single step. If I just hit Debug -> Start/Stop Debug Session, then all options are greyed out.
Having said that, my LED is working per the code, but it is free running, not under the single step control
What you you use your "input" variable for? And why is it declared volatile? Volatile is for variables that may be asynchronously updated. Possibly by another task, if you have an RTOS. Possibly between main loop and an ISR.
The only (questionable) reason for using volatile for an auto variable is if attempting to implement a software loop, and you want to try to stop the compiler from optimizing away the loop.
Next thing - you should consider debouncing your button read. Depending on the mechanical construction of your button and the speed of your processor, you may see the LED flicker a number of times when you press and/or release the button. This flicker is too fast for you to notice with your eye - you have to use an oscilloscope.
This is an interesting comment. You might consider whether the observable behaviour of the program would change if the first two of the following lines of code were removed:
input = (pPIOA->PIO_PDSR) & BUTTON1; input = 0; input = BUTTON1;
Hmmm. removing those lines made no difference.
However, my Blinkey example works in the Keil example code directory. Let me compare this with my code (and setup) and report back...
the input variable was just for debugging
Just to conclude this thread, I now have my code single stepping and free running.
Under the Target Options:
In the Linker Tab: Check the box 'Use Memory Layout from Target Dialog'
In the Debug Tab: Set the Use J-Link radio button (obvious) and in the 'Settings' select your Reset Strategy to Software, for Atmel AT91SAM7 MCUs'
This seemed to fix all of my problems
Sorry, I was making a general comment on the uses of volatile. It wasn't intended as a solution to your problem.
In this case, the two lines just created a bit of extra delay, similar to my mention of using volatile in a software loop with the intention of stopping the compiler from optimizing away the loop.