Dry goods sharing: Why is the DSP program running? How did you solve it?

What are the reasons for the DSP program running away? How did you solve it? Brainstorming in the name of academics is taking place in the e-family forum. Let's take a look at the dry goods you deserve.

Michael_xing:

Let me talk about my previous project experience.

There are two options for the general debugging code steps.

Solution 1: First debug the main program, and finally add a protection circuit such as a watchdog;

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

For me, in order to better write algorithm code, I plan to use it.

In the process of debugging my code, I encountered the following program running:

[Cause] Hardware watchdog circuit design error

[Design] In the design of my design, I designed the hardware watchdog circuit with Maxim chip MAX706AT. It seems to be a perfect circuit. When connecting the simulator for simple square wave output test, I found that the DSP has no task output. The program is already abnormal, because I used the program one to design the code, so I only know the exception and don't know the reason.

【Solutions】

1, countless download programs, and run the program, but the program is always running abnormally.

2. Fortunately, there are several IOs that directly drive the LEDs in my circuit design. At this time, I noticed that the brightness of the LED display is not normal. Then, I quickly test the IO voltage with a multimeter. The result is only about 1.6V. . At this time, I have already understood that the watchdog is abnormal.

3, troubleshooting the MAX706AT circuit in the circuit, there is no problem at all. When the MAX706AT's package and pinouts were found, the root cause of the problem was discovered. The chip is available in both SO and UMAX packages. It is strange to say that the names are identical, the package is different, and the pin definitions are different, causing the reset voltage of the watchdog chip to always be low.

Finally found the problem.

Michael_xing:

In the process of debugging my code, I encountered the following program running:

[Cause] The interrupt processing timeout caused the program to run away.

[Design] I designed the bipolar signal acquisition system based on TMS320F28335(4). Because of the high frequency, the interrupt acquisition method is adopted. That is to say, I use the PWM output square wave to trigger the acquisition module to start collecting. After latching, it will be interrupted

Tell dsp to read the data. Then the data read is done in the interrupt.

In the first version, the sampling trigger is performed with a period of = 20ms/256.

Very strange problem has occurred. In DEBUG mode, there is no problem, data can be collected, but in RELEASE mode, when the data is collected, the program runs away.

When you realize that the program is running away, you suspect that the interrupt routine is too long or the processing time is too long.

【Solutions】

If the guessing period is too short, then the period can be increased, the period = 20ms/128, and the failure still ends.

Reduce cycle = 20ms/64, okay.

It is advisable to chase after the poor, the cycle is reduced to = 20ms/32, okay

The first time it was solved.

[attached] When using dsp for algorithm processing, you must first evaluate the algorithm. Otherwise, when you realize your own program problem, it is too late, because after the parameter is modified, it may not meet the system requirements.

Cresta:

The reasons why I have encountered DSP programs running are:

1. Careless operation of the subfunction return address value.

2. The value overflows, reads and writes over the range of storage space, stack overflow, and so on.

The program is a program with a BIOS. When the program runs away, I set a breakpoint on 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. It was invisible, so it was in a stalemate. I don't know what to do.

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

In the beginning, I realized that the program caused by the stack overflow might run away, so I increased the dynamic stack on each memory, namely: create a heap in this memory heap size: 0x08000. The result does not work.

The Stack Size (MAUs) option, which was later modified, changed the global stack size from 0x400 to 0x1000. Then the problem was ruled out. Later I realized that the dynamic stack is used to dynamically create tasks, not the one I want. After reflection, it is still a big mistake caused by the unfamiliarity of the BIOS system!

Ice Age:

I have encountered the program of the single-chip computer running, there is static interference. Overclocking is too large. Causes instability.