Is this a bug or Me? Fast PWM simulation with AT90CAN32

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please refer to post below for help please!
(previously I was asking why the simulator wasnt working properly. Apparently that just the way it is. But I still have a major problem)

Just a noob in this crazy world trying to get some electrons to obey me.

Last Edited: Wed. May 27, 2009 - 02:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Is there something I am missing or is this a bug?

I'm not sure you can call it a bug when the user manual for the simulator says it probably won't work:
Quote:
Timer/Counters
16-bit Timer/Counters on all devices have several problems with PWM, prescaler and output compare. Output compare registers are not buffered properly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I dont think its a problem with buffering. Just nothing works. The only interrupt I can get to work is the overflow in normal mode. I cant even get a Compare match interrupt to be called in normal mode.
Something is seriously wrong.

Just a noob in this crazy world trying to get some electrons to obey me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I dont think its a problem with buffering.

Maybe not, but what Cliff quotes says that there are problems with more than just output buffering. The general consensus here seems to be: Dont trust the simulator when it comes to timers.

If you need to debug timer functionality at that level, then an On-Chip-Debugger is recommended (eg AVR JTAGICE MkII, or maybe the AVR Dragon depending on your target AVR model). If you need to know what actually happens on the chip, then debug on the chip. AVR Simulator simply does not have that quality.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your suggestion. I think I must buy a JTAG interface then. I have always relied on the simulator in the past and it has served me well, until now.

Just a noob in this crazy world trying to get some electrons to obey me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

edit: see below

Just a noob in this crazy world trying to get some electrons to obey me.

Last Edited: Wed. May 27, 2009 - 01:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So now I am no longer using the simulator and trying to debug it with a scope and I get the strangest thing happening. I am on the verge of going crazy.
I am trying to use TCNT1 with OCR1C to call an interrupt routine.

But no matter what value I load into OCR1C, the output frequency is 16.67Hz. This is probably because the value isnt being written to OCR1C, so the interrupt is only occuting every time the counter = 0 (every 65536 counts).

The programme is so simple theres nothing left to change!!! I dont know what else to do other than cry. I cant explain how appreciative I will be of some help on this.
I changed all my STS's to OUT's, then changed them back on compile errors. I have manually checked the address in the include file vs the datasheet. I am totally stumped.

.include "can32def.inc"
.def temp = r16
.def temp2 = r17

.org 0
rjmp Reset
.org OC1Caddr
rjmp interrupt_OC1C

;___________________________________________________________
interrupt_OC1C:
in temp, PinB
COM temp
out PortB, temp
reti

;___________________________________________________________
RESET:
/*Set the Stack Pointer*/

clr temp
ldi temp, high(RamEnd)
out SPH, temp
ldi temp, low(RamEnd)
out SPL, temp

ser temp
out DdrB, Temp

/*Set Output Compare Match C*/
ldi temp2, high(0x0384)
ldi temp, low(0x0384)
sts OCR1CH, temp2
sts OCR1CL, temp

/*Enable Output Compare Match Interrupt C*/
ldi temp, (1<<OCIE1C)
sts TIMSK1, temp

/*Start the clock at 1/8th Prescale*/

ldi temp, (0<<CS12)|(1<<CS11)|(0<<CS10);
sts TCCR1B, temp
sei

LOOP:
rjmp LOOP

Just a noob in this crazy world trying to get some electrons to obey me.

Last Edited: Wed. May 27, 2009 - 02:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
interrupt_OC1C:
    in temp, PinB
    COM temp
    out PortB, temp
    reti

I fully understand that you do not enable interrupts until the third from last line.
But you should always PUSH and POP any registers that you use in an ISR.

It also helps if you indent your code to make it readable.

Should you not initialise TCCR1A ?
Your comments that precede initialising TCCR1B do not seem right.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

interrupt_OC1C:
    in temp, PinB
    COM temp
    out PortB, temp
    reti

I fully understand that you do not enable interrupts until the third from last line.
But you should always PUSH and POP any registers that you use in an ISR.

It also helps if you indent your code to make it readable.

Should you not initialise TCCR1A ?
Your comments that precede initialising TCCR1B do not seem right.

David.


Hi thanks for your time.
Sorry about the wrong comment (edited it now). I was trying other things, and kept cutting down my code until I could get one that part working, then start building up again. But that one part working isnt working. Dont know what to do now, and boss just came and told me how imperitive it is again. :(

Since I am just running it in normal mode (couldnt get any other mode to work), there is nothing in TCCR1A I need to initialise.

Just a noob in this crazy world trying to get some electrons to obey me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Could the problem be that I am using AVR Simulator 1 white the include file is in AVR
Tools\AVRAssembler2\Appnotes ?

Just a noob in this crazy world trying to get some electrons to obey me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nope At90CAN32 is one of the old devices and only supported by the inaccurate sim V1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are there any settings I could try, even when I scope it is still not working?

Just a noob in this crazy world trying to get some electrons to obey me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can anyone tell me if they think my code is right? Should I be looking into hardware?

Just a noob in this crazy world trying to get some electrons to obey me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can I suggest 3 letters to you?...

C T C

The fact is that as you have things set you have a timer that will just repeatedly count 0..65535 (in "normal" mode) and each time it passes the point where the count is 0x384 it will trigger the compare interrupt where you complement PORTB

So the output frequency will be at the rate it takes the timer to count to 65535 and all the OCR value will do is move the point of the interrupt within that frequency.

Now one thing you could do if change your compare interrupt so that it not only toggles the port but also sets TCNT back to 0 and this would kind of have the affect you are after in that varying OCR will vary the output frequency. But it won't be exact as the clearing of TCNT will occur a handful of machine cycles AFTER the compare event.

In CTC mode the timer AUTOMATICALLY clears TCNT back to 0 at the moment the compare interrupt occurs so is very accurate.

So, like I say...

C T C

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried Simulator#1 with your code. You get no IRQs. But it will quite happily simulate a COMPB and vector to that ISR.

I have never used an COMPC IRQ. Probably because not all AVRs have them.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Can I suggest 3 letters to you?...

C T C

The fact is that as you have things set you have a timer that will just repeatedly count 0..65535 (in "normal" mode) and each time it passes the point where the count is 0x384 it will trigger the compare interrupt where you complement PORTB

So the output frequency will be at the rate it takes the timer to count to 65535 and all the OCR value will do is move the point of the interrupt within that frequency.

Now one thing you could do if change your compare interrupt so that it not only toggles the port but also sets TCNT back to 0 and this would kind of have the affect you are after in that varying OCR will vary the output frequency. But it won't be exact as the clearing of TCNT will occur a handful of machine cycles AFTER the compare event.

In CTC mode the timer AUTOMATICALLY clears TCNT back to 0 at the moment the compare interrupt occurs so is very accurate.

So, like I say...

C T C

Thanks for your input. I first tried fast PWM, didnt work, then I tried CTC, didnt work, so then I tried normal mode. I am not looking for the best solution right now. I am just trying to get the OCR1C interrupt to be serviced. Its so strange, its as if the chip doesnt want to write any values to any of the OCRn registers.

So far the only interrupt that will be called/work for me is the OV one.

Just a noob in this crazy world trying to get some electrons to obey me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I tried Simulator#1 with your code.

The Simulator 1 is notorious for not handling CTC and PWM modes correctly. Generally, when doing something else than running the counter in the basic mode (in your case, counting to the maximum TOP it can, eg 64K) as soon as I see something odd I would have as the primary hypothesis that the simulator is flawed in the current mode.

Try running Cliffs advice on the real chip, and put your 'scope on it. Chances are that you are very close now, but that you're having a struggle with the simulator (in vain).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I tried Simulator#1 with your code. You get no IRQs. But it will quite happily simulate a COMPB and vector to that ISR.

I have never used an COMPC IRQ. Probably because not all AVRs have them.

David.

You are right, it will simulate a OCR1A and OCR1B fine, but not C.

Just a noob in this crazy world trying to get some electrons to obey me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Quote:

I tried Simulator#1 with your code.

The Simulator 1 is notorious for not handling CTC and PWM modes correctly. Generally, when doing something else than running the counter in the basic mode (in your case, counting to the maximum TOP it can, eg 64K) as soon as I see something odd I would have as the primary hypothesis that the simulator is flawed in the current mode.

Try running Cliffs advice on the real chip, and put your 'scope on it. Chances are that you are very close now, but that you're having a struggle with the simulator (in vain).

YESSSS!!!!!! Its working now! :)
I forgot to reset the counter to zero when the interrupt was called. :roll:
Thanks for all your advice, I would of never of done it without you guys. I was thinking on a completely different line, and getting hung up on one point, until your posts broaden my mind!
I would hug you guys if could!! :D
Thanks again
Now back to work *crack whip*

Just a noob in this crazy world trying to get some electrons to obey me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I forgot to reset the counter to zero when the interrupt was called.

So you ignored my advice about CTC? As I say you can either manually set TCNT to 0 in the ISR (with "jitter") or you use CTC and it's done automatically and accurately for you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

I forgot to reset the counter to zero when the interrupt was called.

So you ignored my advice about CTC? As I say you can either manually set TCNT to 0 in the ISR (with "jitter") or you use CTC and it's done automatically and accurately for you.

I tried to use CTC before you posted, and it mystically didnt work, thanks to my confused state of mind.

My orginal code used Fast PWM. I kept simplifiying it until I could get something to work. Now with your guys insight I got something working, I built the code back up to the Fast PWM Mode (Toggles the OCR1A and OCR1B pins automatically, and I use OCR1C interrupt to load new match values into OCR1A & B. to vary the PWM cycles.

Thanks again.

Just a noob in this crazy world trying to get some electrons to obey me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I didnt want to start a new thread cause I have done too much of that already, but I find it strange that

Quote:
.equ ADR_Sol1 = SRAM_START+02
.equ ADR_Sol2 = SRAM_START+04
.equ ADR_Sol3 = SRAM_START+06
.equ ADR_Sol4 = SRAM_START+8

Compiles succesfully,
whereas
Quote:
.equ ADR_Sol1 = SRAM_START+02
.equ ADR_Sol2 = SRAM_START+04
.equ ADR_Sol3 = SRAM_START+06
.equ ADR_Sol4 = SRAM_START+08

does not :? :? :?

Just a noob in this crazy world trying to get some electrons to obey me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is because the 08 is interpreted as an octal number. And is obviously an illegal octal at that.

0      //zero        
####   //decimal     valid 0..9
0###   //octal       valid 0..7
0x###  //hexadecimal valid 0..9 a-f A-F
0b###  //binary      valid 0..1

Yes, it annoys me too.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
That is because the 08 is interpreted as an octal number. And is obviously an illegal octal at that.

0      //zero        
####   //decimal     valid 0..9
0###   //octal       valid 0..7
0x###  //hexadecimal valid 0..9 a-f A-F
0b###  //binary      valid 0..1

Yes, it annoys me too.

David.

Oh wow, thanks for the revalation! Good to know.
I thought it was a bug.

Just a noob in this crazy world trying to get some electrons to obey me.