Hi,
I have been looking at the datasheet for the ATtiny817 and I can't seem to find what the default (from the factory) fuse settings are?
I want to make sure that the RSTPINCFG is in UPDI mode from the factory.
I do have the 817 Xplained boards, would the 817 fuse settings on these boards be the same as the factory chips or does Atmel change the fuses for these demo boards.
Thanks!
I want to make sure that the RSTPINCFG is in UPDI mode from the factory.
If that disables the reset pin I would say it would be unprogrammed.
I do have the 817 Xplained boards,
We don't YET but should be arriving anytime now.........
The GCC header in Atmel's "pack" that includes the 817 has this:
/* ========== Fuses ========== */ #define FUSE_MEMORY_SIZE 9 /* Fuse Byte 0 Reserved */ /* Fuse Byte 1 Reserved */ /* Fuse Byte 2 Reserved */ /* Fuse Byte 3 Reserved */ /* Fuse Byte 4 Reserved */ /* Fuse Byte 5 Reserved */ /* Fuse Byte 6 Reserved */ /* Fuse Byte 7 */ #define FUSE7_DEFAULT (0xFF) /* Fuse Byte 8 */ #define FUSE_SLEEP0 (unsigned char)~_BV(0) /* BOD Operation in Sleep Mode Bit 0 */ #define FUSE_SLEEP1 (unsigned char)~_BV(1) /* BOD Operation in Sleep Mode Bit 1 */ #define FUSE_ACTIVE0 (unsigned char)~_BV(2) /* BOD Operation in Active Mode Bit 0 */ #define FUSE_ACTIVE1 (unsigned char)~_BV(3) /* BOD Operation in Active Mode Bit 1 */ #define FUSE_SAMPLFREQ (unsigned char)~_BV(4) /* BOD Sample Frequency */ #define FUSE_LVL0 (unsigned char)~_BV(5) /* BOD Level Bit 0 */ #define FUSE_LVL1 (unsigned char)~_BV(6) /* BOD Level Bit 1 */ #define FUSE_LVL2 (unsigned char)~_BV(7) /* BOD Level Bit 2 */ #define FUSE8_DEFAULT (0xFF) /* Fuse Byte 9 */ #define FUSE9_DEFAULT (0xFF) /* Fuse Byte 10 */ #define FUSE_FREQSEL0 (unsigned char)~_BV(0) /* Frequency Select Bit 0 */ #define FUSE_FREQSEL1 (unsigned char)~_BV(1) /* Frequency Select Bit 1 */ #define FUSE_OSCLOCK (unsigned char)~_BV(7) /* Oscillator Lock */ #define FUSE10_DEFAULT (0xFF) /* Fuse Byte 11 */ #define FUSE_EESAVE (unsigned char)~_BV(0) /* EEPROM Save */ #define FUSE_RSTPINCFG0 (unsigned char)~_BV(2) /* Reset Pin Configuration Bit 0 */ #define FUSE_RSTPINCFG1 (unsigned char)~_BV(3) /* Reset Pin Configuration Bit 1 */ #define FUSE_CRCSRC0 (unsigned char)~_BV(6) /* CRC Source Bit 0 */ #define FUSE_CRCSRC1 (unsigned char)~_BV(7) /* CRC Source Bit 1 */ #define FUSE11_DEFAULT (0xFF) /* Fuse Byte 12 */ #define FUSE_SUT0 (unsigned char)~_BV(0) /* Startup Time Bit 0 */ #define FUSE_SUT1 (unsigned char)~_BV(1) /* Startup Time Bit 1 */ #define FUSE_SUT2 (unsigned char)~_BV(2) /* Startup Time Bit 2 */ #define FUSE12_DEFAULT (0xFF) /* Fuse Byte 13 */ #define FUSE_CMPA (unsigned char)~_BV(0) /* Compare A Default Output Value */ #define FUSE_CMPB (unsigned char)~_BV(1) /* Compare B Default Output Value */ #define FUSE_CMPC (unsigned char)~_BV(2) /* Compare C Default Output Value */ #define FUSE_CMPD (unsigned char)~_BV(3) /* Compare D Default Output Value */ #define FUSE_CMPAEN (unsigned char)~_BV(4) /* Compare A Output Enable */ #define FUSE_CMPBEN (unsigned char)~_BV(5) /* Compare B Output Enable */ #define FUSE_CMPCEN (unsigned char)~_BV(6) /* Compare C Output Enable */ #define FUSE_CMPDEN (unsigned char)~_BV(7) /* Compare D Output Enable */ #define FUSE13_DEFAULT (0xFF) /* Fuse Byte 14 */ #define FUSE_PERIOD0 (unsigned char)~_BV(0) /* Watchdog Timeout Period Bit 0 */ #define FUSE_PERIOD1 (unsigned char)~_BV(1) /* Watchdog Timeout Period Bit 1 */ #define FUSE_PERIOD2 (unsigned char)~_BV(2) /* Watchdog Timeout Period Bit 2 */ #define FUSE_PERIOD3 (unsigned char)~_BV(3) /* Watchdog Timeout Period Bit 3 */ #define FUSE_WINDOW0 (unsigned char)~_BV(4) /* Watchdog Window Timeout Period Bit 0 */ #define FUSE_WINDOW1 (unsigned char)~_BV(5) /* Watchdog Window Timeout Period Bit 1 */ #define FUSE_WINDOW2 (unsigned char)~_BV(6) /* Watchdog Window Timeout Period Bit 2 */ #define FUSE_WINDOW3 (unsigned char)~_BV(7) /* Watchdog Window Timeout Period Bit 3 */ #define FUSE14_DEFAULT (0xFF)
That seems to suggest that all the used fuses (7..14) default to 0xFF in fact.
That is really cool find, thank you!
I am not sure what it would mean for it to be 0xFF as that seems to be a "reserved" selection from the datasheet (See attached).
Although the datasheet seems to be a work in progress, the November release is much better then the September release for the 817.
I did get a nasty surprise when the November datasheet came out for the 817, it looks like the on board DAC can only handle about 1 mA, so back to a separate DAC.
I did open a support case with Atmel to find out if it defaults to UPDI, I will check back in when I get a definitive answer.
it looks like the on board DAC can only handle about 1 mA, so back to a separate DAC.
1mA is a HUGE current feeding an opamp requiring picoamps, which is usually what happens with analog signals to become useful.
How are you using the DAC that may require a higher current?
That seems to suggest that all the used fuses (7..14) default to 0xFF in fact.
You shouldn't take those default values too seriously. I can confirm that the fuse settings on a new device is NOT 0xFF on all addresses. I'll try to come up with the correct ones.
Our header file generator sets the default value of fuses to 0xFF if it hasn't gotten any input for it, and for tiny817 it hasn't gotten any inputs.
The default fuse settings for ATtiny817 seems to be
1280: 00 00 02 ff 00 f4 07 00 00
I guess that it's only Atmel that so far have tiny817 chips
Are there any time frame for when we can buy / get samples of the chip?
And are the chips on the dev. boards the release that go on sale?
I see that digikey now have the chip in the system but no stock (and they call max voltage 3.6V I really hope it's an error).
And are the chips on the dev. boards the release that go on sale?
Yes.
Thanks then perhaps it's time to get hold on a dev board :)
(for those that find it odd to ask. It's very normal that an extra spin of the chip is needed, logic fixed, but some of the analog things could need a change/fine tune to keep yield up)
Thanks then perhaps it's time to get hold on a dev board :)
(for those that find it odd to ask. It's very normal that an extra spin of the chip is needed, logic fixed, but some of the analog things could need a change/fine tune to keep yield up)
Aren't you on the list from this thread, https://www.avrfreaks.net/forum/a...? You should PM your mail address if you haven't already.
(Yes, the revision question is a valid point, but this time we got it right :-) The revA was only used internally, revB is the thing.)
You shouldn't take those default values too seriously. I can confirm that the fuse settings on a new device is NOT 0xFF on all addresses. I'll try to come up with the correct ones. Our header file generator sets the default value of fuses to 0xFF if it hasn't gotten any input for it, and for tiny817 it hasn't gotten any inputs.
FUSES = {
.fuse7 = FUSE7_DEFAULT,
.fuse8 = FUSE8_DEFAULT,
.fuse9 = (FUSE_SLEEP1 & FUSE_ACTIVE0)
etc.
};or whatever and any place they use xxx_DEFAULT they are now going to really screw up their chip! Far better to get a "FUSE7_DEFAULT symbol undefined" error!
Your header file generator should not generate _DEFAULT values if it does not know.
...which is what I've written in the internal bug-tracker (DEVXML-1128).
I am making a device for the research doctors at OHSU (Oregon Health Science University). I could need as much at 8 mA but usually around 3 to 4.
Okay, heard back from Atmel on that register. See below.
Our internal IC design confirms that the default state of RSTPINCFG[1:0] is UPDI mode.
We filed a bug in datasheet. This will be fixed in the next version of datasheet.
Thanks for notifying this bug to us.
Hope this clarifies your query. We are closing this case now. Kindly revert back if you need further clarifications.
I could need as much at 8 mA but usually around 3 to 4.
"Then buffer it dear Henry, dear Henry, dear Henry, then buffer it dear Henry, dear Henry buffer it". 
An opamp would be a lot simpler and cheaper than using an external DAC.
Okay, heard back from Atmel on that register. See below.
Thanks.
The opamp is a good idea! I got the external DAC working on a prototype but I will look into modifying my circuit.
Thanks and sorry for the slow reply.
P
Edited for clarity.
