tiny1616 fuse setting error

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

I had no problem using such a format to include the fuse setting in the ELF file.
However, an error occurs in tiny1616.
Is this a deficiency in device definition?
Please tell me if there is a better form.

 

#include <avr/io.h>

FUSES = {
    .WDTCFG     = WINDOW_OFF_gc | PERIOD_OFF_gc,
    .BODCFG     = LVL_BODLEVEL7_gc | SAMPFREQ_1KHZ_gc | ACTIVE_ENABLED_gc | SLEEP_SAMPLED_gc,
    .OSCCFG     = FREQSEL_20MHZ_gc,
//  .TCD0CFG	=
//  .SYSCFG0	=
//  .SYSCFG1	=
//  .APPEND     =
//  .BOOTEND	=
};

int main(void){
    while (1) {}
}

This topic has a solution.
Last Edited: Fri. Mar 2, 2018 - 10:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kabasan, What you posted above works fine here, no errors.

 

Look for the definitions in iotn1616.h.

"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

Last Edited: Fri. Mar 2, 2018 - 06:00 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

There has been an error in the ATDF file that has caused this errors. Try to update to the latest ATtiny_DFP 1.3.172 (http://packs.download.atmel.com/).

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

je_ruud wrote:

... Try to update to the latest ATtiny_DFP 1.3.172 (http://packs.download.atmel.com/).

That is the answer Kabasan.  Please mark post #3 as the solution.

 

EDIT: post # was incorrect

"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

Last Edited: Fri. Mar 2, 2018 - 07:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you very much. I successfully built it.
I thought Studio would automatically announce the update, but my environment was stopped at 1.3.147.

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

Um, what kind of operation should I mark this problem as resolved?

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

Just click [Mark as Solution] on post #3

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

OK. Thank you.

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

clawson wrote:

Just click [Mark as Solution] on post #3

Glad you posted, I had the wrong post # in my earlier post, apologies to je_ruud.

"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: 1

I thought Studio would automatically announce the update

It does... Flag in top right corner

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

Kabasan, did you brick your chip with the fuse settings you specified in post #1?

 

EDIT: If you haven't compiled and written this to a chip yet, I strongly advise that you don't.  It will brick your chip!  See the next post for more details.

"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

Last Edited: Wed. Mar 7, 2018 - 07:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@meolsen, see this post and the thread it is in. Programmatically setting the fuses with empty parameters as in the OP here will definitely brick the chip, and only 12V UPDI programming seems to be the solution.  Looking forward to seeing you there.

"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

I am sorry for my poor source being disaster.
That source is in the middle of writing, the complete version looks like this.

FUSES = {
    .WDTCFG     = WINDOW_OFF_gc | PERIOD_OFF_gc,
    .BODCFG     = LVL_BODLEVEL7_gc | SAMPFREQ_1KHZ_gc | ACTIVE_ENABLED_gc | SLEEP_SAMPLED_gc,
    .OSCCFG     = FREQSEL_20MHZ_gc,
//  .TCD0CFG    =
    .SYSCFG0    = CRCSRC_NOCRC_gc | RSTPINCFG_UPDI_gc | (0 << FUSE_EESAVE_bp),
//  .SYSCFG1    =
//  .APPEND     =
//  .BOOTEND    =
};

I knew in advance that disabling UPDI would require high voltage programming and that AtmelIce could not do it beforehand and it did not get into trouble.

Another advice of # 10, I am using AtmelStudio on two PCs and I keep flagging both. However, "Atmel ATmega Series Device Support (1.2.209)" and "Atmel ATtiny Series Device Support (1.3.172)" were not announced.

It may be something's wrong, but for me this is not very important, so I am waiting for the day to be resolved naturally.

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

kabasan wrote:

I am sorry for my poor source being disaster.

No need to be sorry Kabasan,  I was warning you not to use it, my disaster was accidental.  Actually now that it happened there is an opportunity to create a fix that may benefit many.  Thank you.

"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

*EDIT:  I manually downloaded the 1.3.172 pack , installed and it appears to work fine. I thought i read the numbers correct and was up to date.

 

I am having the same compiler issue as the OP but with at Attiny1614 sister chip. Current pack is  1.3.147

 // Set fuses:
 FUSES =
 {
	 //.WDTCFG     = 0x00,
	 .BODCFG     = ACTIVE_ENABLED_gc | LVL_BODLEVEL2_gc,
	 .OSCCFG     = FREQSEL_16MHZ_gc,
	 //.TCD0CFG	= 0x00,
	 .SYSCFG0	= RSTPINCFG_UPDI_gc,
	 .SYSCFG1	= SUT_64MS_gc ,
	 //.APPEND     = 0x00,
	 //.BOOTEND	= 0x00,
 };

~William

Last Edited: Tue. Jul 10, 2018 - 09:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using the AS7 command prompt to load a .cmd batch file for programming my Attiny1614 with an ICE.

Could i add manual fuse programming separate with commands in AS7 command prompt (just like AvrDude)?  

~William

Last Edited: Tue. Jul 10, 2018 - 09:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suppose you can use the atprogram tool that comes with Atmel Studio. Type

 

atprogram help program

and it will display information that should be enough for what you want to do.

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

I will explore other commands with atprogram, currently i have a .cmd batch file to enter in the commands automatically.

atprogram does show the fuses info once you type: atprogram help write.

So its an option thankfully, I did get the fuses in the source code to work with my .elf file.

~William

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

The main error you are seeing there is because of:

 

 

That is occurring because of avr\lib\ldscripts\avrxmega3.x which contains:

 

MEMORY
{
  text   (rx)   : ORIGIN = 0, LENGTH = __TEXT_REGION_LENGTH__
  data   (rw!x) : ORIGIN = 0x802000, LENGTH = __DATA_REGION_LENGTH__
  eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = __EEPROM_REGION_LENGTH__
  fuse      (rw!x) : ORIGIN = 0x820000, LENGTH = __FUSE_REGION_LENGTH__
  lock      (rw!x) : ORIGIN = 0x830000, LENGTH = __LOCK_REGION_LENGTH__
  signature (rw!x) : ORIGIN = 0x840000, LENGTH = __SIGNATURE_REGION_LENGTH__
  user_signatures (rw!x) : ORIGIN = 0x850000, LENGTH = __USER_SIGNATURE_REGION_LENGTH__
}

So I guess the question is where __FUSE_REGION_LENGTH__ is defined. The fact that it's a symbol name with two leading underscores suggests it is auto-generated by the complier/linker tools. Obviously what's supposed to happen is that it should match the sizeof() this:

typedef struct FUSE_struct
{
    register8_t WDTCFG;  /* Watchdog Configuration */
    register8_t BODCFG;  /* BOD Configuration */
    register8_t OSCCFG;  /* Oscillator Configuration */
    register8_t reserved_0x03;
    register8_t TCD0CFG;  /* TCD0 Configuration */
    register8_t SYSCFG0;  /* System Configuration 0 */
    register8_t SYSCFG1;  /* System Configuration 1 */
    register8_t APPEND;  /* Application Code Section End */
    register8_t BOOTEND;  /* Boot Section End */
} FUSE_t;

That is 9 bytes and the error says "overflow by 7 bytes" which suggests that __FUSE_REGION_LENGTH__ is defined as 2 rather than the 9 it should be.

 

The very old AVRs had just 2 fuse bytes (low / high) so I think someone somewhere has made a copy/paste error where they have used an old AVR definition as the template for defining this symbol for these new Xtiny models.

 

Clearly this looks like a bug in Atmel world so I'd raise a support ticket with Microchip so they are aware. It might be that Morten or Jan-Egil or someone will read about it here but you'll have more success if you raise a ticket so it goes into their Bugzilla/JIRA/whatever.

 

The short term fix will be to locally edit your copy of avrxmega3.x and change it to be:

MEMORY
{
  text   (rx)   : ORIGIN = 0, LENGTH = __TEXT_REGION_LENGTH__
  data   (rw!x) : ORIGIN = 0x802000, LENGTH = __DATA_REGION_LENGTH__
  eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = __EEPROM_REGION_LENGTH__
  fuse      (rw!x) : ORIGIN = 0x820000, LENGTH = 9
  lock      (rw!x) : ORIGIN = 0x830000, LENGTH = __LOCK_REGION_LENGTH__
  signature (rw!x) : ORIGIN = 0x840000, LENGTH = __SIGNATURE_REGION_LENGTH__
  user_signatures (rw!x) : ORIGIN = 0x850000, LENGTH = __USER_SIGNATURE_REGION_LENGTH__
}

EDIT: interesting dialog about this here:

 

https://lists.nongnu.org/archive...

 

So the feature was added by Senthil who is an engineer working for Atmel and it shows that it is binutils that is responsible for the symbol definition.

Last Edited: Wed. Jul 11, 2018 - 08:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Clawson thank you for your in dept reply, but i downloaded the newest pack: Attiny_DFP 1.3.172 and it allowed me to compile correctly with the fuse settings inside the source code.

I originally thought i was up to date, was not the case.

~William

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

So it looks like they changed the .x file - seems like good news!