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:
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?
This is the rise time of the VCC:
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.
And there is no code that is responsive for the delay.
How do you know? Is this C? Assembly?
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.
But I see a start-up time of 4ms @16MHz and 3,3ms @20MHz
>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).
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)?
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 )
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.
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).
>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.
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.
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.
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.
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] |
 |
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!
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 
And you thought you were in charge of the code! CV was just playing you
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! 
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.
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?
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.
Using an option to change the laws of C could lead to more puzzles in the future.
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] |
|
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.
**
***
MASH General Bartford Hamilton Steele catchphrase is "Waste waste waste".
