Thread: RTOS, LUTs and interrupts

Using a Freescale DSP chip, I have 3 timers that grab a value out of an their own respective LUT to generate a sine wave (often with many harmonics) and then send the information out to a DAC. The system is controlled over a serial interface by a GUI (which I am am also designing).

I send the information defining the amplitude of each of the harmonics and then generate the sine LUT's for the outputs.

I ran into a problem where every so often when I send new data the sine LUT has some corrupted data in it. After poking around, I noticed that if I turned off the timers when I was updating the sine LUT, it worked flawlessly (other than seeing the sine wave stop updating sometimes while the timers are off).

So clearly the problem is that I am accessing the data at the same time I am updating this. I don't know why this is. I figured that with a processor, with code running serially, this wouldn't happen.

I was just wondering what the proper way to do this is. I figured that I could have two LUTs, update one while reading from the other and then just switching a pointer at the end. But I am slightly concerned about memory size and I feel like this complicates my communications interface.

Anyone have any suggestions?

Thanks for the response, but it is nothing like that. If that were the case, I would think that the problem could arise at anytime, but it only happens when I try to update the LUT.

I think I will just go with swapping the arrays, that seems to work and hopefully I won't need any extra memory. . . if I do I can deal with the problem when I get there. Unless, of course, someone else comes up with a solution.

I will be checking back. I may even be at the point where I can reasonably help OTHER people with programming problems.

Salem,

Your suggestion definitely makes sense and it is something I have explored.

However, all I do is send the information about the wave and then generate it on chip; I send the amplitude and phase of the fundamental frequency and then the amplitude of 4 harmonics in the wave (there is other information, but it does not directly affect the problem). That being said, I have never seen the information get in incorrectly.

What happens is that I use that data passed in to generate the harmonic LUT. It is during the generation of that LUT that the data gets messed up. . .and it is just a couple of values. The bulk of the 360 samples come out fine, but maybe 4-5 will get screwed up.

But, again, if I stop the timer while updating the LUTs, it generates the waves perfectly. It is so bizarre.

These timers only read from the LUTs? No writing?

How many places, or in what parts do you write to the LUTs?

gg

It is only written to when the serial interfaces calls the function to generate them. Intentionally, of course, I guess I could have some kind of pointer problem writing randomly, but I don't think that is it.

If I let the program run freely, which enters the ISRs all the time, the LUT never changes. The only time it gets messed up is when I write to them while the ISRs are running.

In an attempt to solve the problem I assigned two LUTs to each wave. I read from one and if I require an update, I update the other and then just swap the pointers at the end. This exhibits the same exact problem and can be solved in the same way by disabling the interrupts while I am updating the array.

So even if I were accidentally writing to the array I was just trying to read, it shouldn't affect the array that it was not reading from.

Bizarre stuff.

The key clue is that masking interrupts masks the issue.
If there's only one part of the code that ever writes, then it may be a reentrancy issue - which would explain why masking interrupts prevents it from occurring. Or perhaps the writing algorithm relies on other external data that may change on you if interrupts are running.

What platform, environment does this code run in?

gg

Sweeet.

I found the problem. Not exactly sure why it works or what the hell it is doing, but I am pretty sure the problem has been solved. Maybe you guys could explain it to me a little better.

I didn't write the original code. . . my background story is that I am a hardware designer with a lot of FPGA background. By chance I ended up becoming the embedded C programmer and .Net developer for out company. I have been working with another developer's code so it gave me a starting point.

When you two started talking about reentrancy and saving the SM it reminded me that one of the #pragma interrupt "calls" (I am not exactly sure what that line does) had a "saveall" at the end. I remember this sticking out to me because I had no idea what it meant. . .well, I guess I just don't understand pragma's all that much.

So, I just stuck a saveall on the end of all of those "calls" that were causing the problem. Boom. Problem solved. Thanks.

I understand that the "saveall" tells it to save more registers than it was saving before, but I guess I don't fully understand the pragma.

Thanks for the help.

Charlie