Programming a new AVR device?

Go To Last Post
76 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi. So I just designed a built a circuit around the new Attiny1634... how do I go about programming it if it isn't yet supported by AVRDude? Or is it? How do I even know? Thanks.

- Steven

Last Edited: Wed. Jul 25, 2012 - 12:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Shawn. I'd be real surprised if it couldn't be programmed with any old ISP or clone. I ordered an Atmel AVRisp mkii right from the Atmel store. The EU dudes will tell you to get an AVRisp from Thomas Fischl in Germany. i sent him an email and he said he doesnt sell to Americans. How do you like that?

Imagecraft compiler user

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

It would be listed in the avrdude.conf file. I do not see it listed in the latest avrdude (version 5.11.1). It should not be too hard to create a definition for the chip, I have never written one though.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

bobgardner wrote:
Hi Shawn. I'd be real surprised if it couldn't be programmed with any old ISP or clone. I ordered an Atmel AVRisp mkii right from the Atmel store. The EU dudes will tell you to get an AVRisp from Thomas Fischl in Germany. i sent him an email and he said he doesnt sell to Americans. How do you like that?

Thanks Brian ("Brian?"... well, who's Shawn? lol). I wasn't asking about the physical connection. I'm sure my ISP can do it too. The point was the chip isn't being recognized. In other words, what -P do I declare?

- Steven

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

larryvc wrote:
It would be listed in the avrdude.conf file. I do not see it listed in the latest avrdude (version 5.11.1). It should not be too hard to create a definition for the chip, I have never written one though.

Me neither :)

So yeah... can someone please help with how I'd do what Larry said?

- Steven

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

I thought you were Shawn Mack from Florida. Sorry bout that. How many S Macks are AVR freaks? Small world.

Imagecraft compiler user

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

If your hardware supports SPI, PDI, TPI, JTAG or whichever physical interface your Tiny1634 uses, you should be fine.

Simply write a new entry for the avrdude.conf file. The format is pretty intuitive.

Then use -p ATtiny1634 --- -P is for the comms channel e.g. USB, LPT, COM, ...

I presume that an AVRISP-2 is 'hardware' capable.

David.

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

david.prentice wrote:
Simply write a new entry for the avrdude.conf file. The format is pretty intuitive.
Steven was hoping that somebody might help him with that. It does look simple, but doing it the first time is often awkward. :wink:

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

david.prentice wrote:
Simply write a new entry for the avrdude.conf file. The format is pretty intuitive.

That's the part I want not glossed over :)

Hardware isn't the issue.... its software.

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

I have simply changed the id, desc, signature of a ATmega168 in the avrdude.v10 conf file.
This should cope with regular SPI programming.

It appears to use the same SPI commands from a brief comparison of data sheets.

Note that I have made no attempt to check the HVPP details.

David.

#------------------------------------------------------------
# ATtiny1634
#------------------------------------------------------------

part
    id              = "t1634";
    desc            = "ATTINY1634";
     has_debugwire = yes;
     flash_instr   = 0xB6, 0x01, 0x11;
     eeprom_instr  = 0xBD, 0xF2, 0xBD, 0xE1, 0xBB, 0xCF, 0xB4, 0x00,
	             0xBE, 0x01, 0xB6, 0x01, 0xBC, 0x00, 0xBB, 0xBF,
	             0x99, 0xF9, 0xBB, 0xAF;
    stk500_devcode  = 0x86;
    # avr910_devcode = 0x;
    signature       = 0x1e 0x94 0x12;
    pagel           = 0xd7;
    bs2             = 0xc2;
    chip_erase_delay = 9000;
    pgm_enable       = "1 0 1 0 1 1 0 0 0 1 0 1 0 0 1 1",
                       "x x x x x x x x x x x x x x x x";

    chip_erase       = "1 0 1 0 1 1 0 0 1 0 0 x x x x x",
                       "x x x x x x x x x x x x x x x x";

    timeout         = 200;
    stabdelay       = 100;
    cmdexedelay     = 25;
    synchloops      = 32;
    bytedelay       = 0;
    pollindex       = 3;
    pollvalue       = 0x53;
    predelay        = 1;
    postdelay       = 1;
    pollmethod      = 1;

    pp_controlstack     =
	0x0E, 0x1E, 0x0F, 0x1F, 0x2E, 0x3E, 0x2F, 0x3F,
	0x4E, 0x5E, 0x4F, 0x5F, 0x6E, 0x7E, 0x6F, 0x7F,
	0x66, 0x76, 0x67, 0x77, 0x6A, 0x7A, 0x6B, 0x7B,
	0xBE, 0xFD, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00;
    hventerstabdelay    = 100;
    progmodedelay       = 0;
    latchcycles         = 5;
    togglevtg           = 1;
    poweroffdelay       = 15;
    resetdelayms        = 1;
    resetdelayus        = 0;
    hvleavestabdelay    = 15;
    resetdelay          = 15;
    chiperasepulsewidth = 0;
    chiperasepolltimeout = 10;
    programfusepulsewidth = 0;
    programfusepolltimeout = 5;
    programlockpulsewidth = 0;
    programlockpolltimeout = 5;

    memory "eeprom"
        paged           = no;
        page_size       = 4;
        size            = 512;
        min_write_delay = 3600;
        max_write_delay = 3600;
        readback_p1     = 0xff;
        readback_p2     = 0xff;
        read            = " 1 0 1 0 0 0 0 0",
                          " 0 0 0 x x x x a8",
                          " a7 a6 a5 a4 a3 a2 a1 a0",
                          " o o o o o o o o";
    
        write           = " 1 1 0 0 0 0 0 0",
                          " 0 0 0 x x x x a8",
                          " a7 a6 a5 a4 a3 a2 a1 a0",
                          " i i i i i i i i";

	loadpage_lo	= "  1   1   0   0      0   0   0   1",
			  "  0   0   0   0      0   0   0   0",
			  "  0   0   0   0      0   0  a1  a0",
			  "  i   i   i   i      i   i   i   i";

	writepage	= "  1   1   0   0      0   0   1   0",
			  "  0   0   x   x      x   x   x  a8",
			  " a7  a6  a5  a4     a3  a2   0   0",
			  "  x   x   x   x      x   x   x   x";

	mode		= 0x41;
	delay		= 5;
	blocksize	= 4;
	readsize	= 256;
        ;

    memory "flash"
        paged           = yes;
        size            = 16384;
        page_size       = 128;
        num_pages       = 128;
        min_write_delay = 4500;
        max_write_delay = 4500;
        readback_p1     = 0xff;
        readback_p2     = 0xff;
        read_lo         = " 0 0 1 0 0 0 0 0",
                          " 0 0 0 a12 a11 a10 a9 a8",
                          " a7 a6 a5 a4 a3 a2 a1 a0",
                          " o o o o o o o o";
        
        read_hi          = " 0 0 1 0 1 0 0 0",
                           " 0 0 0 a12 a11 a10 a9 a8",
                           " a7 a6 a5 a4 a3 a2 a1 a0",
                           " o o o o o o o o";
        
        loadpage_lo     = " 0 1 0 0 0 0 0 0",
                          " 0 0 0 x x x x x",
                          " x x a5 a4 a3 a2 a1 a0",
                          " i i i i i i i i";
        
        loadpage_hi     = " 0 1 0 0 1 0 0 0",
                          " 0 0 0 x x x x x",
                          " x x a5 a4 a3 a2 a1 a0",
                          " i i i i i i i i";
        
        writepage       = " 0 1 0 0 1 1 0 0",
                          " 0 0 0 a12 a11 a10 a9 a8",
                          " a7 a6 x x x x x x",
                          " x x x x x x x x";

        mode        = 0x41;
        delay       = 6;
        blocksize   = 128;
        readsize    = 256;

        ;
        
    memory "lfuse"
        size            = 1;
        min_write_delay = 4500;
        max_write_delay = 4500;
        read            = "0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0",
                          "x x x x x x x x o o o o o o o o";
        
        write           = "1 0 1 0 1 1 0 0 1 0 1 0 0 0 0 0",
                          "x x x x x x x x i i i i i i i i";
        ;
    
    memory "hfuse"
        size            = 1;
        min_write_delay = 4500;
        max_write_delay = 4500;
        read            = "0 1 0 1 1 0 0 0 0 0 0 0 1 0 0 0",
                          "x x x x x x x x o o o o o o o o";
        
        write           = "1 0 1 0 1 1 0 0 1 0 1 0 1 0 0 0",
                          "x x x x x x x x i i i i i i i i";
        ;
    
    memory "efuse"
        size            = 1;
        min_write_delay = 4500;
        max_write_delay = 4500;
        read            = "0 1 0 1 0 0 0 0 0 0 0 0 1 0 0 0",
                          "x x x x x x x x x x x x x o o o";
        
        write           = "1 0 1 0 1 1 0 0 1 0 1 0 0 1 0 0",
                          "x x x x x x x x x x x x x i i i";
        ;
    
    memory "lock"
        size            = 1;
        min_write_delay = 4500;
        max_write_delay = 4500;
        read            = "0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0",
                          "x x x x x x x x x x o o o o o o";
        
        write           = "1 0 1 0 1 1 0 0 1 1 1 x x x x x",
                          "x x x x x x x x 1 1 i i i i i i";
        ;
    
    memory "calibration"
        size            = 1;
        read            = "0 0 1 1 1 0 0 0 0 0 0 x x x x x",
                          "0 0 0 0 0 0 0 0 o o o o o o o o";
        ;
    
    memory "signature"
        size            = 3;
        read            = "0 0 1 1 0 0 0 0 0 0 0 x x x x x",
                          "x x x x x x a1 a0 o o o o o o o o";
        ;
;

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

First there appeared 8kB tinys, now 16kB tinys, what is next?
1kB of RAM, Two USARTs, more advanced RC calibration, asm(JMP), no MUL, RAM starts at 0x100, max 2MHz at 1,8V and max 12MHz at 4,5V operation.

It also has a QTCSR register...
Perhaps it is high time to add a new Quiz question?

No RSTDISBL, no fun!

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

Thanks David, I'll try that... what is HVPP?

Brutte... I'm not really sure what your post is suggesting?

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

Your data sheet has a chapter:

Quote:
23. External Programming

HVPP is the 'parallel programming' with 12V on the RST pin.

ISP is the 'in-circuit serial programming' with regular voltages on the pins.

I can see that you would be nervous of writing an avrdude 'conf' entry.
But you should know which part of your data sheet describes the relevant parts of your chip.

Don't expect to read it all. Or understand it all. Just be familiar with it. i.e. know how to look up a certain peripheral / register etc.

David.

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

David... I understand the datasheet is an important resource, and that the info is all there. But... when certain parts are unfamiliar, I may as well be reading Greek (and I can't read Greek). Prior to replying, I did open up the datasheet and I searched for "HVPP" with no hits - hence the request for clarification. Jargon and acronyms makes learning harder. That's the case in any field.

Thank you very much for the assist.

- Steven

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

Quote:
Brutte... I'm not really sure what your post is suggesting?

Absolutely no suggestions. The chip looks similar to other tinys w.r.t. programming/debugging capabilities so you should not have problems with that. Mind fuse bits.

No RSTDISBL, no fun!

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

Ok... I think I got it working?

But then the first thing I did was started reading out fuse bits to file, just to make sure it was working OK. For a lock bit, I get 0x3F where I was expecting 0xFF from the datasheet (page 222) that says the default is all 1's. Am I just missing something obvious?

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

Another thing... I have to use the -B switch to slow the SCK way down, otherwise I get "target does not answer". I figured this was because the default fuse settings were making the clock slow, but once I removed the div/8 there's no change. Ideas?

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

First off, post your command lines.
And the response from avrdude. (preferably a reasonably short form)

You should be able to read virgins with -B5 and experienced non-CKDIV8 chips with -B1 or -B0.5
However you need to read what the fuses and lock bits are first.

Regarding 0x3F. Examine the CONF entry. Doesn't it call bit6,7 don't care ?
If you do care, change to "o o"

David.

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

This is what David was referring to in his post about the chip definition above. An x is a don't care.

Quote:
memory "lock"
.
.
.
.
read mask --> "x x x x x x x x x x o o o o o o";

=================================================================

This keeps the chip definition above from wrapping lines.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

My Firefox is displaying in "Maximise" mode. So the CODE did not wrap for me.
You should be able to copy-paste CODE into your editor whether the Freaks display has wrapped or not.
Forcing a wide display is fine for 80-wide or so. Forcing it to 100s-wide is horrible.

Regarding avrdude CONF entries.
If you write to a fuse or lock memory with "x x x i i i i i" (don't care) bits then they are written as 0.
If you read from a fuse or lock memory with "x x x o o o o o" (don't care) bits then they are read as 0.

This causes an anomaly when you write 0xFF because it will read back as 0x1F and upset the punter.

IMHO, it is best to configure unused write fuse bits as "1" and to read back all 8 bits e.g. "o o o o o o o o"

Historically, avrdude.conf has entries that are configured differently.

David.

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

Not everybody uses maximize and we were referring to that definition where the last bit had wrapped. No biggie.

david.prentice wrote:
Historically, avrdude.conf has entries that are configured differently.

Is that good differently or bad differently? :)

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

It is a PITA differently.

Have you not noticed the whinges when someone sets lock bits or efuse and are upset by the read values?

e.g. the verify fails.

David.

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

david.prentice wrote:
Have you not noticed the whinges when someone sets lock bits or efuse and are upset by the read values?

e.g. the verify fails.


Oh, that PITA differently! Perhaps a disclaimer like on engbedded.com would help. Naw, probably not.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

IMHO, it just needs someone to quietly go through the avrdude.conf file and edit it.

However I guess that many scripts are in existence that rely on this behaviour.
So it is probably safer to leave well alone.

David.

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

I recognize that those bits don't matter, but the datasheet didn't say they were set to "don't care"... it says they are set to 1's by default, and they aren't. If the Holy Bible of AVR learning is "read the datasheet", then the datasheet needs to be exacting.

Anyway...

Quote:
avrdude -p t1634 -c usbasp -U lfuse:r:lfuse.txt:h

No B switch, yields:
Quote:
avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.

avrdude done. Thank you.


Same with a -B up to 10:
Quote:
avrdude -p t1634 -c usbasp -U lfuse:r:lfuse.txt:h -B 10

yields:
Quote:
avrdude: set SCK frequency to 93750 Hz
avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.

avrdude done. Thank you.


-B higher than 10, however...
Quote:
avrdude -p t1634 -c usbasp -U lfuse:r:lfuse.txt:h -B11

yields:
Quote:
avrdude: set SCK frequency to 32000 Hz
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9412
avrdude: reading lfuse memory:

Reading | ################################################## | 100% 0.01s

avrdude: writing output file "lfuse.txt"

avrdude: safemode: Fuses OK

avrdude done. Thank you.

Now, that command above, resulted in a file containing:

Quote:
0xe2
which is 11100010, which (according to the flawless datasheet) is identical to default except bit 7 is unprogrammed, meaning "Divides by 8" is false. Everything else is default, so this should be running at 8Mhz.

- Steven

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

Try this, and post the output.

Quote:
avrdude -p t1634 -c usbasp -B 11 -v

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
avrdude: Version 5.10, compiled on Jan 19 2010 at 10:45:23
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "E:\WinAVR-20100110\bin\avrdude.conf"


         Using Port                    : lpt1
         Using Programmer              : usbasp
         Setting bit clk period        : 11.0
         AVR Part                      : ATTINY1634
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page
      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65     5     4    0 no        512    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     16384  128    128  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0 0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0 0 0x00 0x00

         Programmer Type : usbasp
         Description     : USBasp, http://www.fischl.de/usbasp/

avrdude: set SCK frequency to 32000 Hz
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9412
avrdude: safemode: lfuse reads as E2
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as 7

avrdude: safemode: lfuse reads as E2
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as 7
avrdude: safemode: Fuses OK

avrdude done.  Thank you.
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Where did you get your usbasp firmware from ?

You appear to only function with the bit-banged slow SPI.
None of the -B settings that select the hardware SPI seem to work.

For the moment, you will just have to use your -B11 and program very SLOWly.

Does your usbasp work normally with other chips?
Can you upload a different firmware ?
i.e. do you have another programmer?

All (?) usbasp firmware does a completely pointless SCK synchronisation. Pointless but harmless too! If the AVR does not 'enter ISP' immediately after RESET goes low, then any amount of clock pulses will make no difference. i.e. always fails.
Do you have proper 100nF caps on your VCC line ?

David.

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

I'll let David cover the USBasp details. He has a lot more experience with the USBasp and avrdude than I do.

You can run a simple test to see if you are indeed running at 8 MHz. Something similar to this: (LED blinks once per second)

/*
* Blinky.c
*/

#define F_CPU 8000000UL

#include 
#include 

int main(void)
{
	DDRB = 0x01;
	PORTB = 0x01;
	
	while(1)
	{
		_delay_ms(500);
		PINB = 0x01;
	}
}

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

david.prentice wrote:
Where did you get your usbasp firmware from ?

Official source
david.prentice wrote:
You appear to only function with the bit-banged slow SPI.
None of the -B settings that select the hardware SPI seem to work.

For the moment, you will just have to use your -B11 and program very SLOWly.

Yeah, so I noticed :(

david.prentice wrote:
Does your usbasp work normally with other chips?
Sure does
david.prentice wrote:
Can you upload a different firmware ?
Yeah. I updated the f/w that's on there now to the latest. Previously, it couldn't set SCK at all.
david.prentice wrote:

i.e. do you have another programmer?
Lol... don't ask why, but yes. I have literally over 200 USBasps here. However, they're purpose-built for a specific application. They don't have standard ISP headers.

I also have a home-brew AVRisp MKII somewhere.

The usbasp that I'm using now is the only "bought" one that I have for avr.

david.prentice wrote:

Do you have proper 100nF caps on your VCC line ?
Of course. :)

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

This seems a mystery to me. However the obvious suspicions lie with:
capacitance on the RESET, SCK, MOSI, MISO line.

RESET should be fine with 100nF or so. Quite honestly, SCK etc should probably work with 1nF.

Since your usbasp drives the SPI lines of other AVR boards, I would assume that there are no dry joints that might give a high series-resistance.

A high resistance will have the same effect. i.e. a large RC time-constant.
e.g 100R * 1nF = 100ns which is insignificant at <= 1500kHz
e.g. 10k * 50pF = 500ns which is insignificant at <= 375kHz
e.g. 100k * 50pF = 5us which is insignificant at <= 32kHz
e.g 100R * 100nF = 10us which is insignificant at <= 16kHz

50pF is a typical board capacitance on a badly layed out pcb.
100R is a typical output resistance of an AVR GPIO line.
100k is a really bad dry joint.

You can see from these figures that a programmer with a 'safety' 1k series resistor in the lines will struggle with any parallel capacitance.

Have you got a Scope or Logic Analyser?

David.

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

I just got some tiny1634's and tried your avrdude.conf entry with an usbasp. I noticed that the t1634 have flash page size of 16 words, so I had to change the .conf under memory "flash" to this:

        page_size       = 32;
        num_pages       = 512;

Then I could program the flash successfully. But I still can't go under -B11 (32kHz) even with CKDIV8 disabled.

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

Where did you get the tiny1634 from?

RS, Farnell, Rapid do not stock them.

I only made a brief glance at the Serial ISP commands. Obviously you need to compare them carefully with any avrdude.conf entry.

Can you examine the sequence with a Logic Analyser. I would be pretty certain that any new Atmel AVR is going to behave much the same as the existing devices.

David.

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

I got them from Mouser. At the moment they have a little more than 1000 each of both R and the non R version. (the R version have higher accuracy on the internal RC osc., +/- 2% instead of +/- 10%).

I will try to look up the details of the avrdude.conf entry. I don't have a logic analyser (well I have a BusPirate, but I've never used it as a LA, maybe I'll try that if I can find some time for that).

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

As far as I can see, the only stocks of tiny1634 are in the US.

It is a pain buying anything from the US. They normally want to charge you $50 for DHL.
Ah-ha. Mouser charge £12 ($18) so that is not too bad.

I have never used a Bus Pirate but it should be simple enough to monitor the initial 0xAC530000 "Enter ISP" command.

David.

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

They have free shipping if you buy for $100 or more, but that's almost 100 t1634's ;-).

I tried to program with a stk500, then I could go town to -B 1.1 without problems.

My usbasp have the latest firmware, but I've only used it for TPI programming before (without problems).

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

David, I'll send you a free 1634 if you get the proper conf working :)

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

Now I have a logic analyzer (why didn't I get that before?).
As I understand it, the SPI session starts with the programmer sends 0xAC, 0x53, 0x00, and receive back 0x53 on the third byte.

This works with usbasp and -B11, but not with -B10. As you can see the programmer is only sending 0xAC followed by two zeros and no 0x53!?

(Oh, I just got another star :-))

Attachment(s): 

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

You should always 'trigger' on ENABLE going low. You can also measure period and frequency by hovering on the display.

Your first screenshot seems to have odd clock pulses. Perhaps you have an inappropriate sample frequency.

Yes. A Logic Analyser is really useful. A Saleae has a virtually unlimited sampling length. In general, you need to sample at least 2x the speed of any signal. In practice, 8x will give you a good picture.

s_mack is mailing me a tiny1634, which should arrive next week. I will be able to examine its behaviour with different usbasp firmware(s). From your earlier post, it appears that stk500v2 protocol works absolutely normally.

David.

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

david.prentice wrote:
You should always 'trigger' on ENABLE going low.
Yes I know, but it takes about 100ms after reset goes low until things start to happen, so I triggered on SCL instead. It still shows what happens before the trig.
Quote:
Your first screenshot seems to have odd clock pulses. Perhaps you have an inappropriate sample frequency.
I saw that. But that image is the case when it works.

Quote:
From your earlier post, it appears that stk500v2 protocol works absolutely normally.
Yes it does.

But I found something else. It actually works with -B1 one time after I plug in the usbasp, but if I repeat I have to use at least -B11 or replug the usbasp. And the clock pulse is regular this first time with -B1 (but not first time with -B11).

Edit: Since this is the first time I use an usbasp in ISP mode, I verified that it worked as it should with another AVR (mega328p). It did.

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

Ah-ha. I have just inspected the 'current' fischl.de firmware.

And it initially sends AC 00 00 00 after RESET.
Then it sends a RESET pulse followed by AC 53 00 00

The AVR recognises the AC 53 00 00 and replies with: FF FF 53 00 as expected

I inspected a mega32 response. I guess that the tiny1634 is more critical. Despite my earlier ranting, the current firmware seems quite respectable. Note that the very first 'avrdude' after you plug in the usbasp sends AC 53 00 00 and hence 'connects' immediately. You can 'correct' the AC 00 00 00 behaviour by reading SPSR and SPDR when you initialise the SPI.

Incidentally, my usbasp showed regular clock signals for -B0.5 to -B10 (hardware SPI). It showed the variable period in your screenshot for -B11 (bit-banged SPI).

David.

Edit. I had initially replied about the behaviour of the Chinese LcsoftStudio firmware. This issues an 'extra' SCK pulses to unsynchronise the SPI. (like the earlier fischl.de firmware)
This has totally destroyed my understanding of AVR 'Enter programming' sequence. And assumed that the AVR only responded to the first AC 53 00 00 after reset.

However the Chinese get to 'Enter' after sufficient odd pulses without a reset.

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

I would also be interested in support for ATtiny1634 in avrdude.

After having issues with AvrStudio 6.0 in Windows, I am exploring Linux as well :)

In Windows I could not go back from debugWIRE mode to ISP mode
(after setting DWEN fuse). In fact Atmel support confirmed that could reproduce the issue in AVR Studio 6.0. Can you believe this? =) But I faced the same issue with ATmega168. So it is really something wrong there.

When will there be official support for Attiny1634 in avrdude?

How about avarice and gdb debugger? Will this work with ATtiny1634 already or does it need also customisations?
I would like to use graphical front-end DDD for debugging ATtiny1634 and ATmega168 through debugWIRE, and ATmega644P and ATmega640 through JTAG. This would be heavy armor for proper debugging! =)

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

Quote:

When will there be official support for Attiny1634 in avrdude?


When someone volunteers to do the work to add it. That's the whole point of open source collaborative developments. Those that need a new feature add it to the pot so it can then be shared by everyone else. If everyone sits around just asking "when will new feature XXX turn up?" it never will.

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

Similarly, if those that know how to do it sit around just stating "just do it" to those that don't... it never will. But then, that's kind of the failure of open source, isn't it?

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

I would guess that you can have a tested avrdude.conf entry before the end of the week.
I will see how well AS6.0 works with the tiny1634 with Dragon and JTAGICE-mkII. No doubt some JTAGICE-3 owner may try that too.

I think you are being very optimistic to expect a slick graphical Linux debug support. For a start, someone will need to do the Linux work.

It looks as if IAR support the tiny1634.
Rowley does not appear to support the tiny1634.

David.

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

David,

You are the best! Looks like you are going to be a ATtiny1634 user soon too =)

I would be interested in hearing feedback on AS6.0 scenario: going from ISP to debugWIRE, and (trying) to come back to ISP =)

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

@snigelen

In your earlier post of 3 Aug you showed a Logic Analyser trace of -B11 i.e. usbasp doing bit-banged 32kHz SPI.

It has driven me mental, wondering why the SCK pulses are of odd period.

I looked at several different fischl.de firmware versions. They all display the uneven SCK. It appears to be every 1ms you get about 66% 11kHz and 33% 32kHz (the correct frequency). USB interrupts occur every 1ms or so.

I can see no reason for the ispDelay() function to behave like this. The ISR() servicing the USB only takes microseconds to service. Yet why should you get 'long' SCK pulses for 660us ?

The problem is academic. No one is ever going to use usbasp at < 93kHz. The hardware SPI looks completely normal.

I can see no reason for the ispDelay() taking a different time. Nothing else uses the Timer0. The register allocation looks normal to me.

David.

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

I can't really see why the SCK pulse should be irregular either.

Oh, so -B11 seems to be the lowest value for soft SPI.

The irregularities is less notable in even longer SCK periods.

If I cheat and change sck_sw_delay = 3; (this is for 32kHz) to sck_sw_delay = 0; in the usbasp firmware it actually works, and pretty fast. But the irregularities is now very notable, small bursts of about 444kHz pulses followed by a long 42 us pulse. See attachment.

I said before that it works in any speed the first time after you plug in the USB-asp. To be more precise, it will only work one time in hardware SPI mode after plugin.

Attachment(s): 

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

Quote:
To be more precise, it will only work one time in hardware SPI mode after plugin.

The answer to that is to read SPSR and SPDR when you 'connect'. i.e. clear any WCOL bit.

I was looking forward to running a tiny1634 today. s_mack very kindly mailed me one. However it is QFN and not SOIC-20 so I can't do anything with it. (unless I get a new set of eyes and a QFN adapter !)

I could understand the 42us 'ispDelay()' if it corresponded to regular ISR()s. But TCNT0 is free-running, and the function simply waits for TCNT0 to reach a value.

David.

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

And if I change

void spiHWenable() {
        SPCR = sck_spcr;
        SPSR = sck_spsr;
}

in usbasp's isp.c to

void spiHWenable() {
        uint8_t dummy;
        SPCR = sck_spcr;
        SPSR = sck_spsr;
        if (SPSR & (1<<SPIF))
                dummy = SPDR;  // Clear interrupt flag
}

it works every time! Even with -B0.1 (1.5MHz, but it's not really faster that -B1).

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

david.prentice wrote:
The answer to that is to read SPSR and SPDR when you 'connect'. i.e. clear any WCOL bit.
Hm, it seems to work if I access SPDR only if SPIF is set, but maybe it's always set when WCOL is set? But I guess you can du the SPSR, SPDR access regardless of the flags in SPSR?

Pages