AVR-Chat

ATMEGA8 simulation in:
AVR Studio	4, 8, 0, 310
Platform	AVR Simulator	Build	1, 0, 0, 12
Part		ATMEGA8	Build	65

Operating System
Major		5
Minor		1
PlatformID	2
Build		2600
Service Pack 1

Problem #1:

Everything's fine initting the machine, up to Idle.
I set a BP at Idle, and run it to there.
Then I put a BP in at Panic, and take off the one at Idle.
Notice that all the routines are commented out. 
So only ISR's could even be running.
After 6513uS (the loop takes 1uS) I'm at Panic, with SP at 045F
Apparently it loops in this code 6512 times just fine, then fails the same test.
Now, the question is, with SPL=5F, and SPH=04, WHY am I at Panic?

With the routines enabled, I run the machine just fine, till I hit Panic.

Idle:
	;rcall	Timed_Smack	;Resets watchdog, if it's time to do so.
	wdr
	;rcall	Start_Step	;If possible, make a step, speed based on fu
	;rcall	Printhead_Latch	;Latches printhead, and starts burning the A half
	;rcall	Send_Pixel_Line	;
	;rcall	Fake_Pixel_Lines; Simulates reception via SPI, except a line at a time.

	;Stack check
	in		TEMP,SPL
	cpi		TEMP,$5F
	brne	PANIC
	in		TEMP,SPH
	cpi		TEMP,$04
	breq	Idle

Panic:
	rjmp	Panic



Problem #2:

I am getting INT1 even though INT1 is disabled.
It does appear to respect GIE, but at more or less random intervals, I find myself in the INT1 ISR, with INT1 cleared in GICR.

INT0 does not seem to have this problem.

>
>Are you sure SP is at 045F when at Panic?
>Is the error happening always at 6513 loop count?

That's what it says there on the left in "Stack Pointer" 0X45F when I'm sitting at the PANIC breakpoint..

>Include an extra instruction in the Stack_Check just to force the simulation software to use different size of memory, etc, and see if the problem happens again at 6513 count.

I'll try this later, for now I've just rem'd out the panic check.
I have other fish to fry..

Still bugged by the INT1 though.. I hate it when a disabled int fires, even more so in SIM where there's no hardware to trigger it....

>
>Include an extra instruction in the Stack_Check just to force the simulation software to use different size of memory, etc, and see if the problem happens again at 6513 count.


Even more fun, I put an extra NOP in the main loop, with the main routines enabled.
What would you guess?

I start the clock at reset, and let it run till I hit panic.

Without the NOP, 55074 uS every time.
With the NOP, 34594uS every time.
Two nops, 38609, every time.

I'm not seeing a pattern here.

Since you know exactly when it trips, set up the simulator to break a couple
hundred cycles prior to the fault and single step your way to bliss.
Eventually you will see the error.

-----Original Message-----
From: David VanHorn [mailto:dvanhorn@cedar.net]

>
>Include an extra instruction in the Stack_Check just to force the
simulation software to use different size of memory, etc, and see if the
problem happens again at 6513 count.


Even more fun, I put an extra NOP in the main loop, with the main routines
enabled.
What would you guess?

I start the clock at reset, and let it run till I hit panic.

Without the NOP, 55074 uS every time.
With the NOP, 34594uS every time.
Two nops, 38609, every time.

I'm not seeing a pattern here.

At 01:31 PM 1/2/2004 -0800, Larry Barello wrote:

>Since you know exactly when it trips, set up the simulator to break a couple
>hundred cycles prior to the fault and single step your way to bliss.
>Eventually you will see the error.

How?

The SP is 045F when the test fails.
The test compares 045F to 045F, and tells me <>.
The same test passes thousands of times, before it fails.

Set up a counter, break on a memory location, do something so you can catch
the processor a few cycles prior to the failure, then step through until you
catch it.  This is very painful, but entirely possible.

Could an interrupt interfere and change the flags after the test, but before
the branch?  Your results and the shifting time it takes for the failure to
occur sounds like a classic race condition between an interrupt handler and
some foreground code.

Try wrapping your test of SP in a CLI/STI and see if the problem goes away.
Maybe re-inspect your interrupt handlers to make sure they properly
save/restore the SREG, etc.

Good luck!

-----Original Message-----
From: David VanHorn [mailto:dvanhorn@cedar.net]

At 01:31 PM 1/2/2004 -0800, Larry Barello wrote:

>Since you know exactly when it trips, set up the simulator to break a
couple
>hundred cycles prior to the fault and single step your way to bliss.
>Eventually you will see the error.

How?

The SP is 045F when the test fails.
The test compares 045F to 045F, and tells me <>.
The same test passes thousands of times, before it fails.

----- Original Message -----

From: "David VanHorn" <dvanhorn@cedar.net>
> Even more fun, I put an extra NOP in the main loop, with the main routines
enabled.
> What would you guess?
>
> I start the clock at reset, and let it run till I hit panic.
>
> Without the NOP, 55074 uS every time.
> With the NOP, 34594uS every time.
> Two nops, 38609, every time.
>
> I'm not seeing a pattern here.

Of course this is a software bug.   It should be related to some internal
counter, pointer or something like that.
It is going beyond from where expected.
Instead of two nops, include a dummy 4 bytes (2 words) instruction, like a
LDS   (LDS R2,$0000), the resulting count should be the same as the two
nops.  Try to include 3, 4, 5, 6 nops and make sure about the count error.
I guess you will have always error count between $8000 and $FFFF. For some
reason, some routine at the simulator is using an integer signed or
something like that, and it blew pointers as positive or negative carry
bits.  That would be quick for debug, if having the sim source code... that
is.
I guess the sim *must* have some setup that could be changed, buffers
expanded, or something like that, unfortunately not for us poor mortals.
Try to contact the manufacturer with this data you already gattered.

wagner

>
>Could an interrupt interfere and change the flags after the test, but before
>the branch?  

Ok, I see that, but I was discarding that, because I write all the ISR vectors first, with save and restore of SREG, then add code to them as needed.

I'll double check.

(runs off to check. returns swearing mightily..)

Ok, I was missing a restore of SREG. Guess where.

In the unfinished INT1 ISR, which is disabled, but firing anyway.
(I'm looking at bits 7,6 in GICR, which oddly seem backward somehow.)
They are both zero though, which should prevent INT0 or INT1 from happening.

Now, about INT1 firing off when it's disabled..
?

At 06:26 PM 1/2/2004 -0500, Wagner Lipnharski wrote:

>> I'm not seeing a pattern here.
>
>Of course this is a software bug. 

We got it, Larry reminded me about the ints, and as picky as I am about that stuff, I missed one.. Of course it was in the INT1 ISR that is supposed to be disabled, BECAUSE it's not finished, but I guess I deleted one too many lines there.. :-P

Of course, you checked to make sure your interrupt vector table is correct?
Dead interrupts or spurious interrupts have *always* been due to the wrong
interrupt vector table, in my experience.

I forgot to ask: in actual hardware or only in the simulator?  Have you
re-hosted on another processor (m128 or m16) so you can use your JTAG to
examine real hardware?  I find that re-hosting on a more suitable processor,
on a breadboard, using either the JTAG or ICE200 gets me almost all the way
there with very few lines of code change needed to enable the special
peripheral features for the target hardware.  Then it is just a few cycles
of churn & burn to get it right on the target chip.  Well, at least I have
been able to avoid getting a real ICE so far using that technique...

Cheers!

-----Original Message-----
From: David VanHorn [mailto:dvanhorn@cedar.net]
..
In the unfinished INT1 ISR, which is disabled, but firing anyway.
(I'm looking at bits 7,6 in GICR, which oddly seem backward somehow.)
They are both zero though, which should prevent INT0 or INT1 from happening.

Now, about INT1 firing off when it's disabled..
?

At 04:49 PM 1/2/2004 -0800, Larry Barello wrote:

>Of course, you checked to make sure your interrupt vector table is correct?
>Dead interrupts or spurious interrupts have *always* been due to the wrong
>interrupt vector table, in my experience.

I checked it twice, but as tired as I am at the moment, (packing for another 1900 mile road trip) I may have missed something..

;***********************************************************************
; INTERRUPT VECTOR TABLE.  YOU MAY NOT CHANGE THE ORDER OF THESE JUMPS!
;***********************************************************************
        jmp     INIT_Machine    ;Restart vector, points to the beginning of the code. 
        jmp     EXT_INT0        ;IRQ 0 
        jmp     EXT_INT1        ;IRQ 1 
        jmp     TIM2_COMP       ;Timer 2 Compare
        jmp     TIM2_OVF        ;Timer 2 Overflow
        jmp     TIM1_CAPT       ;Timer 1 capture 
        jmp     TIM1_COMPA      ;Timer 1 compare A
        jmp     TIM1_COMPB      ;Timer 1 compare B
        jmp     TIM1_OVF        ;Timer 1 overflow
        jmp     TIM0_OVF        ;Timer 0 overflow
        jmp     SPI_Handler     ;Serial transfer complete
        jmp     USART_RXC       ;USART RX complete
        jmp     USART_DRE       ;USART data register empty
        jmp     USART_TXC       ;USART TX complete
        jmp     ADC             ;Analog-Digital Converter
        jmp     EE_RDY          ;EEPROM Ready
        jmp     ANA_COMP        ;Analog comparator
        jmp     TWI             ;Two Wire Serial Interface
        jmp     SPM_RDY         ;SPM
;


>I forgot to ask: in actual hardware or only in the simulator?  

Just sim so far.

>Have you
>re-hosted on another processor (m128 or m16) so you can use your JTAG to
>examine real hardware?  I find that re-hosting on a more suitable processor,
>on a breadboard, using either the JTAG or ICE200 gets me almost all the way
>there with very few lines of code change needed to enable the special
>peripheral features for the target hardware.  Then it is just a few cycles
>of churn & burn to get it right on the target chip.  Well, at least I have
>been able to avoid getting a real ICE so far using that technique...

My experience with the ice-50, starting about two years ago, has been pretty rough.
Interestingly, before then, it was great. Small problems, like the middle two bits in the ADC output swapped. 76534210  stuff like that, but they were determinstic, and relatively easy to work around. 

These days, it's all flaky stuff that dosen't happen 100% of the time.
The ICE-200 worked nicely, but then that was with prev versions of S3, not S4.

You may be better off.

In this one, It's a M8, with no jtag, no ice (tiny package) and no spare pins.
The app is intricate, state driven, and very interactive with the external HW.

Well, given that the vector table is correct and you are on the simulator,
there must be some other problem.  I know you have run across a bunch of
simulator issues, still, I would consider s/w first.  perhaps some other
handler is fiddling with GICR or MCUCR and messing with the various bits.

Still, consider using a mega16 in an STK500 and bring out the appropriate
port bits to your mega8 header (cruft something up if you are using the MLF
package) then you can develop with the JTAG.  As far as I can tell the M16
is a straight upgrade from the m8 - at least for the projects I have worked
on.  Just make sure you get the right vector table :)  After you get things
working, then recompile for the m8 and it should work.  Keep the m16 lash-up
around for development work.

Cheers!

-----Original Message-----
From: David VanHorn

At 04:49 PM 1/2/2004 -0800, Larry Barello wrote:

>Of course, you checked to make sure your interrupt vector table is correct?
>Dead interrupts or spurious interrupts have *always* been due to the wrong
>interrupt vector table, in my experience.

I checked it twice, but as tired as I am at the moment, (packing for another
1900 mile road trip) I may have missed something..

;***********************************************************************
; INTERRUPT VECTOR TABLE.  YOU MAY NOT CHANGE THE ORDER OF THESE JUMPS!
;***********************************************************************
        jmp     INIT_Machine    ;Restart vector, points to the beginning of
the code.
...

At 05:51 PM 1/2/2004 -0800, Larry Barello wrote:

>Well, given that the vector table is correct and you are on the simulator,
>there must be some other problem.  I know you have run across a bunch of
>simulator issues, still, I would consider s/w first. 

Yeah.. It's kind of disheartening, when you're not sure where the problem is like this. It's easy to feel like nothing's going to work, and it's hard to have a lot of enthusiasm. 

> perhaps some other
>handler is fiddling with GICR or MCUCR and messing with the various bits.

I would say so, but when the ISR is firing, I'm BP'd there, and the ISR shows disabled.  I know the flag will be cleared by that point, but the enables should show their true state at that point.

>Still, consider using a mega16 in an STK500 and bring out the appropriate
>port bits to your mega8 header (cruft something up if you are using the MLF
>package) then you can develop with the JTAG.  As far as I can tell the M16
>is a straight upgrade from the m8 - at least for the projects I have worked
>on.  Just make sure you get the right vector table :)  After you get things
>working, then recompile for the m8 and it should work.  Keep the m16 lash-up
>around for development work.

Hmm.. That might be an option.

Of course these should all be RJMP!
Don't you hate it when that happens? :)

>;***********************************************************************
>; INTERRUPT VECTOR TABLE.  YOU MAY NOT CHANGE THE ORDER OF THESE JUMPS!
>;***********************************************************************
>        jmp     INIT_Machine    ;Restart vector, points to the beginning of the code. 
>        jmp     EXT_INT0        ;IRQ 0 
>        jmp     EXT_INT1        ;IRQ 1 
>        jmp     TIM2_COMP       ;Timer 2 Compare
>        jmp     TIM2_OVF        ;Timer 2 Overflow
>        jmp     TIM1_CAPT       ;Timer 1 capture 
>        jmp     TIM1_COMPA      ;Timer 1 compare A
>        jmp     TIM1_COMPB      ;Timer 1 compare B
>        jmp     TIM1_OVF        ;Timer 1 overflow
>        jmp     TIM0_OVF        ;Timer 0 overflow
>        jmp     SPI_Handler     ;Serial transfer complete
>        jmp     USART_RXC       ;USART RX complete
>        jmp     USART_DRE       ;USART data register empty
>        jmp     USART_TXC       ;USART TX complete
>        jmp     ADC             ;Analog-Digital Converter
>        jmp     EE_RDY          ;EEPROM Ready
>        jmp     ANA_COMP        ;Analog comparator
>        jmp     TWI             ;Two Wire Serial Interface
>        jmp     SPM_RDY         ;SPM

What am I missing here?

I'm setting up SPI as a master on a mega 8, but it never outputs any data, and SPIF never sets. (at least in the sim..)

SPSR is 0x01 ( I want double speed mode)
SPCR is 0x50 ( I want fast, master, enabled, no int)

DDRB is 0xEF
PORTB is 0x14
PINB is 0x0C, but I don't think it matters.

When I drop the data in SPDR (in sim) the data dissapears on the next cycle, but that's it. Nothing happens on the PORTB pins, and SPIF in SPSR never sets, so I hang waiting for transmit to complete.

At 09:52 PM 13/01/04 -0500, you wrote:
>
>Of course these should all be RJMP!
>Don't you hate it when that happens? :)

Of course you are RJMPing for joy I guess :-)

Regards

John Samperi

******************************************************
                        Ampertronics Pty. Ltd.
  11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
         Tel. (02) 9674-6495       Fax (02) 9674-8745
               Email: samperi@ampertronics.com.au
                 Website  http://ampertronics.com.au
* Electronic Design   * Technical Services   * Contract Assembly
******************************************************

At 09:59 PM 13/01/04 -0500, David VanHorn wrote:
>What am I missing here?
>

Don't know but here's what I do with the mega8 SPI in one project.

setup
.....
	ldi	r16,0b11101110		;PORTB B0=icp and B4=Miso as inputs
	out	DDRB,r16		;all other outputs
.....
;Set up SPI, LSB first, Master, clock idle high, phase=1, clock fck/64
	ldi	r17,(1<<SPE)|(1<<DORD)|(1<<MSTR)|(1<<CPOL)|(1<<CPHA)|(1<<SPR0)|(1<<SPR1)
	out	SPCR,r17
.....
;Sends spireg out serially. Clock is ACTIVE LOW, IDLING HIGH.
;(Mode 3) Bits are shifted out LSB FIRST.
spi_out:
; Start transmission of data (spireg)
	cbi	portb,SS	;Clear /SS pin
	out	SPDR,spireg
; Wait for transmission complete
Wait4spif:
	sbis	SPSR,SPIF
	rjmp	Wait4spif
	sbi	portb,SS	;Set /SS pin
	ret	
.....

It may not help but sometimes it's the things that are overlooked
that do the trick....as you well know.

Regards

John Samperi

******************************************************
                        Ampertronics Pty. Ltd.
  11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
         Tel. (02) 9674-6495       Fax (02) 9674-8745
               Email: samperi@ampertronics.com.au
                 Website  http://ampertronics.com.au
* Electronic Design   * Technical Services   * Contract Assembly
******************************************************

>
>setup
>.....
>        ldi     r16,0b11101110          ;PORTB B0=icp and B4=Miso as inputs
>        out     DDRB,r16                ;all other outputs

Ok, where it matters, we're same.

>;Set up SPI, LSB first, Master, clock idle high, phase=1, clock fck/64
>        ldi     r17,(1<<SPE)|(1<<DORD)|(1<<MSTR)|(1<<CPOL)|(1<<CPHA)|(1<<SPR0)|(1<<SPR1)
>        out     SPCR,r17

Where it matters, we are doing the same thing, SPI enabled, and Master are "1" on mine, the rest zero. 




>        cbi     portb,SS        ;Clear /SS pin

This one, I don't understand. 
It looks like you're setting up as a slave?


>        out     SPDR,spireg
>; Wait for transmission complete
>Wait4spif:
>        sbis    SPSR,SPIF
>        rjmp    Wait4spif
>        sbi     portb,SS        ;Set /SS pin
>        ret     


A very familiar looking piece of code.

At 02:43 AM 14/01/04 -0500, you wrote:
>>        cbi     portb,SS        ;Clear /SS pin
>
>This one, I don't understand. 
>It looks like you're setting up as a slave?

The master is lowering the SS (Slave Select or enable)
pin to let the slave know that data is coming. Of course
one could leave SS always low if there is only one
slave attached to the master in mode 3.

>;Set up SPI, LSB first, Master, clock idle high, phase=1, clock fck/64
>        ldi
r17,(1<<SPE)|(1<<DORD)|(1<<MSTR)|(1<<CPOL)|(1<<CPHA)|(1<<SPR0)|(1<<SPR1)
>        out     SPCR,r17

>Where it matters, we are doing the same thing, SPI enabled, and Master are
"1" on mine, the rest zero. 

So you are not using mode 3 as CPHA and CPOL are zero. (have deleted your
previous email)

From the Motorola HC11 data book:
****
When CPHA equals 0, the SS line must be negated and reasserted
between each successive serial byte. Also, if the slave writes data to the
SPI data register (SPDR) while SS is low, a write collision error results.

When CPHA equals 1, the SS line can remain low between successive
transfers.
*****
The Mega8 manual doesn't seem to explain this in the section
SS Pin Functionality, but I suspect that something similar may
be happening. It does however mention a few things about the
SS pin in master mode. May want to have a fresh look at it.

>>        sbi     portb,SS        ;Set /SS pin
>>        ret     

Disable slave at end of transmission.




Regards

John Samperi

******************************************************
                        Ampertronics Pty. Ltd.
  11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
         Tel. (02) 9674-6495       Fax (02) 9674-8745
               Email: samperi@ampertronics.com.au
                 Website  http://ampertronics.com.au
* Electronic Design   * Technical Services   * Contract Assembly
******************************************************

>
>So you are not using mode 3 as CPHA and CPOL are zero. (have deleted your
>previous email)


My slave isn't really SPI, just clocked serial.
I need to send 104 bytes as fast as possible, so the SPI works nicely.

The transmit routine (including counting the "1" bits) takes 2.00uS per byte on an 8 MHz M8. So, maybe I'll add a single NOP so that the byte is guaranteed to be gone before I get around again. Still, 104 nops adds up.

Still not having any luck getting it to talk. 

Since I eliminated the check for SPIF, I don't really NEED it to work in sim, but it would be very reassuring to see it happen.

At 05:28 PM 14/01/04 -0500, you wrote:
>>So you are not using mode 3 as CPHA and CPOL are zero. (have deleted your
>>previous email)
>
>
>My slave isn't really SPI, just clocked serial.
>I need to send 104 bytes as fast as possible, so the SPI works nicely.

Well in that case there are 2 things you can try. 

Use the code snippets I send earlier, even though it's not 
what you want, you will be able to see something happening
IF the hardware is not faulty. This code is used on a project
I'm working on currently where the M8 is talking to a GSM
modem and data is sent to a 68HC11 board via the SPI.


Change to mode 3 temporarily (CPHA and CPOL are one)
and use the low speed SPI mode. If it works then you can
try changing things and see where it fails.

Also make sure that the SS pin is set as an output so it doesn't
influence the SPI.

Don't know if I can do anymore as I know that you are quite
experienced, but sometimes just  talking about a problem will
show the answer. I talk to my budgies regularly and they are
quite IT savvy :-))

Regards

John Samperi

******************************************************
                        Ampertronics Pty. Ltd.
  11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
         Tel. (02) 9674-6495       Fax (02) 9674-8745
               Email: samperi@ampertronics.com.au
                 Website  http://ampertronics.com.au
* Electronic Design   * Technical Services   * Contract Assembly
******************************************************

>
>Use the code snippets I send earlier, even though it's not 
>what you want, you will be able to see something happening
>IF the hardware is not faulty. This code is used on a project
>I'm working on currently where the M8 is talking to a GSM
>modem and data is sent to a 68HC11 board via the SPI.

I'm building hardware now, Hopefully it's just a sim problem.
The system is madly spinning through blowing pixel lines into the ether.

It's kind of cute. 
:)


>Don't know if I can do anymore as I know that you are quite
>experienced, but sometimes just  talking about a problem will
>show the answer. I talk to my budgies regularly and they are
>quite IT savvy :-))

I talk to my cat, but I think he's plotting against me.

At 09:33 PM 14/01/04 -0500, you wrote:
>
It's quite strange that you are building things
yesterday evening.....This could come in handy
when someone needs something yesterday here
in Australia.....

Regards

John Samperi

******************************************************
                        Ampertronics Pty. Ltd.
  11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
         Tel. (02) 9674-6495       Fax (02) 9674-8745
               Email: samperi@ampertronics.com.au
                 Website  http://ampertronics.com.au
* Electronic Design   * Technical Services   * Contract Assembly
******************************************************