Strange register interaction on 18F2431

[richard]

PTCON1.7 = 1 seem to point to an issue with your pwm timebase interrupt , what does that look like any asm code in it, maybe incorrect banksel
if you disable interrupts does the problem persist ?
can you make a simplified cut down version that still demonstrates the problem

[Demon]

...
can you make a simplified cut down version that still demonustrates the problem

My usual suggestion, plus, check out the datasheet at the registers just before the messed up one. Anything stand out? Do you use those? Maybe want to display those as well to see if your register is just not the tip that is visible of a larger problem.

Without having a chip to try your code, what about config fuses? Some features multiplex, maybe you've got another feature doing stuff you're not expecting.

Funky stuff, wish I could help.

Robert

[HenrikOlsson]

Hi guys,
Thank you for your replies!

Richard,
Untill now the interrupts have always been enabled though obviously the PWM timebase interrupt isn't generated if the timebase isn't running. What I've done since yesterday is to add code to main routine which once every 1600ms prints the content of DFLTCON, this doesn't work if the PWM timebase isn't on because the 1600ms "tick" is based on that. When the program starts the DFLTCON is set to what is stored in EEPROM (as expected) then the ResetServo routine is called, where DFLTCON somehow gets changed, and then is stays at that value for as long as I leave it on. I've left it for 20min, and at an interrupt rate of 1500Hz that's 1.8 million interrupts, the content of DFLTCON stayed intact.

After those 20 minutes I manually called the ResetServo via the serial console, as Before the content of DFTLCON changed while that routine executed and then it reamains at that new value - whatever it is.

None of the other 20 values I can change via the serial console is misbehaving as far as I've been able to tell - it's only the setting for DFLTCON and again, it's not my variable that's changing it's the actual SFR.

What I've also tried is adding something like the following to main loop:

If DFLTCON <> EncFilter THEN    'DFTLCON is the SFR, EncFilter is my variable.
    Toggle PortC.2
    DFLTCON = EncFilter               ' Force DFLTCON back to correct value
ENDIF

I've yet to see PortC.2 toggle anytime EXCEPT when ResetServo is called and DFLTCON is NOT written to (by me) from that routine at all - yet it changes.

At this point I'm tempted to just add DFLTCON = EncFilter at the end of the ResetServo subroutine and then just forget about it but there's something strange going on and I don't like it.

The actual interrupt code is a mix between PBP and ASM, it's all "treated" as pure ASM interrupts and I've manually examined the generated .lst file to figure out which system variables needs saving and restoring. The interrupt code itself has NOT been changed at all. With that said agree that it has to be something.....

/Henrik.

[richard]

the only time I have experienced anything similar was trying to use a LAT pin in the I2COUT command . i2c worked ok but other code got wrecked seemingly at random .
dt sorted for me , reason is a lot of commands like i2c etc set the tris reg by adding a fixed offset to the port address works fine for PORTX fails miserably for LATX . its not a trap I will fall into again .
I wonder if the problem could be tracked with source level debugger , it would probable be a tedious exercise though .

[pedja089]

As I mention in PM to HenrikOlsson,
MPLAB X have breakpoint on variable(ram location) read or write. That would pinpoint instruction that overwrite DFLTCON.
Also that could be up to MPASM version used. I had problem with DT_HID, but Darrel find out that ASM generated bad ram address for USB registers.
And there is allways option that there is bug in PBP.

[richard]

just a thought about using pbp code in isr declared as "asm" in dt_ints , I have stopped doing it if I'm dealing with word sized (addition subtraction comparisons ) I found it sets or resets pbp internal regs and causes no end of random glitches , byte sized things seem ok but never mult/div of course . caveat emptor

[HenrikOlsson]

Hi guys,
First of all, thank you again for your time and your replies, I do appreciate them!

I rolled my codebase back to where I started the other day. Verified that it didn't misbehave (which it didn't) and started to reimplement the changes made.
I made small changes and verified between each one that it still worked as expected (and with worked I mean the issue with the DFLTCON register).

I'm now pretty much at the state I was in before and it's still working as expected. Obviously there is SOMETHING wrong with my "other" code but I have been unable to figure out what it is that makes it behave the way it does.

The biggest change implemented was to remove Darrels EE_Vars routine in favour for using "standard" DATA, READ, WRITE - this to save program space. I can not find any difference between the current implementation and what I used up until this morning. Yet, this works and the other doesn't.

pedja089,
Yes, thank you for your PM. Over the years I've tried to get MPLAB X going for the sole purpose of being able to do source level debug at the hardware level. Needless to say I haven't been able to get it going. This would have been THE PERFECT time to use it and I would still VERY MUCH like to be able to figure out what the heck is going on.

Richard,
I'm not using DT-Ints at all but of course you're correct. PBP uses it's system variables so if/when you use PBP in an ISR those system variables needs to be saved/restored which is what DT-INTS does (when declared as a PBP type interrupt).
The drawback is that it saves and restores ALL the system variables even though the code in the ISR might only use one or two. What I've done is to look at the generated assembly listing for the ISR and then added code to save and restore only those system variables that gets used by the PBP code actually IN the ISR. I'm fully aware of the "danger" in this, and any change to the ISR code will force me to again look at the generated .lst file to see if any more system variables needs to be handled. With that said, the interrupt code wasn't touched at all when the issue with DFLTCON being overwritten occured so I can't see how it may have anything to do with it.

I've got three interrupt sources and the code for each is very short and simple.
* My PCPWM timebase interrupt service routine does not use any PBP system variables.
* My QEI rollover interrupt service rouitne does not use any PBP system variables.
* My USART receive interrupt serive routine uses T1, FSR0H and FSR0L so I'm saving and restoring those (one WORD and two BYTE variables).

It's not something I recommend doing.

I have a feeling the problem is still hiding in there somewhere just waiting to re-surface when I least expect it. I'll make sure to keep you updated!

/Henrik.

[pedja089]

I hope that you are solve problem...
If problem still persist, I could try to set up MPLAB X for you using TeamViewer.
Good Luck.