AVR Freaks

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

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!

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 */

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

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.

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.