ATtiny1616 start-up time much to long ---- solved

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

I have an application, where the start-up time of the processor after power-on has to be as short as possible. With internal clock of 16MHz it should be around 200µs, regarding data sheet. But I see a start-up time of 4ms @16MHz and 3,3ms @20MHz. And there is no code that is responsive for the delay. For testing, the first command is a digital output, where I can see the delay after power-up.

 

VCC is 3V, working frequency is 4MHz (16/4) and the Fuses are as follows:

Fuses

This topic has a solution.
Last Edited: Fri. Dec 6, 2019 - 10:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is your power supply rise time?  What is the VCC level?

I see you set a BOD at 1.8v, look in the data sheet and see if that is a valid level for 16MHz or 20MHz clock, ie. safe operating level.

 

Jim

Perhaps a higher BOD level would make more sense.

Edit:

Sorry missed 3.3v vcc and 4MHz clock....

What is the app that needs such fast startup?

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

Last Edited: Tue. Dec 3, 2019 - 02:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is the rise time of the VCC:

 

Power rise time

 

I have tried to switch on the BOD, since I have no external reset-ic. But no effect on the delay.

If I set the fuse "Oscillator Lock", the delay decreases to 3ms, but the timing of the UART went wrong.

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

skysurfer243 wrote:
And there is no code that is responsive for the delay.

 

How do you know? Is this C? Assembly?

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

An eeprom erase/write takes 4ms. The main clock should be in the 8us range to start, it says. The default clock div is /6, so startup code would need to be taking ~10k clocks which seems unlikely.

 

I would first make sure the SYSCFG1 register was correct regardless of what the fuse settings say they should be. Read it in the app or use the debugger. Would hate to be looking all over and later find the sut was not set right for whatever reason.

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

skysurfer243 wrote:
But I see a start-up time of 4ms @16MHz and 3,3ms @20MHz
How are you observing this? Do you do something like tweak an IO line and catch that on a scope as the first power on action of the software or something?

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

>If I set the fuse "Oscillator Lock", the delay decreases to 3ms, but the timing of the UART went wrong.

 

I believe there is a problem when using that fuse bit, IF I remember correctly (there is a thread here somewhere). When it is used, the cal20m value ends up being set to an extreme value. That is why the uart goes bad.

 

Just tested on a tiny817- cal20m is 32 when osclock is set, 18 when clear (default).

 

>But I see a start-up time of 4ms @16MHz and 3,3ms @20MHz

 

That seems to indicate its something based on clock cycles as both seem to be in the 10K clocks area (ms x clk/div6).

Last Edited: Tue. Dec 3, 2019 - 05:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Make sure you don't have a cap on the reset line & do have a solid pull up resistor.  Also, make sure your programmer is disconnected/not touching the reset line.

Is your reset line pulled up to chip Vcc, or somewhere else (slower)?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

avrcandies wrote:

Make sure you don't have a cap on the reset line & do have a solid pull up resistor.  Also, make sure your programmer is disconnected/not touching the reset line.

Is your reset line pulled up to chip Vcc, or somewhere else (slower)?

 

Good point, scope of reset line and IO is the best way to check start-up delays.

Also, pulse reset manually, and check the delay there too.  ( some MCUs have differing delays from POR to RST )

 

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

I ran a test with a tiny817 xplained mini. Set SUT to 0ms, set a pin first thing in main, no other code except normal minimal c runtime startup code for this simple app.

 

This was on a logic probe, threshold set to 2v-

from power on to updi pin high = 160us (that pin is only going to the mega32u4, so this is seeing the internal pullup being enabled)

from updi pin high to test pin high = 56us

so total from power on to test pin high = 216us

 

When SUT is set to 64ms, it is, so that seems to be working as it should (at least on the extreme edges I tested).

 

Since updi is in use, there is no reset pin. I would create an empty/simple project similar to the above test. Same fuse settings as the main project. Measure. If its the same, I guess you can probably rule out code, if it acts correct then you just need to check out the startup code in the main app from reset to wherever you determine the mcu is running.

Last Edited: Wed. Dec 4, 2019 - 03:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since updi is in use, there is no reset pin.

Well, it depends on how the testing is being done...If the programmer is disconnected & things set up to a normal config, there certainly is a reset pin action. 

It is probably best to remove the programmer, in case it (or one of its settings) is the culprit-- that would help to pin down the issue (programmer vs chip issue).

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

>If the programmer is disconnected & things set up to a normal config, there certainly is a reset pin action

 

The reset pin is set to updi, so there is no reset pin. You can hang a 100uf cap on that pin or pull it low, and it would make no difference except to prevent you from doing any updi programming.

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

 

If you are disconnecting the programmer & have set it to a normal configuration, then the pin becomes a reset pin...which can delay the startup.

If the programmer is still connected, then , yes it will be  UPDI...but you should get rid of the programmer to eliminate it as a contributor & have the reset pin per normal config.

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Wed. Dec 4, 2019 - 06:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm assuming since the fuse settings were shown to be using the reset pin as updi, that this is what is being used. It would be quite odd to be using the reset pin in either reset mode or gpio mode, and then be switching the fuse between updi and reset or gpio mode as there would be no need to do so since you would already have 12v capability, and could just leave it on whichever mode you wanted.

 

>If the programmer is still connected, then , yes it will be  UPDI...but you should get rid of the programmer to eliminate it as a contributor & have the reset pin per normal config.

 

The pin is functioning as per the fuse setting, and only the fuse setting, and does not change if a updi programmer is connected. If the fuse setting is set to updi, then the reset functionality is disconnected and there is nothing you can do to effect the ext reset (including keeping it in reset for any amount of time). If the fuse is set to reset mode, then you have reset pin functionality and will be using the 12v capability of your programmer to get updi to work (and you would also be prevented from hanging any caps on that line if you want updi to work).

 

I would guess, counter to the claim in the original post, there is something in the code that is causing the problem, assuming sut of 0ms is programmed correctly.

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

Hello, everybody. I am surprised about the intensive help here in this forum!

Today I generated a test program with Atmel Start and compiled it in AtmelStudio. Now the start time is at 300µs as expected. I haven't found the cause in the original CodeVisionAVR program yet, but it's clear now, that it depends on the code.

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

CV's CRT clears SRAM by default, does it not? With 2K, and a 5cycle loop (st X+ / cmp / cmp / brne), that's about 10K cycles.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

joeymorin wrote:
CV's CRT clears SRAM by default, does it not? With 2K, and a 5cycle loop (st X+ / cmp / cmp / brne), that's about 10K cycles.

 

That's it! Disabling the option "Clear Global Variables at Program Startup" in the C Compiler options leads to approx. 250µs start-up time. Thank you!

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

That's it! Disabling the option "Clear Global Variables at Program Startup" in the C Compiler options leads to approx. 250µs start-up time. Thank you!

And you thought you were in charge of the code!  CV was just playing you crying

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

avrcandies wrote:
And you thought you were in charge of the code!  CV was just playing you crying

Yes, and I knew that the RAM would be initialized in the startup file. But I didn't think this would take so long, stupid! frown

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

skysurfer243 wrote:
That's it! Disabling the option "Clear Global Variables at Program Startup" in the C Compiler options leads to approx. 250µs start-up time. Thank you!

While you now have a handle on the puzzling behaviour, think about the possible impact(s) of your "solution".  Using an option to change the laws of C could lead to more puzzles in the future.

avrcandies wrote:
And you thought you were in charge of the code!  CV was just playing you 

???

And other toolchains  don't have their own ways to implement C on an AVR?

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 guess you'd be OK as long as you assume any .bss are uninitialized - ie don't assume they hold 0. That will also go for char[] arrays and assuming you can strcat() onto them and stuff like that.

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

theusch wrote:
Using an option to change the laws of C could lead to more puzzles in the future.
The laws of C say nothing about zeroing all of SRAM, only setting to zero those variables which are global/static and are also uninitialised.

 

So in CV, even if I have only a single byte in .bss, my only choice for compliant C behaviour is to check "Clear Global Variables at Program Startup", which clears all of SRAM (2K on the t1616)?

 

I'd ask for my money back ;-)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Fri. Dec 6, 2019 - 03:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
I'd ask for my money back ;-)

I guess that would be your prerogative.  CV clears the WD at startup as well.  Oh, wait -- CV's null program is larger than a GCC null program.  So, GCC must be right, and WD shouldn't be cleared.  At the expense of those few words of code, the GCC people then post why their app mysteriously gets into a reset loop at startup.  Just as with clearing BSS ** one must eliminate any waste, *** even if the precautionary procedures are not "free".

 

Even though you get to your destination slower, you still take the time to fasten your seat belt even though the conditions you might need it are rare.

 

**

BSS

Bull Sh** Syndrome

God! Perry is such a liar! He totally has BSS!

***

MASH General Bartford Hamilton Steele  catchphrase is "Waste waste waste".

https://www.youtube.com/watch?v=...

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.