AVR128DA28 appears to lock up at boot

[TylerK07]

I've been scratching my head on this one for a while. Basically when I first power on the micro, it seems to lock up. I have an activity LED that's fed from PORTD, pin 7, and it turns on as soon as the micro powers on. My setup function SHOULD turn it off... but if the AVR is locked, then it stays on. From there, I can press reset a bunch of times and it will eventually turn off and then everything works fine from there on.

Couple of things:
• This only happens when power is first applied to the AVR
• After a successful reset (need to press many times), I can continue pressing RESET and it resets and works properly.
• Even when in the "locked up" state, I can still program the AVR through the UPDI port

I can't decide if this is a hardware or software issue. It never happened before and then started suddenly several months ago. Is it possible something changed in DXCore? Any starting point/direction to troubleshoot this would be greatly appreciated!

If it's helpful to peek at the code, it's actually all on GitHub here:
https://github.com/TylerK07/YM3812-Module/tree/master/Articles%208/YM3812_Velocity

Thank you kindly!

[ogbreaks]

Can I check Tyler - instead of pressing many times - can you repeat the following. Turn on power to the module. Wait at least 30 seconds. Then press reset button. Does this reset the module first time?

[ogbreaks]

As a side note - I found that I needed to set the reset button function on pin 18 (PF6) of the AVR128DA28 as it was defaulted to a regular in/out pin (gpio) or 0. This meant it did not work at all to begin with. I needed to set this via my programmer before uploading the code to 2 . I set this manually on fuse5 and so the settings on that fuse are as follows:

#Fuse syscfg0/fuse5 value 0xc8 (factory 0xc0) mask 0xed

config eesave=eex_erased # 0
config rstpincfg=rst # 2
config crcsel=crc16 # 0
config crcsrc=nocrc # 3

This now works as expected with the added complication of the power up (30 second) freeze. I'm thinking this could be hardware related and getting into some testing hopefully this week.

[ogbreaks]

Ok, after a few hours of debugging tonight I have solved the problem here @TylerK07 Tyler. Without a better understanding of the chip architecture I cant give a definitive reason why its happening but I have a suspicion this is an interrupt or sleep/idle mode issue on the AVR128AD28 controller. It is code related and is a result of a problem with the .ino file and simply solved by banging on an i/o port of the AVR128 right before the YM3812 reset procedure:

void setup(void) { PROC_YM3812.reset();

with eg:

void setup(void) {
  checkFlashA();
  PROC_YM3812.reset();`

where the function checkFlash simply hits up an i/o pin