What causes DSP program to crash? How do you solve it?

　　What are the reasons for DSP program failure? How do you solve it? Brainstorming in the name of academics is spreading in the Electronics Fan Network Forum. Let's take a look at the dry goods that you deserve.

　　michael_xing:

　　Let me first talk about my previous project experience.

　　There are two general steps for debugging code

　　Solution 1: Debug the main program first, and then add protection circuits such as watchdogs;

　　Solution 2: First build the code environment, such as the watchdog protection circuit, and then develop the main program on this platform.

　　As for me, in order to better write algorithm code, I often adopt option 1.

　　When I was debugging the code, I encountered the following situation where the program ran away:

　　【Cause】Wrong design of hardware watchdog circuit

　　[Design] In the scheme I designed, I used the Maxim chip MAX706AT to design the hardware watchdog circuit. It seemed to be a perfect circuit. However, when I connected the simulator to perform a simple square wave output test, I found that the DSP had no task output. The program was abnormal. Because I used scheme 1 to design the code, I only knew the abnormality but not the reason.

　　【Solutions】

　　1. Download the program countless times and run it, but the program always runs abnormally.

　　2. Fortunately, there are several IOs in my circuit design that directly drive LEDs. At this time, I especially noticed that the brightness of the LED display was abnormal. Then, I quickly took a multimeter to test the IO voltage, and the result was only about 1.6V. At this time, I already knew that the watchdog was abnormal.

　　3. Check the MAX706AT circuit in the circuit, and there is no problem at all. When looking for the package and pin correspondence of MAX706AT, the root cause of the problem was found. The chip has two packages, SO and UMAX. Strangely enough, the names are exactly the same, but the packages are different, and the pin definitions are different, which causes the reset voltage of the watchdog chip to always be low.

　　Finally found the problem.

　　michael_xing:

　　When I was debugging the code, I encountered the following situation where the program ran away:

　　【Cause】Interrupt processing timeout caused the program to run away

　　[Design] I designed a bipolar signal acquisition system based on TMS320F28335 (4). Because the frequency is high, I adopted the interrupt acquisition method. That is, I used PWM to output square waves to trigger the acquisition module to start acquisition. After the acquisition is latched, it will interrupt

　　Tell DSP to read data. Then the data reading is done in the interrupt.

　　In the first version, a period of 20ms/256 was used for sampling triggering.

　　A very strange problem occurred. In DEBUG mode, there was no problem and data could be collected. However, in RELEASE mode, the program ran away when collecting data.

　　When I realized that the program was running away, I suspected that the interrupt program was too long or the processing time was too long.

　　【Solutions】

　　It is guessed that the period is too short, so the period can be increased, period = 20ms/128, and it still fails.

　　Subtract the period = 20ms/64, okay.

　　It is better to pursue the enemy with all the remaining courage, and reduce the cycle to = 20ms/32, okay

　　This solved it the first time.

　　[Appendix] When using DSP for algorithm processing, be sure to evaluate the algorithm first. Otherwise, when you realize the problem with your program, it will be too late, because after the parameters are modified, they may not meet the system requirements.

　　Cresta:

　　The reasons why DSP programs run out of control that I have encountered are:

　　1. Accidentally operate the sub-function return address value.

　　2. Numerical overflow, reading or writing storage space beyond the range, stack overflow, etc.

　　The program is a BIOS program. When the program runs out of control, I set a breakpoint at the last line of the main function. As a result, the program can run to the last line of the main function. The next step is to initialize the BIOS operating system. The source code of the operating system is invisible, so I am stuck for a while. I don't know what to do.

　　The program went wrong when I was porting it. Later, I compared the BIOS configuration of my program with another normal BIOS configuration and found that the Stack Size was 0x400 (the default configuration) while the other was 0x1000. After I changed it, the program returned to normal.

　　At the beginning, I also realized that the program might run away due to stack overflow, so I increased the dynamic stack on each memory block, that is, create a heap in this memory heap size: 0x08000. It didn't work.

　　Later I changed the Stack Size (MAUs) option, i.e. the global stack size, from 0x400 to 0x1000. Then the problem was solved. Later I realized that the dynamic stack is used to dynamically create tasks, not the stack I wanted. After reflection, I felt that it was a big mistake caused by my unfamiliarity with the BIOS system!

　　Ice Age:

　　I have encountered MCU programs running wildly, static interference, overclocking, and instability.

　robi:

　　Share the reasons why the program often runs out of TI DSP debugging

　　1) The program has no ending or is not a looping program.

　　2) The nmi pin is not pulled up.

　　3) The program will often run away when the watchdog is in effect.

　　4) Improper programming can also cause the program to run wild.

　　5) There is a problem with the hardware system

　　liulin126:

　　Numeric overflow, reading or writing storage space beyond the range, stack overflow, are the main causes of exceptions.

　　wjw1989:

　　I played arm before, so the principle should be the same.

　　The principle of resetting the chip is to prevent program errors. However, abnormal problems cannot be solved by resetting. Therefore, the code must be debugged first to ensure normal operation of the code, and then the reset module can be added. Only in this way can the product be made well. Otherwise, it will be reset for the sake of resetting.

　　wjw1989:

　　Share someone else’s experience:

　　The reasons why DSP programs run out of control that I know of are:

　　Hardware: 1. The reset circuit is unstable; 2. The power supply is unstable; 3. The ground wire is unstable.

　　Software: 1. Accidentally operated the sub-function return address value.

　　2. Numerical overflow, reading or writing storage space beyond the range, stack overflow, etc.

　　My program is a BIOS program. When the program runs out of control, I set a breakpoint at the last line of the main function. As a result, the program can run to the last line of the main function. The next step is to initialize the BIOS operating system. The source code of the operating system is invisible, so I am stuck for a while. I don't know what to do.

　　The program went wrong when I was porting it. Later, I compared the BIOS configuration of my program with another normal BIOS configuration and found that the Stack Size was 0x400 (the default configuration) while the other was 0x1000. After I changed it, the program returned to normal.

　　At the beginning, I also realized that the program might run away due to stack overflow, so I increased the dynamic stack on each memory block, that is, create a heap in this memory heap size: 0x08000. It didn't work.

　　Later I changed the Stack Size (MAUs) option, i.e. the global stack size, from 0x400 to 0x1000. Then the problem was solved. Later I realized that the dynamic stack is used to dynamically create tasks, not the stack I wanted. After reflection, I felt that it was a big mistake caused by my unfamiliarity with the BIOS system!

　　wjw1989:

　　Friends also shared some, which are summarized as follows:

　　The reasons why DSP programs run out of control that I know of are:

　　Hardware: 1. The reset circuit is unstable; 2. The power supply is unstable; 3. The ground wire is unstable.

　　Software: 1. Accidentally operated the sub-function return address value.

　　2. Numerical overflow, reading or writing storage space beyond the range, stack overflow, etc.

　　My program is a BIOS program. When the program runs out of control, I set a breakpoint at the last line of the main function. As a result, the program can run to the last line of the main function. The next step is to initialize the BIOS operating system. The source code of the operating system is invisible, so I am stuck for a while. I don't know what to do.

　　The program went wrong when I was porting it. Later, I compared the BIOS configuration of my program with another normal BIOS configuration and found that the Stack Size was 0x400 (the default configuration) while the other was 0x1000. After I changed it, the program returned to normal.

　　At the beginning, I also realized that the program might run away due to stack overflow, so I increased the dynamic stack on each memory block, that is, create a heap in this memory heap size: 0x08000. It didn't work.

　　Later I changed the Stack Size (MAUs) option, i.e. the global stack size, from 0x400 to 0x1000. Then the problem was solved. Later I realized that the dynamic stack is used to dynamically create tasks, not the stack I wanted. After reflection, I felt that it was a big mistake caused by my unfamiliarity with the BIOS system!

　　I personally think that when it comes to hardware, the problem is nothing more than one: power supply.

　　If the power supply is unstable, the chip will definitely not work properly. What problems will occur if it does not work properly?

　　(1) The chip does not work. Haha. This time I discovered that when the IO output is short-circuited, the chip will not work. The phenomenon is: the chip IO level is not 3.3v, but 1.768v

　　(2) The chip is constantly resetting. I will not discuss this issue, as the chip is constantly powered on and off.