ATtiny10 and STK600 Issues

Go To Last Post
92 posts / 0 new

Pages

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

As for debugging, when reality doesn't match simulator...
DebugWire is available now on most all new and most "current" AVRs, so if you took the suggestion made earlier, use a Tiny13 (next weediest chip) to Emulate your Tiny10. Then single step the illogical to understand what state your chip has got in to.

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

The TPI interface can actually read IO states via the PINB register, but I'm not sure how many registers get knobbled when TPI is invoked.

So if you wrote some states out to RAM, I think you could debug your Tiny10 in a post-mortem kind of way.

I could not seem to access the R16..R31 though.

BTW I'm not sure what STK600 + AVR Studio lets you do compared to what is possible..

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

bb56 wrote:
The Tiny10 Adapter card also came from my local distributor when I got the STK600.

What distibitor is that? I couldn't find the STK600-TINY10 adapter.
Atmel doesn't even list it at their starter kit website along with the other STK600 adapters yet: http://atmel.com/dyn/products/to...

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

Note that bb56 is US based, and despite our Geographic nearness to Norway, Europe (Denmark and UK) might not be their "initial" market.

My sample Tiny10 units came from NuHorizons but they shipped them over from Atmel USA.

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

Unless local distributors or their Applications Staff have units but have not yet got round to letting people know.

Its probably worth a phone call or two to find out.

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

bwarren wrote:
As for debugging, when reality doesn't match simulator...
DebugWire is available now on most all new and most "current" AVRs, so if you took the suggestion made earlier, use a Tiny13 (next weediest chip) to Emulate your Tiny10. Then single step the illogical to understand what state your chip has got in to.

Thanks Brett.

If I get some spare time, I will compare the 10 to the 13. For now, I chose to implant a little snippet of code to blink another LED while I'm not using the pin for it's intended purpose. I put the code in strategic places to see if I ever execute it.
I also use LED bahaviorial analysis to logically attack my code - when the main LED on the PWM does not respond properly or erratically, I suspect my use of opcodes like 8-bit add and subtract on numbers larger than 127. Then there are the bsr vs. bsrc code assembler differences (this one found the hard way).
Exxample:

.EQU UpDown = 4
sbrs	State,UpDown ;check a bit
.
.
sbr	State,(1<<UpDown) ;set a bit

As a newbie to the assembler - this had me going for a while. The OpCodes are very similar in terms of dealing with a Bit, and they both contain 'sbr', but they deal with the argument quite differently. The 8-Bit AVR Instruction manual helps.

Also, the Tiny10 preliminary data manual says factory is 10% but the user can achieve 1% clock accuracy by setting OSCCAL bits, but I haven't a clue how one arrives at the correct setting. My clock tolerance is not a problem (yet anyway).

Bob

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

SBR is my pet hate of the instruction set (which is generally very good)
If you are setting a "BIT" why do we need to say 1<<bit !!

Acutally, opcode for it is mapped to
ori State,(1<<UpDown)
So I just use that to avoid forgetting the <<.

The other non-compiling anagram to watch for is
sbci R16,1 (subtract "1 plus carry" from R16)
sbic R16,1 (skip if bit 1 (0x2) in port "R16?!" is set)

As I've only implemented 32 instructions on my own "TPI Programmer", seeing the LEDs at all was enough!
Cunning debug tip (if not doing so already) -> send a pattern on your debug led to identify which runtime or error path you hit. (a low quality UART)

;=== path 1 ===
sbi PORTB,debug_led_bit
sbi PORTB,debug_led_bit
sbi PORTB,debug_led_bit
cbi PORTB,debug_led_bit

;=== path 2 ===
sbi PORTB,debug_led_bit
cbi PORTB,debug_led_bit
cbi PORTB,debug_led_bit
cbi PORTB,debug_led_bit

Have Fun!
brett

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

Quote:

SBR is my pet hate ...
If you are setting a "BIT" ...

You are actually setting >>bits<<, hence the mask of which >>bits<< to set. Not to be confused with SBI to set >>a single bit<< in a reachable I/O register. :twisted:

Instruction set design is always a compromise. My "pet hate" is the waste of valuable low I/O space in smaller AVRs such as the Mega48 with the new-style Mega expanded I/O area.

Re the Tiny10, they could have thrown us a bone and provided a GPIOR or two down low in I/O space for flags and such.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:

The other non-compiling anagram to watch for is
sbci R16,1 (subtract "1 plus carry" from R16)
sbic R16,1 (skip if bit 1 (0x2) in port "R16?!" is set)

Gee, my little test programs I tried on the desk didn't trip me up--'course I used CodeVision C. ;)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

bb56 wrote:
Also, the Tiny10 preliminary data manual says factory is 10% but the user can achieve 1% clock accuracy by setting OSCCAL bits, but I haven't a clue how one arrives at the correct setting.

Read these application notes for AVR internal RC oscillator calibration:
http://atmel.com/dyn/products/ap...
AVR053: Calibration of the internal RC oscillator
AVR054: Run-time calibration of the internal RC oscillator

There's also source code for these application notes.

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

Quote:
but the LED is on for ~4 seconds, off for ~3.5 seconds.
As you may have observed the timing loop is self adjusting according to the clock frequency, so if it has the correct info and the correct setup you should always get very close to 1ms timing. ie don't have to redo your delay timing when the clock is different.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

bwarren,

any chance we can get more information on how you implemented the programming algorithm on the tiny2313?

-Bob

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

js wrote:
Quote:
but the LED is on for ~4 seconds, off for ~3.5 seconds.
As you may have observed the timing loop is self adjusting according to the clock frequency, so if it has the correct info and the correct setup you should always get very close to 1ms timing. ie don't have to redo your delay timing when the clock is different.

I thought it should have adjusted, that's why it didn't make sense that it ran correctly only after changing the OSC Freq manually to 8Mhz. I didn't take the time to debug it - sorry John, but thanks for the sample code. I've been out of the programming game for too many years and it was refreshing to see a solid .asm example.

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

Quote:

...[js]... a solid .asm example.

Now, >>there<< is an oxymoron if I've ever seen one. :twisted: [See the current thread: "C works; ASM doesn't" -- that is a maxim for life if I've ever heard one.]

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

!See later in thread for newer code version.
!This version has a bus contention bug

I've attached the code for my project.

WIRING:
Tiny2313 TXD(pd1) -> Tiny10 DATA -> Tiny2313 RXD(pd0)
Tiny2313 CLKO (pd2) -> Tiny10 CLK
Tiny2313 pd3 -> Tiny10 RESET

Method to activate...
Run program on Tiny2313.
Use debugwire to pause Tiny2313
Set QuickSetup (R25) to 0x7
Continue program

Main code does not auto download to avoid reboot loops and other pitfalls

UART is always RX (records Data Out and Data In)
UART is occasionally TX (sending command bytes to Tiny10)
UART speed is slowest possible, as datasheet mentions no timings!!
Reply data stored in ram, but I dont actually check in the code YET.

Code is compiled in to app starting at "TinyCode:"
Max 32 words (64 bytes)

TO RELEASE THE TINY10 and run your code...

WAIT FOR IT TO FINISH -> 10s!!
pause program with debugwire
Disable RXC and TXC
Toggle PD3 (tiny10 reset) TWICE.

Example code may or may not flash, I was in the middle of some changes and ahd to do "other" things first!

Attachment(s): 

Last Edited: Sun. May 31, 2009 - 01:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oops, found a code bug! :-o

My code sets the PD2(UART clock out) on startup -> it should only set it after it engages tiny10 reset.

Avr Tiny10 fights avr tiny2313 if you use PB1 as an output.
My debugwire goes awol when the contention happens.

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

recovery:

1) disconnect tclk from atiny2313 pd2
2) powercycle system incl dragon (my power == avr dragon 5V)
3) restart AvrStudio (I get stuck with a "only one instance allowed" message)

fix:
move
ldi R16,(1<<SERCLKBIT)|(0<<SERDATAOUTBIT)
out DDRD,R16
from start of "Init:" to start of "HWSetup:"

restart tiny2313 program via debugger.
From now, system will come up clean after a powercycle or 2313 reset.
So attach tclk to pd2 again.

Soon I'll post a code update that includes the fix,
and correctly "releases" automatically once the tiny10 is programmed.

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

I think I've now fixed the bugs from previous version of my tiny10 programmer.

NEW VERSION:
1) Bus contention bug fixes
2) Command "7" now programss and then reset release
3) unlimited tiny10 code size (images > 1K will cause bitwise AND of program opcodes!)
4) Auto-Program via switch
5) 2x faster uart and no code readback (cause I wasn't verifying anyway)

Auto-program allows 1 time use of PD6 (bottom right pin of attiny2313) to trigger code download.
Ground PD6 to trigger, Reset tiny2313 to get another go.

So.. this means that ISP only folks (STK500, AVRISP) can also "benefit" from the Tiny10.

Attachment(s): 

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

My physical setup.
Project does not appear to be in a "sale" condition yet.

Tiny10 sample #10- placed on top of tiny2313 to highlight it's potential pcb benefits.

MLF form of some other devices is same size, but way harder to solder.

Attachment(s): 

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

bwarren,

Thanks for the updated code as I'm an ISP-only user. I seem to be having success triggering the 2313 as my t10 RESET is pulled low and t10 CLK is pulled high. I am not getting the expected behavior from the tiny10 however (blinking leds). I'm a little curious about "Tiny2313 TXD(pd1) -> Tiny10 DATA -> Tiny2313 RXD(pd0)" I have the t2313 TXD and RXD shorted together then a wire running to pin1 (PB0) on the tiny10 is this the correct configuration?

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

Hi santacruzbob

Yes, PB0 is data and RX+TX are commoned.
Dont forget the CLK though.

Tiny10 PB1 (pin 3 bottom left) is TPICLK,
so this needs to be attached to tiny2313 PD2
(uart clock output when uart runs in synchronous mode)

Tiny10 PB0 (pin 1 top left) is TPIDATA,
so this needs to be attached to tiny2313 PD0
(uart data output + input)

Last Edited: Mon. Jun 1, 2009 - 09:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

LED wise...

I've got Led on Reset, Data and Clk.
Each led is sent to 5V Vcc via resistor.
Reset led goes on during programming
Data led pulses at 8Hz (ish)
Clock led stays in for full duration (need a scope to see it)

My non-programming pin tiny10 PB2 is a common my output leds.

From PB2, i connect led + resistor to PB0
From PB2, i connect led + resistor to PB1

Dont use too low resistor, as it could affect programming and or upset the output drive from tiny10.

Of course, now you have the source... you can just put led on PB2 and "do your own thing"!

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

My ATtiny10 is acting wierd and I need some hints with this one. I'm the first to admit it is probably something I'm doing, but I'm out of ideas.

I have a reasonably small program loop (50 lines including comments, 150 with init and subroutines). During init, I initialize the ADC, then initialize the PWM on Timer0 before reaching the main loop, the code turns the PWM on and off 3 times to signal end of init. That part works.

In the loop, I read the A2D, compare it with a constant (0xF0) and if it is above that, I turn on the PWM, if below, I turn it off. end of Loop.

I fire this up in the SIM 2 and given the state of the Studio 4 info, it appears to work. (Although I load OCR0AH and OCR0AL - those fields in the I/O view don't ever set. I think that is a bug with Studio 4.)

I burn the Tiny10 and run it. Loops real well with the VRef set to 0V (PWM Off) and 4.9V (PWM On). I have the PWM at about 50% duty cycle (OCR0AL=128) so the on board LED is medium bright when PWM is on.

When I move the VRef0 slider to ~4.6V strange things happen. It sometimes happens at other voltages too. The PWM goes on full duty cycle. I can tell by the brightness. Once it does this, I can swing the VRef0 slider to 0V and nothing happens (yes I hit "Write" each slide) and the LED appears to be stuck in this full on position. But if I slide VRef0 to 4.9V again, the LED goes back to normal brightness and then I can swing VRef0 to 0V and it will go off like nothing is wrong. And On again at 4.7 thru 4.9V. Middle voltages from 4.6 to ~3.5V exhibit the behavior.

I realize that I am one of the few with an STK600 and the Tiny10 adapter card so I don't know if anyone has witnessed strange PWM behavior on other uC parts, but if anyone can give me some tips on how to determine if the Tiny10 is wacky, the STK600 is wacky or I'm wacky - please let me know (be kind now).

Dumb question: Anyone else seen discrepancies in the SIM vs the part that could explain this?

Bob

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

Hi Bob

I have not seen any odd behaviour before, but might try out your "app" tonight to see.

Debug suggestion one:
PWM toggles output from High to Low to High etc
Are you simply stopping PWM during High time?

Debug suggestion two (related to one):
PWM always on,Read ADC, PWM <== ADC
or 255-ADC to better match original behaviour.

Other checks to make might be:
VCC still at 5V (Tiny10 going in to brownout?)
VRef actually doing what Avr Studio says (check with multimeter)
You already have checking of reset loop covered.

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

Thanks Brett

PWM clocks at about 488Hz with varying duty cycle, but for now, I leave it at about 50%. I don't know where I stop it in the cycle. Hmmm..That could explain the brighter than 50% behavior. I simply turn off the clock by writing the Timer Control Register clock speed to zero - the data sheet labels this as 'off'.
VRef0 does swing exactly as shown on the screen verified by meter.

I think I'll check out the PWM stop method.

Bob

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

Hi Bob

That (clock speed) does sound like the cause.
The clock is not counting, but PWM is still active..your "output compare" bits are still being compared and driven on to output pins etc.

Solution:
Dont kill timer, just set PWM to Min or to Max to "stop" it.
(use of 255 or 0x0 depends on inversion settings)

If inversions settings mean 0x00 is "very nearly" 1/256 off...

Use PWM mode where OCRA (or ICP) is the max value.
Set timer maximum count to 254 (instead of 255/65535)
Now PWM level 255 means "always on"
127 means "almost 50%"
0 means "always off"

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

Quote:
Solution:
Dont kill timer, just set PWM to Min or to Max to "stop" it.
(use of 255 or 0x0 depends on inversion settings)

Brett - you were absolutely right! Apparently turning off the timer leaves OCRA showing up on the output pin wherever it was when the clocked was stopped.

I implemented your suggestion and now it is stable. I was disappointed in the slight glow of the LED when off so a little digging showed that I can stop the OCRA output from showing on the pin by setting the DDR bit to input. Now the LED goes completely off. Also, the other 'bonus' is that I can now successfully blink the pwm output at nearly any blink interval - fast or slow.

Many thanks my friend. Now to put the changes in the full featured code to find the other bugs that I may have.

Bob

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

Quote:

Apparently turning off the timer leaves OCRA showing up on the output pin wherever it was when the clocked was stopped.

Yes, so when you turn off the timer (or otherwise stop the PWM) you also "disconnect" the pin and set it to the desired state. When you want to resume, you set the pin to the desired initial state, reconnect the pin to the timer, and start the timer (or the PWM).

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:

you also "disconnect" the pin and set it to the desired state

Yes - that's exactly what my LightsOff code does now:
    ldi   R16,0b00000010   ; PB0=INPUT,PB1=Output,PB2=Input,PB3=Input
    out   DDRB,R16         ; DDRB=0x03

(PWM is on PB0)
The symptoms were so erratic based on the PWM LED behavior, nothing made sense.
Now I have to look for normal code bugs with this one out of the way.

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

Quote:

you also "disconnect" the pin and set it to the desired state

Yes - that's exactly what my LightsOff code does now:


?? Well, you >>are<< turning it into an input. Whether it is floating or pulled up will depend on your PORTB >>at that particular time<<.

Here is a fragment from a Mega164 app:

// Macros for connecting/disconnecting pin
#define	PWM_MOTOR_OFF()		TCCR2A &= ~(1<<COM2B1)
#define	PWM_MOTOR_ON()		TCCR2A |= (1<<COM2B1)
...
				// Stop the motor
				PWM_MOTOR_OFF();			// disconnect pin
				OUT_MOTOR = MOTOR_OFF;		// no effect if started; sets off if stopped

So, in my case I allow the timer to keep going with its PWM, and just disconnect the pin and force the output to the desired state.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I agree with the comment from theusch.

Assuming you stop your PWM mode in the "high" state...old code left pin as output and led was on full brightness.

Now when you stop your PWM mode in the "high" state, you turn pin to input.
As an input, the "HIGH" on the PORTB turns on a 20-50K pullup resistor. This will draw about 0.1mA (3V 30K).
Assuming LED set for 10mA, this is 1%, about the "2" or "3" setting out of 256.

Alternate plan of attack...turn off pwm OUTPUT with the two COM0B bits.
(pwm still going, but pin OC0B not affected)

  in   R16,TCCR0A
  andi R16,~((1<<COM0B1) | (1<<COM0B0))
  out  TCCR0A,R16

Port now drives to what ever your previous portB register contained, hopefully 0 for strong OFF.

Regards
Brett

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

Or you could connect the LED anode to VCC through a resistor and connect the cathode to the AVR pin. This way the LED tunrs on when the port pin is low. When you then set the pin to input it doesn't matter if the internall pull-up resistor is turnedf on or off. If it's turned of the anode will float, if it's turned on, both the anode and cathode will be connected to VCC trogough a resistor and no current will flow. By turning the pull-up on in pin input mode you will avoid the LED anode floating if this is a problem. This is of course assuming the LED is not connected to the AVR pin through a common Source N-channel MOSEFET or a common Emitter NPN BJT.

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

I think I'm covered with this. I clear PORTB,PB0 at init and don't use PUEB except on my pushbutton pin. Couldn't find the path that OC0A uses to get to the pin during PWM mode. Page 62 fig 11-7 shows non-PWM mode requiring DDR to enable both PORTB and OC0A to reach the OC0A pin. Not sure if it is the same for PWM mode. I clear portB,PB0 and DDR bit - a sort of Belt and suspenders approach.

Does this make sense?

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

If you are happy that the Tiny10 is now doing the things you command it to...job done!

The intricatcies of each timer's PWM is a minefield that only careful manual reading can navigate. Other avrs are similar but never 100% the same :-)

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

Other questions for this topic:

Did anyone else actually get hold of a stk600-tiny10?

Is everyone else happy with running code on the Tiny10?

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

Quote:

Is everyone else happy with running code on the Tiny10?

I think the all the people on the planet currently using Tiny10 have already contributed to this thread - yup, both of you! ;-)

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

I feel so special being 1 of 2 on the planet :shock:

But seriously, I may have found a bug/limitation on the STK-600 when using the Tiny10. PB1 has either a clock on it (Ext/Xtal/Int switch) or when setting the clk to 0 from AVR Studio 4, the pin goes low. I can't pull it high. It's a serious limitation when you only have 4 I/O pins to test.

Does this occur on the STK600 with other AVRs?

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

bb56 wrote:
I may have found a bug/limitation on the STK-600 when using the Tiny10. PB1 has either a clock on it (Ext/Xtal/Int switch) or when setting the clk to 0 from AVR Studio 4, the pin goes low. I can't pull it high. It's a serious limitation when you only have 4 I/O pins to test.

when using the internal clock the STK600 clock selector switch should always be set to "Int".
http://support.atmel.no/knowledg...
Quote:
Clock Settings

STK600 includes several clock options for the target AVR.

A switch selects between the following three options:

    * Programmable clock generator * Crystal oscillator (with socket for a crystal)
    * XTAL1 Pin tri-stated (to be used with the AVR's internal RC oscillator)

Programmable Clock Generator

The programmable clock generator is set from the PC software. The frequency can be set from 1.1kHz to 32MHz with 0.5% accuracy.

To use the programmable clock generator as clock source, set the CLOCK switch to EXT position.

Crystal Oscillator

The on-board crystal oscillator will work with ceramic resonators or crystals between 4 and 24MHz (AT-cut, fundamental, and parallel resonant crystals). Place a crystal in the crystal socket (located next to the PROGRAM button).

To use the crystal oscillator as a clock source, set the CLOCK switch to the XTAL position.
XTAL1 Pin Tri-stated

If the target AVR run on the internal oscillator, the XTAL1 pin can be disconnected from the clock sources on STK600.

To disconnect the XTAL1 pin, set the CLOCK switch to the INT position.

Real Time Clock

The STK600 also features a 32768 Hz oscillator, which can be used to make a real time clock. The output from the oscillator is available on the 32KHz pin on the AUX header. This clock can be routed to the TOSC1 pin on the target AVR by placing a jumper between the 32KHz and TOSC1 pin on the AUX header.

See also Port Connectors for more information about the AUX header.

Other Considerations

High-Voltage Programming
When programming the target AVR in High-Voltage programming mode, the clock settings is overridden and the device is clocked directly from the STK600 controller. The clock selection switch can be set to any position.

On-chip Crystal Oscillator

In a real-life application where the crystal can be placed close to the AVR's XTAL1 and XTAL2 pins, there is no need for an external oscillator circuit. The long clock signal lines and socket system connectors on STK600 makes it difficult to drive a crystal with the on-chip oscillators. This is resolved by having a crystal oscillator on STK600. The oscillator is designed to operate over the full target voltage range.

Shared XTAL1/Port Pin

Some AVR devices have a XTAL1 pin which also can be used as a regular I/O port pin. The routing card for these devices will connect the device pin to both the XTAL1 net and a port pin header on the STK600. Hence, to use the pin as a I/O port the clock selection switch must be set to position INT to disconnect the clock drivers on STK600 from the pin.

Last Edited: Fri. Jun 5, 2009 - 09:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't have my STK600 handy to look at, but the docs say "set the CLOCK switch to the INT position."

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Thanks Lee.
The last sentence tells it all. I had tried this but my method was to check the voltage at the pin header. When in EXT position, PB1 had a clock and a mean Voltage of ~2.4V. When I connected PB1 to VRef1, a blinking red error light appeared (the unlabeled reg/green LED). I set the clock off using AVR Studio and the Voltage was still ~2.4V and the red Error light still appeared when I connected it to VRef1.

I tried the XTAL position (I have no crystal plugged in) and the Voltage was about 2.2V at PB1. When I connected PB1 to VRef1, the red error light came back. I made the assumption that PB1 was still loaded so I put a 1M resistor to VTarget and the red light stayed off, but it did not pull up the gate. It still measured ~2.2V.

When PB1 measured ~2.5V for switch position INT, I used the same 1M to try to pull it up with no luck.
Using your information this morning, I switched to INT and connected PB1 directly to Vref1 and it worked.

I went over my I/O init code a million times and could not see why PB1 was any different except for the clock on the STK-600. I down the wrong path - likely from my frustration. Thanks for pointing this out.

Now each time I program the chip, all I have to do is switch to EXT, pull all my I/O jumpers, program it, then switch to INT, put my jumpers back and cycle power to test my code (the power cycle is required because I disabled RESET to use PB3 for my pushbutton). The Tiny13 is looking better and better since it comes in a pdip package and moving it to my breadboard to test real life behavior won't be such a painful process.

Bob

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

bb56 wrote:
Now each time I program the chip, all I have to do is switch to EXT, pull all my I/O jumpers, program it, then switch to INT, put my jumpers back and cycle power to test my code (the power cycle is required because I disabled RESET to use PB3 for my pushbutton).

Why do you have to switch to EXT when you program it? Why can't you keep the switch in the INT position and keep on using the internal oscillator during programming?
Have you tried if you can program the ATtiny10 with the switch in INT setting?
The STK600 documentation does not say anything about having to connect an external clock source for TPI programming.

The good old ISP programming works fine using the internal oscillator. One thing you have to make sure of with ISP is to never set the ISP programming frequnecy faster than 1/4 of the AVR frequency, regardless if the AVR use an internal or external clock source. Atmel reccomends maximum ISP programming frequency of 1/5 of the AVR clock to be on the safe side.

Pages