STM32 debugging can run and exit debugging

shipeng

STM32 debugging can run and exit debugging [Copy link]

I recently encountered a strange BUG that made me full of fear of the unknown. This is a kind of helplessness in the face of unknown problems and a strong sense of crisis about my own inability. The thing is this: Celti: I made a boot loader to boot a FREERTOS APP. In the debug mode (debug APP), you can see that the software can be normally booted to jump to the APP to run, but you can't breakpoint or pause after the freertos initialization, otherwise it will run away in minutes. When running away, the PC value is inside the boot loader. At first, I always thought it was the pot of freertos. But there is no problem running the APP directly without the boot loader. I tried it once and it seemed that there was no problem running the bare metal directly without freertos, but I didn't dare to touch the big brother freertos. Its internal operating mechanism can be said to be all my blind spots. I had no choice but to go to the search engine to find the results, but it seems that no one has ever encountered this problem, and I didn't find a matching result.

I spent several days trying to fix the problem, but it didn't work. I tried a bootloader written by someone else and it seemed to work. I didn't expect it was the bootloader's fault. After comparing, I found that there was a problem with the stack address check before the jump:

if (((*(__IO uint32_t*)APPLICATION_ADDRESS) & 0x2FFE0000 ) == 0x20000000)
	{
	  /* Jump to user application */
	  JumpAddress = *(__IO uint32_t*) (APPLICATION_ADDRESS + 4);
	  Jump_To_Application = (pFunction) JumpAddress;
	  /* Initialize user application's Stack Pointer */
	  __set_MSP(*(__IO uint32_t*) APPLICATION_ADDRESS);
	  Jump_To_Application();
	}

If the if condition does not meet the requirement, it should be changed to if (((*(__IO uint32_t*)APPLICATION_ADDRESS) & 0x2FF00000 ) == 0x20000000). But I don't understand. Isn't it okay to jump to APP during simulation debugging? When emulating and debugging APP, the boot loader will not run, and the emulator will automatically jump to APP to run? Isn't this misleading? If I didn't jump at the beginning, I wouldn't have found the wrong direction and wasted several days of my time. It's really a rip-off.

秦天qintian0303

You should be very careful when jumping directly. The boot and application parts should be compiled separately, and then downloaded together. Separate debugging is definitely only part of it.

shipeng

Qintianqintian0303 posted on 2023-12-1 10:30 You should be very careful when jumping directly. The boot and application parts should be compiled separately, and then they should be downloaded together. It is definitely difficult to debug them separately...

Yes, when I debugged the application part alone, I found that I could enter the main function normally. However, if I let it run by itself, it would not work. I didn't know where it ran to. It was just a coincidence that my printf printing had problems again. Sometimes it could print and sometimes it couldn't. If the printing function was normal, I would have found the root cause of the problem long ago. It happened to be the first time I used SWV to print and debug. There were countless problems. Printing was like double-slit interference, sometimes there was no printing and sometimes there was no printing. BUGs covered up BUGs and it was difficult for even the most powerful people to find them, let alone a novice like me.

秦天qintian0303

shipeng posted on 2023-12-1 19:38 Yes, I found that I can enter the main function normally when I call the application part alone, but it doesn't work when you let it run by itself. I don't know where it ran to. It's really...

Where is printf printing? Your program should have run away, and you can only receive the data before the runaway. You should check the jump carefully. You can add a light control to indicate

shipeng

Qintianqintian0303 posted on 2023-12-1 23:51 Where is printf printed? Your program should have run away, and you can only receive the data before the run away. You should check the jump carefully, and you can add it...

The problem has been solved, but the price paid is a bit high, it took several days to solve it. Because of the abnormal printf function, I overestimated the complexity of the problem, and the superficial analysis of the problem pointed to a completely wrong direction.

秦天qintian0303

shipeng posted on 2023-12-4 10:00 The problem has been solved, but the price paid is a bit high. It took several days to solve it. Due to the abnormal printf function, I overestimated the problem by mistake...

Actually, there is a problem with the program

shipeng

I have two main purposes for posting this:

1. I hope this can help someone who is destined to be with me;

2. To illustrate a point and hope to give you some inspiration: many appearances of problems in simulation analysis are misleading and are meant to trick you into a trap. The key is to use printf more reliably.

I've finished speaking, who's in favor and who's against?