TM4C123GH6PM: Getting "Target Reset" and "Software reset was performed" messages when I do "download and debug"

Also this is the code I am working with:

#include "tm4c123gh6pm.h"

#define SYSCTL_RCGC2_R          (*((volatile unsigned long *)0x400FE108))

unsigned long arm,sensor;

void delayms(unsigned long ms);

int main(void){

 unsigned long volatile delay;

 SYSCTL_RCGC2_R |= 0x3F;           // Port E and B clock (0b00010010)

 delay = SYSCTL_RCGC2_R;           // wait 3-5 bus cycles

 GPIO_PORTD_DIR_R |= 0x40;       // PD4 output

 GPIO_PORTD_DIR_R &= ~0x07;        // PD2,1,0 input

 GPIO_PORTD_AFSEL_R &= ~0x47;     // not alternative

 GPIO_PORTD_AMSEL_R &= ~0x47;      // no analog

 GPIO_PORTD_PCTL_R &= 0x0F000FFF;  // bits for PD6,PD2,PD1,PD0

 GPIO_PORTD_DEN_R |= 0x47;       // enable PD4,PD2,PD1,PD0

 while(1){

   arm = GPIO_PORTD_DATA_R&0x04;     // PD2: arm 0 if deactivated, 1 if activated

   sensor = GPIO_PORTD_DATA_R&0x03;  // PD1, PD0: 1 means ok, 0 means break in

   if (arm==0x04) {

     GPIO_PORTD_DATA_R ^= 0x40;//0x10;   // toggle output PD4 for alarm

     delayms(100);   // 100ms delay makes a 5Hz period

   }else{

     GPIO_PORTD_DATA_R &= ~0x40;   // LED off if deactivated

   }

 }//while

}//main

/* Subroutine to delay in units of 1 msec

  Inputs: Number of ms to delay

  Outputs: None

*/

void delayms(unsigned long ms){

 unsigned long count;

 while(ms > 0 ) { // repeat while there are still ms to delay

   count = 16000; // number of counts to delay 1ms at 80MHz

   while (count > 0) {

     count--;

   } // This while loop takes approximately 3 cycles

   ms--;

 }

}

Hello Nawar,

Welcome to the jungle. There's a lot down the road that you will need to achieve, and I suggest you aim for the following steps:

1) Give up writing directly to registers (things like GPIO_PORTD_DIR_R |= 0x40). Download and install the Tivaware library from www.ti.com/tivaware, and replace these "hard-to-figure-out" commands for more convenient things like GPIOPinTypeGPIOInput(BASE, PIN);
You will see a ~5Mb manual inside the tivaware/docs folder with many "easy" functions to control everything in your Tiva, like buttons, output pins, timers, uart communication, memory and many more. And your life as a developer will change fast!

2) Learn interrupts - understand that, when you detect a sensor/button pressed, you want to divert your code from the main execution into a small dedicated function that deals with that button.

3) Learn timers, at least the basics of it. If you create a delay using while(x>2000), your CPU can't see or do anything else during your delay - so if, for example, buttons get pressed, your system will not notice it.

4) As for unlocking your board, you say "I don't know why". Well, you need to unlock your board IF YOU LOCKED it (this usually happens if you make a bad configuration of your main clock or mess up with some special pins...). How to unlock? Yes, you got it: download LMFlash, and follow the unlock procedure that is one of the options there. There are several posts teaching it if needed, but it is basically just pay attention to what's on the program screen and follow it. Other "more modern" programs will also do the same, like UniFlash.

Let us know how it goes.

Regards

Bruno

Poster Bruno gave good advice - especially the suggestion to "move FAR/FAST from the (archaic, greatly slowed, and error inviting) "Direct Register Manipulation" (DRM) style of program coding.      Might you tell us, "How & Why" you adopted such a method?

Nawar Youssef said:

Also, I went back to the simple project that was working correctly

That writing signals that your "New Project" may be a, "User Created" Project - is that true?      It is highly unusual for any relatively new poster here - to succeed when they venture to a "Custom - User Created Project."    (this is so as the "furnished projects "automate" the many (necessary settings & configurations) - which often challenge (even) experienced users.     And - most importantly - there is little "payoff" for such "User created project!")

We also use IAR and - if memory serves - (some) control is provided over the assertion of Reset.     As your "initial (simple project)" was reported as working - might you have changed something w/in the IAR configuration?      It seems reasonable to believe that IAR's  "Start-Up" file was altered - after your reporting of  "was working."

The fact that you can (still) download code signals that you are NOT "locked out!"

Thanks for the quick reply, I tired one time to ask questions on one of Atmel forms which it took more than a month for someone to reply to me, so now I'm surprised. Also, I agree about your points and I am going to do so for sure. But for now, as a new graduated in Computer Engineering, I was aiming to learn in deep about Cortex-M4 and how the processor exactly works on a single-bit scale, also to understand more the memory mapping.

I would like to ask: Let's say someone has developed a custom board for specific project using Cortex-M4 processor. Are the TivaWare Library functions you mentioned can be used also for Cortex-M4 processor? Or they work only for Tiva-C LaunchPad?

I am asking because in Computer Engineering industry, many companies use Cortex-M4 processor by impeded it with their own custom boards.

For my problem: I think I am not familiar with the IAR workbench, because I re-worked on what I called "the simple project" and it seems to work even though the messages above still shown, So I assume those messages are part of the " IAR download and debug" process, .

Thank you.

Nawar Youssef said:

Are the TivaWare Library functions you mentioned can be used also for Cortex-M4 processor?

Absolutely YES, is can be used for any Texas Instruments TM4C's (or Tivas) that you employ on your own custom designs.

And in fact, the operations performed by Tivaware calls are quite common to the ones you'd need to do in other processors as well. Somehow, if you want your code ported to a different brand, there will always be the need to configure a timer, or to define that a particular pin is an output GPIO. Meaning that, even for porting code to a totally different IC, it will be easier to start from a "readable Tivaware code" than from a bunch of register numbers!

Good luck on your developments, and keep the news and questions coming (the smart ones, of course!)  ;)

Bruno

Bruno Saraiva said:

...it will be easier to start from a "readable Tivaware code" than from a bunch of register numbers!

Indeed - and while Register (bits) must be properly configured - the requirement extends to first finding  - then determining (which of many Registers) to employ - and (sometimes) even the proper "sequence" of Register programming.

May we ask again - "Why did you choose this "DRM" style of coding?"     You write that you wanted to glean "great understanding" - yet can (turning) pages & pages of the MCU manual - in the attempt to implement the "simplest of functions" - ever (really) make sense?     Yes you need to understand how the Registers are employed - and which ones to choose - but that can ALL BE ACCOMPLISHED thru (vastly more efficient) use of the API - with "Register Review" following in the background.    

Scanning thru the (likely) mass of Registers - we've observed - is likely to "break your focus" upon your (far more vital) problem solving & code strategy!     (i.e. can an "exhausted mind" be an especially alert & creative one?)      And - why is that "natural consequence" of the exclusive use of DRM/ASM - over the API - neither mentioned nor considered?

I do not believe that IAR - when operating properly - causes a "Reset" upon each/every "Debug Launch."      (as often - we set breakpoints - and launch from there - with NO DESIRE to (always) "Return to Reset!"    Somewhere your settings are improper...