Atmel Startup Code Bug

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

Seems like there is another bug in the startup code for the Attiny Series 1 Attiny1616.

 

This snippit of code from mcu_init claims to put the ports into low power mode. That would mean disabling the input buffers.

 

    /* On AVR devices all peripherals are enable from power on reset, this
     * disables all peripherals to save power. Driver shall enable
     * peripheral if used */

    /* Set all pins to low power mode */

#define PORT_PULLUPEN_bp  3

    for (uint8_t i = 0; i < 8; i++) {
        *((uint8_t *)&PORTA + 0x10 + i) |= 1 << PORT_PULLUPEN_bp;
    }

What it actually does is enables the pullups on all the ports which is the opposite of low power mode. Correct me if I'm wrong here. I'm getting momentary enabling of all my ports and it seems this is the cause.

This topic has a solution.
Last Edited: Sun. Apr 5, 2020 - 08:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would have to look at teh datasheets(not able to at the moment), but I seem to recall somewhere that enabling the pullups actually lowers the power of teh micro as opposed to leaving pins floating. 

 

Hopefully someone here has the datasheet in front of them and can check this

 

JIm

 

EDIT:

This is a rather "Unusual/confuding" snippet:

 /* On AVR devices all peripherals are enable from power on reset, this
     * disables all peripherals to save power. Driver shall enable
     * peripheral if used */

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Sat. Apr 4, 2020 - 02:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps that was true of a different micro and this code does not belong in the Attiny series-0 or series-1.

 

The data sheet says the following;

 

16.3.1 Initialization
After Reset, all standard function device I/O pads are connected to the port with outputs tri-stated and
input buffers enabled, even if there is no clock running.
Power consumption can be reduced by disabling digital input buffers for all unused pins and for pins used
as analog inputs or outputs.
Specific pins, such as those used for connecting a debugger, may be configured differently, as required
by their special function.

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

dnoyeB wrote:

The data sheet says the following;

 

16.3.1 Initialization
After Reset, all standard function device I/O pads are connected to the port with outputs tri-stated and
input buffers enabled, even if there is no clock running.
Power consumption can be reduced by disabling digital input buffers for all unused pins and for pins used
as analog inputs or outputs.
Specific pins, such as those used for connecting a debugger, may be configured differently, as required
by their special function.

Yes, if you disable the input buffers.  Says nothing about the pullup resistors, and as long and the port pins are set as inputs there is no real current flowing.  If the port pins are set as OUTPUTS and the pullups are enabled then you will have some current flow if the pins are driven low.

 

Also from teh datasheet:

To reduce power consumption, these input synchronizers are not clocked if the Input Sense
Configuration bit field (ISC) in PORT.PINnCTRL is INPUT_DISABLE. The value of the pin can always be
read, whether the pin is configured as input or output
 

So when you did the configuration in START did you disable the synchronisers?  I admit I do not know if you can/how you can do this in START.  

 

 

We had another thread where someone though START had a bug in it because of the way it set up a port, but it turned out the OP in that thread wanted something else at startup than what START did.  Keep in mind that START is not perfect.  Nothing is.  But without seeing how you configured START, this will turn into a long thread of back and forth with no real answer.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Fundamental, the software should never be setup to momentary activate ALL the IOs by way of a pull up. That can't be right. A pull up affects the external circuit. I agree this is "Start" code so it may not be perfect for my application. But this just seems unnecessary and wrong. All my IOs get positive voltage/current for minimum ~50μs at startup.
By changing the code to do what it says it's doing, everything works perfectly.
My config has the IO set as output and initially low. It didn't do advanced config for this port. But to be clear Start is doing this to all ports as an initialization step before it considers the requested configuration.

I posted a different Start question about a week ago. That one was asserting a 0 at startup because the port direction was set before the port value was set. Reported and acknowledged.

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

dnoyeB wrote:
I posted a different Start question about a week ago. That one was asserting a 0 at startup because the port direction was set before the port value was set. Reported and acknowledged.

 

Ahhh so that was your thread I was thinking of.

 

 

As I wrote in that thread:

It's just the way you want things is different than the way START does things.

Can you set the startup conditions you want the ports to be at in START?  I don't remember.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

No, its not possible to get this to work just by changing the START configuration. At least not as far as my experimentation has shown.

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

jgmdesign wrote:

Can you set the startup conditions you want the ports to be at in START?  I don't remember.

 

Jim

dnoyeB wrote:

No, its not possible to get this to work just by changing the START configuration. At least not as far as my experimentation has shown.

 

Yes it is possible as seen from a project that I did a couple of years ago.  PINMUX is your friend.

 

"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

Oh Larry, you are still with us. cheeky Send you an email a while ago to check up but got no reply, maybe the email address is no longer any good.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

It's possible to set the configuration. It's not possible to get Start to stop asserting pullups initially on every IO.

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

In the effort to help you I just built a new ATtiny1616 Start project using the 1.4.308 ATtiny_DFP with just an empty while(1) loop in main.c.

 

I connected a logic analyzer to all the I/O pins and set it to trigger on both high or low transitions on any of the pins.  Result on startup, or a forced reset: no changes or glitches on any of the pins.

 

I then changed main.c and made some pins outputs that change state, then only looked for triggers on the remaining unassigned pins.  Result: no changes or glitches on any of the pins.

 

I also tested the same on that previous project I mentioned above and got the same results: no transitions at startup.

 

It may be something that you are setting up in your code, or it may be that you do not have decoupling caps on the circuit, that are causing the ~50 uS transition that you are seeing.

 

I recommend that you start looking at your board or your code. Start appears to be working just fine. 

 

Good luck!

 

 

"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: Sun. Apr 5, 2020 - 12:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks @larryvc for the effort. Do you by chance see the above cited code in your project?

I setup a simple Start project for the ATtiny416 since I have the xplained board. Here is a scope shot of the port startup and the config.

 

StartConfig ATtiny416XplainedStartupIO

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

Here I changed the default to High in the Start configurator.  Now you can see both bugs.

 

  1.  Bug #1 the port initially goes high due to the pull up being set.
  2.  Bug #2 the port's direction register is set to output before its OUT register is set causing the port to go to low since the OUT register contains a 0.
  3.  The port's OUT register finally gets the default configured value bringing the output back to a 1.

 

StartupIO

Last Edited: Sun. Apr 5, 2020 - 12:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just fired up START and created a simple 3 outputs 'application'.  Here is what I have in my pinmux:

 

All three pin are teh same configuration.

 

Here is my setup code that START generated:

/* PORT setting on PA0 */

	// Set pin direction to output
	Jims_test_0_set_dir(PORT_DIR_OUT);

	Jims_test_0_set_level(
	    // <y> Initial level
	    // <id> pad_initial_level
	    // <false"> Low
	    // <true"> High
	    false);

	/* PORT setting on PA1 */

	// Set pin direction to output
	Jims_test_1_set_dir(PORT_DIR_OUT);

	Jims_test_1_set_level(
	    // <y> Initial level
	    // <id> pad_initial_level
	    // <false"> Low
	    // <true"> High
	    false);

	/* PORT setting on PA2 */

	// Set pin direction to output
	Jims_test_2_set_dir(PORT_DIR_OUT);

	Jims_test_2_set_level(
	    // <y> Initial level
	    // <id> pad_initial_level
	    // <false"> Low
	    // <true"> High
	    false);

And thats it.  No mention of pullup resistors.

 

Where in your project is that snippet from your OP?  Can yu zip up the START project export and post it so we all can take a look at the code, and the START GUI?

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

I believe you are showing code from system_init(). The first line of that function should call mcu_init(); If you look in mcu_init() you should see the offending code.

 

void system_init()
{
	mcu_init();

	/* PORT setting on PA2 */

	// Set pin direction to output
	TestOut_set_dir(PORT_DIR_OUT);

	TestOut_set_level(
	    // <y> Initial level
	    // <id> pad_initial_level
	    // <false"> Low
	    // <true"> High
	    true);

	CLKCTRL_init();

	CPUINT_init();

	SLPCTRL_init();

	BOD_init();
}

 

Last Edited: Sun. Apr 5, 2020 - 02:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unfortunately I am getting a bunch of errors when I try to build teh project:

 

So I cannot run the simulator until I figure this out, and right now its late and I have something else to work on so I will look in teh morning.  But if Larryvc says hes not having the issue, there must be something missing in all of this.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

dnoyeB wrote:
Thanks @larryvc for the effort. Do you by chance see the above cited code in your project?

 

Yes, mcu_init() in system.h called from system_init() in driver_init.c etc...  

 

Now that we are on the same page as to what is being measured, comparing to the waveform in post #13,  on my scope I saw the voltage ramp up at startup but I did not see the low going spike.

 

I disabled the call to mcu_init and compared the waveform received to what I would expect at startup and it was as it should be, a nice clean glitch free startup. 

 

Now, I am also convinced that setting PULLUPEN for the ports as is done in mcu_init() is definitely incorrect.  What might have been the Microchip intention, as noted in dnoyeB's OP, was for for mcu_init() to disable all of the port pins' input buffers instead, that would have conserved power as was intended.

 

dnoyeB, this needs to be reported to Microchip.  Please file a bug report with them. 

 

P.S. I am having this strange feeling of deja vu with regard to this issue, like I might have brought it up before...  (Perhaps meolsen is listening)

 

The code below is what system.h should be doing, at least for the startup IO port initialization, fully tested, works great.  The comments could use some cleaning up.

 

/**
 * \file
 *
 * \brief Tiny System Related Support
 *
 (c) 2018 Microchip Technology Inc. and its subsidiaries.

    Subject to your compliance with these terms,you may use this software and
    any derivatives exclusively with Microchip products.It is your responsibility
    to comply with third party license terms applicable to your use of third party
    software (including open source software) that may accompany Microchip software.

    THIS SOFTWARE IS SUPPLIED BY MICROCHIP "AS IS". NO WARRANTIES, WHETHER
    EXPRESS, IMPLIED OR STATUTORY, APPLY TO THIS SOFTWARE, INCLUDING ANY IMPLIED
    WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY, AND FITNESS FOR A
    PARTICULAR PURPOSE.

    IN NO EVENT WILL MICROCHIP BE LIABLE FOR ANY INDIRECT, SPECIAL, PUNITIVE,
    INCIDENTAL OR CONSEQUENTIAL LOSS, DAMAGE, COST OR EXPENSE OF ANY KIND
    WHATSOEVER RELATED TO THE SOFTWARE, HOWEVER CAUSED, EVEN IF MICROCHIP HAS
    BEEN ADVISED OF THE POSSIBILITY OR THE DAMAGES ARE FORESEEABLE. TO THE
    FULLEST EXTENT ALLOWED BY LAW, MICROCHIP'S TOTAL LIABILITY ON ALL CLAIMS IN
    ANY WAY RELATED TO THIS SOFTWARE WILL NOT EXCEED THE AMOUNT OF FEES, IF ANY,
    THAT YOU HAVE PAID DIRECTLY TO MICROCHIP FOR THIS SOFTWARE.
 *
 */

/**
 * \defgroup doc_driver_utils_mcu_init MCU Init
 * \ingroup doc_driver_utils
 *
 * \section doc_driver_system_rev Revision History
 * - v0.0.0.1 Initial Commit
 *
 *@{
 */

#ifndef SYSTEM_INCLUDED
#define SYSTEM_INCLUDED

#include "ccp.h"
#include "port.h"

#ifdef __cplusplus
extern "C" {
#endif

void mcu_init(void)
{
    /* On AVR devices all peripherals are enable from power on reset, this
     * disables all peripherals to save power. Driver shall enable
     * peripheral if used */

    /* Disable all port pin digital input buffers. No need to |= as we do not need
        or want to invert the pin logic or enable the pullups during initialization*/

    for (uint8_t i = 0; i < 8; i++) {
        *((uint8_t *)&PORTA + 0x10 + i) = PORT_ISC_INPUT_DISABLE_gc;
    }

    for (uint8_t i = 0; i < 8; i++) {
        *((uint8_t *)&PORTB + 0x10 + i) = PORT_ISC_INPUT_DISABLE_gc;
    }

    for (uint8_t i = 0; i < 8; i++) {
        *((uint8_t *)&PORTC + 0x10 + i) = PORT_ISC_INPUT_DISABLE_gc;
    }
}
#ifdef __cplusplus
}
#endif

#endif /* SYSTEM_INCLUDED */

 

"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: Sun. Apr 5, 2020 - 08:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the confirmation larryvc, I'll put in the bug report.

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

dnoyeB wrote:

Thanks for the confirmation larryvc, I'll put in the bug report.

Kindly let us know the status as it slowly flows through the Microchip mill...

"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 entered the case 00509791.  It is not well received.  I'm being told the pins are supposed to be pulled up based on an application note http://ww1.microchip.com/downloads/en/Appnotes/AN2515-AVR-Low-Power-Techniques-00002515C.pdf

I think that is fine to do with unused pins but not used pins. And no real comment about the fact that the code isn't doing what it claims to do; Deactivate the input buffers.

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

I get what they are saying in the App Note, but it should be the responsibility of the programmer to insure that unused pins are pulled up!

 

Microchip should not be activating the pullups in the Start initialization!  Deactivating the input buffers would be fine in the Start initialization.

 

If anyone at Microchip is listening please take a closer look at what is being discussed in this thread.  You want us to use Start, fix it.

 

Don't glitch my port pins with your incorrect code!

 

 

Perhaps Microchip are more interested in forcing us to use MPLAB-X instead and are not willing to spend $ to make things right in Start.

"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. Apr 10, 2020 - 12:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

larryvc wrote:
Perhaps Microchip are more interested in forcing us to use MPLAB-X instead and are not willing to spend $ to make things right in Start.

 

Your learning.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

dnoyeB, Please go back to your bug request and reject the resolution.

 

I have submitted follow up case  00511387, 'Atmel Start startup code bug', for the new ATtiny/ATmega series to address the issues we are seeing on our production hardware.

"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

Hopefully this will get resolved soon as it affects all Start based projects using AVR0 and AVR1 series devices.

 

Received this in response to my case 00511387: 

 

Hi Larry,

 

Thank you for contacting Microchip Technical Support Team.

 

We hope you are doing good and safe!

 

I apologize for my misunderstanding in case 00509791.

 

I misunderstood the case core issue. I assumed that the issue was about “ /* Set all pins to low power mode */” comment and power consumption with pull-up enabled.

 

From this description and shared AVR freak link, I understood the issue in Atmel START void mcu_init(void) port initialization code for new AVR0-1 series devices.

 

Because of this wrong initialization(enabling pull-up for all the port pins by default), code generates momentary high pulse/glitch on PORT pins.

 

We have reported this issue to our internal team with your test results mentioned in the freak comments #12, #13 and #17.

 

Thank you for taking the efforts to report this bug to us. It really helps us to make our START bug free and helps other customers not getting into a similar issue.

 

 Once again, my apologies for the misunderstanding caused in the previous case.

 

Best Regards,

Mahalakshmi.

 

"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