A warning to anyone using interrupt levels on the DsPIC's

[Ttelmah]

Hi,

Have had some code for a while that runs an 'interpreter' as a low
priority interrupt (triggered when data is waiting in a buffer), while
running quite a few thing using the default interrupts, and one 'urgent'
thing using a higher priority interrupt.
It was all built back in the 5.09x compiler era, and worked fine.
However recently tried to rebuild with a newer compiler an found it went
wrong.
Testing it turned out that 5.098 was the last compiler where it worked
correctly.
Have tracked it down that the compiler no longer protects local variables
in the interrupts when NESTED=TRUE. The older compilers did.
On the older compiler, RAM was re-used between interrupts at the same
'level', but not between levels.

So if you are using nested interrupts, 'beware'. You will find that the
more recent compilers will re-use RAM between the different interrupt
handlers, and this can make things fail 'big time'.
I have reported it to CCS, so hopefully it'll soon be fixed, but for
anyone using nested interrupts, you need to ensure that all local variables
in the interrupts are either global or static.

A big 'caveat'....

[jeremiah]

That's fun!

I guess the workaround is to declare ISR variables static and if you need the initialized each call, manually do that in the ISR? Or just use globals.

[Ttelmah]

As I said, global or static.
Yes, initialise if you need to at the start of the ISR.

It is fun. Took me an age to find. I was originally thinking they had got
something wrong in the actual handling of the interrupt priorities. Went
through, and every register for this was right. Then found the code was
doing an odd access into an array. Local variable used for the index, which
was checked whenever it was changed. Then found that a level 4 interrupt
was using the same location for one of it's variables. Result was the level 1
interrupt was getting it's variable corrupted by the level 4 interrupt. Bit
more checking found that in 5.098 the variables were correctly respecting
each other, while after this they do not...

[hmmpic]

Suggestion?

Why not create in a new thread where we track down most of the errors, only error the moderator accept will be there.
It is almost impossible to find a compiler version that has no errors, for me version 5066 is perfect, it is years old, and don't support now days pic.

Over time I have reported some, the same have others. But only CCS know what is reported, that's a big problem i think.
When they release new version, there are only few lines with fix, but no line describing what there actually have done.

For my last error/bug, CCS send me a new dll, untested, because it have the same error. Then they post me a new one, but this time for a .pcd problem was on .pch.
Completely impossible to understand how they fix bug.

It will be a nice initiative with a thread where bugs that we know exist are written down.
When a new release is up, we start from there again. That way we will be able to help each other, and CCS closing the errors that occur all the time at regular intervals, and new errors.

And one more,
I have a small c file with some function, if the compiler can do that right, then the compiler have a change to work. I use MPLAB_892 and some simple printf function.
Such a file i think will be a big help for tracking errors.

The error you have was maybe not so easy to track down, but most errors are possible to simulate i think.

I know it is not simple because dif. pic have dif. hardware and database, this will be better than not having nothing.

Just my thoughts.

[Ttelmah]

It's fundamentally a 'nice idea', but the problem is it could become very
large unless it is pruned, and if it is pruned by age, then 'old' problems
could/would get lost.

A possibility would be to do something similar to the 'Best of' forum, with
'compiler issues'.?

[temtronic]

so Mr. T.....
got ANY hair left ????
bad that these 'minor problems' come up...
GREAT that you can figure them out !!!

[newguy]

A "known issues/new issues" portion of the forum would be helpful. I would suggest that the first post of a potential new issue would be the short standard example program we ask to see here when someone has an issue.

[hmmpic]

@Ttelmah, I think it will be a super idea. Then we all can go back and see what we have reported to CCS.

[Ttelmah]

OK. I'll talk to Darren at CCS about this, and I'll probably try to do it as
having a version number in the subject to keep things sensible.

[jeremiah]

[PCM programmer]

When the sticky Master thread goes up, can we get rid of the
Announcement for Best of ? By now everybody knows about it.

[Ttelmah]

Yes. I've actually suggested that we have a single sticky for the new
'issues' section, and include inside this a note that there is also a 'best of'
section.
Unfortunately don't know who is actually the master administrator for
this now. Darren has left CCS. Waiting to hear back.

[Ttelmah]

OK.
This has now been done, so 'any suggestions' please for threads to
link to this.

[hmmpic]

So nice, now we all can see what there is a bug, hope it will be a help for all there use the compiler:-)

[RoganHasnain]

Thank you. I'm beginning to understand how it works ;)