Now, I want to know the start address and length of "_DATA_GROUP_", How can I do it, thanks.
lol
yodl yodl yodl!
It is a misconception that all posters should get answers on their questions, so it is a misconception to think that people who answer don't understand the OP's question if the answers doesn't look like they are a 100% fit for the original question.
Quite often - or maybe I should say VERY often - the OP wants the wrong question answered. It would then be counter-productive to answer the original question. The job then is to try to figure out what problem the OP in reality has, and then suggest a better way of looking at the problem.
If someone asks: How can I switch tires on my car without need for loosening the bolts, the suggestion could be to build a machine that can remove and fit tires - and balance the wheels - while the rim
A very long time ago, there existed operating systems that at each task switch swapped out the full application to disk, before swapping in a new application. A good solution when the memory could only fit a single application at a time. However, not applicable for embedded systems.
No decent operating system should copy a full set of memory, stack or whatever when performing a task switch. The task state is the minimum amount of information that just has to be protected to make the individual tasks behave as expected. I.e. a number of processor registers, and possibly a set of static variables to keep (badly implemented) non-reentrant runtime library functions behaving as expected. If for example a random number generator can't block a task switch while generating a new random number - or if each task is expected to have it's own seed - it might be needed for a task switch to save the internal state of the random number generator. A better solution would of course be to either lock a switch until the next random number has been generated, or let each caller supply a pointer/handle to state information.
Any solution that requires a ISR to swap data could - and should - be rewritten so that it is not needed. A ISR that locks up while waiting for a full line of text should be rewritten so that the serial data is either polled, or the main application explicitly locks up until the ISR have finally inserted enough characters in the receive buffer. For a text-based interface, it would then be enough for the ISR to either flag a buffer overflow, or the reception of a end-of-line or whatever break character that should trig the main application to start doing it's work.
The main application may do anything it likes, since it is always (unless buggy) in a known state when it performs it's actions. An ISR is an asynchronously called function, and hence may be activated at more or less any position in the main application. Because of this, it really should solve a very minimal problem, and then exit.