Some summary about IAR -- the difference between ARM debugging and Flash debugging

I have been immersed in writing my graduation thesis recently . I feel like I am "turning a deaf ear to the world outside and focusing on writing my graduation thesis". I feel numb from staring at word, viso, CNKI client and other text editing tools all day long. I don't know until I write a thesis. I am shocked when I write a thesis. I feel that writing tens of thousands of lines of code is easier than sitting in front of the computer to write tens of thousands of words of the thesis. "How much sorrow can you have? It is like a river of spring water flowing eastward." Hey, I suddenly realized that the most painful thing in life is not that people die and have no money to spend, but that I have been writing a thesis for more than ten days and then found that I have not written more than half of it. But there is no way, I can only bite the bullet and write it. Before that, I'd better update my blog, otherwise it will sink to the bottom of the dust (it seems that I haven't updated for a long time, but fortunately I am not writing a novel, otherwise I will be criticized), haha~

Without further ado, let's get to the point. In fact, I only came into contact with the concepts of Flash debugging and RAM debugging when I was debugging Kinetis. At first, I just used them casually without going into detail. After using them more, I began to study the differences between the two in depth and found that there is a lot to be learned. This is why I later changed the prefix of this article to [Original Fine Goods]. I looked through some information on the Internet, most of which were articles that taught people how to fish, so I felt it necessary to talk about my own views here and make a note:

The above picture shows the Flash debugging interface and RAM debugging interface in the IAR environment.

First, let's talk about what Flash debugging and RAM debugging are. Flash debugging is ordinary debugging in the usual sense, which is to download the compiled and linked code to the ROM area of ​​the microcontroller, put the data in the RAM area, and then debug; while RAM debugging is to put the data in the RAM area and then open up an extra space in the RAM area to store the executable code, so that the code and data run in the RAM area at the same time.

As for why we need to deliberately distinguish these two debugging methods, in fact, there is no concept of RAM debugging in the field of low-end MCUs. A large part of the reason is that there is not enough RAM space to store the compiled code and still have extra space for data RAM. In the field of high-end MCUs, such as ARM, dozens of KB of RAM are very common. Without running super-large projects, it is entirely possible to use part of the space to run the code, so the method of RAM debugging has emerged.

Compared with Flash debugging, RAM debugging has two inherent advantages. One is that the number of times RAM can be erased and written is theoretically unlimited. During the debugging of code, we often need to continuously download updates, and the number of times Flash can be erased and written is limited (usually tens of thousands or hundreds of thousands of times, which seems to be enough, but it is also painful). Therefore, we can choose RAM debugging during debugging. On the other hand, RAM debugging is even more of a strength (Flash is really tragic). The code execution rate and efficiency in the RAM area are much higher than the code that needs to be constantly read and written in the Flash area. There is no doubt about this . Therefore, in today's era of smartphones competing in hardware, we should choose a powerful CPU, but if you want the system to run more smoothly, a large enough onboard RAM is a must, haha. Of course, the disadvantage of RAM debugging is that the code will be lost when the power is off. The code running in the RAM area will not be saved when the power is off. The next time the microcontroller is powered on, it will still execute the old code in the Flash area. This is something that needs attention. Many people forget to consider this point. After the RAM debugging function is completed, when they get the microcontroller to run independently on site, they find that the program is wrong. Ahem, of course it is wrong...

The theoretical part is introduced. Now let's analyze how to implement Flash debugging and RAM debugging in combination with the IAR development environment. In fact, after careful study, we found that the difference between Flash debugging and RAM debugging in IAR is just the difference in the .icf configuration file. It is actually very simple and easy to understand. It just changes the memory mapping of the microcontroller. The following is a list of the differences between the two (the important parts are annotated for reference):

256KB_Pflash.icf file for flash debugging:

/*-Specials-*/ 
define symbol __ICFEDIT_intvec_start__ = 0x00000000;/* The starting address of the interrupt vector is the first address of ROM*/ 
/*-Memory Regions-*/ 
define symbol __ICFEDIT_region_ROM_start__ = 0x0; 
define symbol __ICFEDIT_region_ROM_end__ = 0x00040000;/* 256k ROM space*/ 
define symbol __ICFEDIT_region_RAM_start__ = 0x1fff8410; 
define symbol __ICFEDIT_region_RAM_end__ = 0x20000000;

…

define exported symbol __VECTOR_TABLE = 0x00000000;/* The interrupt vector table is placed at the starting address of ROM area 0*/ 
define exported symbol __VECTOR_RAM = 0x1fff8000;

…

define symbol __code_start__ = 0x00000410;/* The code start area address is in the ROM area*/

…

place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec }; 
place at address mem:__code_start__ { readonly section .noinit };

place in ROM_region { readonly, block CodeRelocate}; /* Place the read-only code in the ROM area*/

place in RAM_region   { readwrite, block CodeRelocateRam, 
                        block CSTACK, block HEAP };

64k_ram.icf file for RAM debugging:

/*-Specials-*/ 
define symbol __ICFEDIT_intvec_start__ = 0x1fff8000;/* The starting address of the interrupt vector is the first address of RAM*/ 
/*-Memory Regions-*/ 
define symbol __ICFEDIT_region_ROM_start__ = 0x0; 
define symbol __ICFEDIT_region_ROM_end__ = 0x0;/* Set the ROM space to 0 */ 
define symbol __ICFEDIT_region_RAM_start__ = 0x1fff8000; 
define symbol __ICFEDIT_region_RAM_end__ = 0x20000000;

…

define exported symbol __VECTOR_TABLE = 0x1fff8000;/* The interrupt vector table is placed at the first address of the RAM area*/ 
define exported symbol __VECTOR_RAM = 0x1fff8000;

…

define symbol __code_start__ = 0x1fff8410;/* Set the code start address in the RAM area*/

…

place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec }; 
place at address mem:__code_start__ { readonly section .noinit };

place in RAM_region { readonly, block CodeRelocate }; /* Place the read-only code in the RAM area*/

place in RAM_region   { readwrite, block CodeRelocateRam, 
                        block CSTACK, block HEAP };

    I won't explain the above code in detail. I estimate that most bloggers should understand it through comments and comparisons. If you don't understand, please leave a message below to discuss it together. Of course, you are welcome to vote. This blog was first published on ChinaAET. Please indicate the source and the original author jicheng0622's information when reprinting. Thank you for your understanding. Let's talk more. To be continued~