I am curious about a strange effect i observed in firmware for a prototype. Here's the quick version of my story:
I will use an 8x5 LED matrix in row x collumn configuration to demonstrate the basis of the operation of POV clocks: the changes of each pixel are too fast for our eyes.
PortB connects to 8 leds of each collumn.Port A selects which collumn will be on.
so, on to the problem:
I set up all of portb as output, all of porta as output, timer1 to active, CCP register to trigger interrupt accurately at ((1/60hz) * 5) = 3333 us = 3333 instruction cycles on timer1 without prescaler.
every time the interrupt triggers, an output routine will emit some value(current line) stored in ram through the index register and then increment the FSR(next line). after incrementing and outputting 5 times, it goes back to the first value . After doing this cycle 30 times(0.5 second), it changes to 5 other values and goes on.
Now, simulating on MPLAB the value of portB and the value fetched on RAM (somewhere between 0x40 and 0x4F) do not match!
So, under advice of another user of the forum,i Disabled the CCP module and Timer1 and used Timer2's overflow interrupt to count time instead.
With timer2 as a timebase instead of timer1 and CCP, the Values Of portB and the lines fetched by the index register started to match!
Something is terribly wrong in the implementation of timer1 and/or CCP1. What might i have missed?could it be a simulation issue?
Check my source code below and see what could have caused the discrepancy of portB.
The zip contains the source code using timer1; The asm contains the updated source using timer2.

 

So here you are, almost a full day since you posted your issue and not even a peep from anyone to help you. I would imagine asking people to compare 600 lines of assembly code to find the needle in the haystack could be the issue.

When tracking down a weird oddball problem the best thing to do is to make the smallest piece of code that duplicated the issue. That way you cut out interactions that may or may not cause the problem. More importantly, if you post the small code someone else is far more likely to first read it and next find the problem.

And welcome to the forums!

 

So here you are, almost a full day since you posted your issue and not even a peep from anyone to help you. I would imagine asking people to compare 600 lines of assembly code to find the needle in the haystack could be the issue.

We covered it pretty thoroughly in the POV clock thread here. I actually loaded the code, found the write to PORTB and verified the TS's problem in MPSIM and X then, and took another look this AM. RB3 seems to be assigned to CCP, it does not follow MOVWF PORTB. According to the databook and MidRange Reference Manual, running TMR1/CCP in modes 0Ah or 0Bh (as TS's code does), the port pin should be I/O (not CCPout). It doesn't seem to work that way - at least in the sim. I turned off interrupts and stripped the code to just fetch values and write to the port. Fails with CCP mode 0Bh, works with CCP off. Problem confirmed. My advice then and now is to open a support ticket with Microchip and send them the code if they need it - there is a bug in the docs, the sim or how we are understanding the books. It would not be the first time - for any of that for me.

Still, it's a good thing that the TS cares enough to dig down to understand why things are not working.

I've used TMR1/CCP to do a period timer many times without problems but don't know if I did any specifically on the '628 core or if I ran across MPSIM problems - I'm kind of an on-the-hardware guy.


Good luck.

 

We covered it pretty thoroughly in the POV clock thread here. I actually loaded the code, found the write to PORTB and verified the TS's problem in MPSIM and X then, and took another look this AM. RB3 seems to be assigned to CCP, it does not follow MOVWF PORTB. According to the databook and MidRange Reference Manual, running TMR1/CCP in modes 0Ah or 0Bh (as TS's code does), the port pin should be I/O (not CCPout). It doesn't seem to work that way - at least in the sim. I turned off interrupts and stripped the code to just fetch values and write to the port. Fails with CCP mode 0Bh, works with CCP off. Problem confirmed. My advice then and now is to open a support ticket with Microchip and send them the code if they need it - there is a bug in the docs, the sim or how we are understanding the books. It would not be the first time - for any of that for me.

Still, it's a good thing that the TS cares enough to dig down to understand why things are not working.

I've used TMR1/CCP to do a period timer many times without problems but don't know if I did any specifically on the '628 core or if I ran across MPSIM problems - I'm kind of an on-the-hardware guy.


Good luck.

By the way, i already made a webticket at microchip. Still pending.
On the next problem-solving posts i shall add the source along with a stripped-down code snippet showing the part affected by the issue.

 

Perfect!
Let us know what they say.

On the next problem-solving posts i shall add the source along with a stripped-down code snippet showing the part affected by the issue.

That's a good approach. Frequently, the problem will resolve as you strip out other things, leaving you a clue as to what is affecting what.
Well done.