How to load program into SRAM for debugging

Feel you pain - but might there be far faster/simpler means - to achieve your objective?

Our group "lives/breathes" KISS. (always appropriate for this reporter)  Again - fully accept your concerns - seek only to steer you into simpler - yet still "Safe Harbor"...  (Catalina bound < week - boat fever alive/well)

So - would not the addition of a short, simple code loop - which awaits a gpio bit's toggle - to then and only then - execute the "serious/business" portion of your program - suffice?  Prior to entry into this, "simple loop" - your program would perform all necessary MCU initialization - making all peripherals ready.  The program then, "sits in this loop" awaiting that bit-toggle to launch.

While I leave this for you - this method may be extended so that another bit - or that same one - can return the program to the simple, starting loop - which should cause all "serious/business" code operations to cease.  (via a call to pre-loop initializations...)

And - this same method enables "multiple programs" or even variants of your critical code - to run individually so that "A-B-C" (or beyond) comparisons are neatly accommodated...   Works for us - perhaps you, too...

You are most welcome to suggest me one . So that I dont have to program SRAM and still code does not run on its own. 

Do note that our posts "crossed" & that I, "composed live" (on the road to client - mobile, of course) & dumped to forum (early - in parts) so that the whole writing would not be lost/corrupted...

Yeah this is one way to have control over the code. 

But now can you please let me know how to program it into SRAM instead of flash. 

I know I need to change linker command file .cmd but I dont know the details and how and from where I can do this. 

If you can cite some document or tell me how to do it , it would be really helpful.

Thanks,

Ishan

Well - I do know & have done that - but is not that outside/beyond your original request? 

Is it not a bit "off-putting" to your fast, detailed "helpers" to have their valid, alternative method - so rejected?

Method earlier described meets your stated, "program safety" objectives - and provides additional benefits as I further outlined.  And - you specifically asked for/sought, [I.I.: "So that I dont have to program SRAM and still code does not run on its own"] - and I answered w/precision - and now the target/cheese has moved!  Not good - and not for me...

If your "real" (hidden) agenda was programming into SRAM only - perhaps that should have been more clearly stated - your initial AND 2nd posting...  (such posts usually do not "end well" - thus are outside my time/interest...)

If you look at the question(Topic headline says " How to program SRAM for debugging "). other suggestions/solutions included in question was secondary. If in future some other reader reads this discussion and is looking for how to program SRAM he/she will not get the answer but will only learn on how to ask questions without talking anything else. !!! Thanks to you !!!

No disrespect to you. Your solution is good  and can be done, but I would like to have two options with me. So its up to you know if you want to tell me how to program SRAM ??!!.

Also I will have to spare 1 GPIO connect give it input, in my densely populated board. Sorry for saying " So that I dont have to program SRAM " I take it back.

Recall that the subject/title does not readily appear for view (lost via the necessity to scroll) once the post is opened!  (but I do thank you for that forum usage suggestion) 

Along w/engineering/programming - I read/write/review contracts for a living.  Your first writing, "So is there anything can be done so that program does not run without me commanding it to run from debug perspective," seems nicely addressed & answered.   Does not that statement - occurring long after and twice repeated, not serve to over-ride the brief, earlier, forum-hidden SRAM mention? 

Record here fairly reveals that I've met/exceeded your request w/imagination & even extended the benefits you sought.  (i.e. enabled multiple such programs, code-snippets to safely "co-exist" - and execute individually - under your full command - importantly either w/in or outside your command - from the debug perspective...)

I have tried hard to meet your requirement - remained w/in the boundaries set by multiple of your posts - and believe that the KISS approach I've outlined even extends features & benefits.

The more complex request you've now seized upon requires added time/effort and provides no, "safe harbor assurance" - that even it will fully satisfy...  (moving targets are more difficult to hit...)

You may quickly/easily "modify" your post's subject/title to better reflect the full satisfaction of your, "Control Program Execution when operating outside the Debugger," which indeed persists in being truly central to this thread...