AVR runs reliably after programming, won't after power cycle - Page 1
Forum section: electronics / general

author: Dan Moos
author_rank: Frequent Contributor
timestamp: March 15, 2025, 03:20:52 am
content: atmel 1284p. Using an old AVR Dragon, with Microchip studio.Using the mcu to manage keyboard and sd card duties for a 6502 homebrew computer. AVR talks to the 6502 through a 6522 VIA I/O chip.If I program the AVR, it seems to work reliably. If I then power cycle it, it hangs when doing a specific data transfer function. If i reprogram it, all is well. As long as I don't powercycle or reset the AVR, things work great. Even unplugging the programmer (I'm using JTAG) doesn't stop it from working. Seems to no matter what optimization settings, or if I'm buiding debug or release.I'm using the avr's internal 8 MHz clock. I'vbe tried seting the the divide by 8 fuse, to see if slowing the chip down helps, but I get the same behaviour.What happens when I program the chip, that changes after a reset? The failing code does involve manipulating/listening to handshake signals with the 6522. But my keyboard routines, which depend on the same handshaking work fine.

author: brucehoult
author_rank: Super Contributor
timestamp: March 15, 2025, 03:30:31 am
content: Are you sure you initialise all global variables, and the state of all I/O pins you use? There could be something you need that programming does but you're not.Also maybe add a delay to let things in the system settle before trying communication. Maybe 10ms, maybe 100ms .. but a second wouldn't hurt for test purposes.

author: pcprogrammer
author_rank: Super Contributor
timestamp: March 15, 2025, 07:20:25 am
content: Quote from: brucehoult on March 15, 2025, 03:30:31 amThat is what I'm thinking too. Maybe your code reacts to some signals of the 6502 part and goes of in the code to mystery land, that does not happen when the 6502 system is stably running.What happens if you keep the AVR in reset during the power cycling and release it once the 6502 system is stably running?

author: Dan Moos
author_rank: Frequent Contributor
timestamp: March 15, 2025, 04:07:56 pm
content: I should elaborate as to why I don't think this is a setup time issue. (Although I'm still opene to it.The functionality that is failing is my "dir" command. I'm implementing FAT32 on the SD caed, doing all the heavy lifting on the AVR. The other job of the MCU is PS/2 keyboard interface. That part works perfectly.So In my start up sequence for the whole shebang, bothe the MCU and CPU are powered simultaneously, but I do have a 250ms delay as my first line of code fore the MCU. The MCU and CPU both have a separate serial connection to my pc, so I can monitor the startup. I then run my keyboard setup code and my sd card setup code, with the various milestones involved documented on the serial terminal. Concurrently, the CPU is doing its setup stuff, which is pretty short and sweet. Just setting up registers in a few chips.I can't interact with the computer until the MCU has finished its initialization of keyboard, SD card. Importantly, the MCU displays the boot sector data (via serial terminal) of the SD card, which takes time, and at least shows that communication is solid.Intotal, there is about 4 seconds from cold start before I can type anything, and before the cpu has to interact with the MCU. And its not until the first keystroke that they talk at all.At this point, keyboard functionality, which uses the same handshaking and same I/O port as the "dir" routine works no matter what. Its only when I type "dir" (following a hard restart) that it crashes. So it can be minutes before the mcu and the cpu have to interact, and it still happens. I'm confident it isn't a setup time issue.

author: pcprogrammer
author_rank: Super Contributor
timestamp: March 15, 2025, 05:06:36 pm
content: To recap:Ok, so this "dir" command makes things crash, but only when the system power cycled, or the MCU is reset.When it is in this crashed state, you attach your JTAG programmer and write the code again to the FLASH of the AVR based MCU. This means that the MCU restarts the program and when that is up and running you can execute the "dir" command and it all works fine.Does it also "crash" when you try another command, like opening a file known to be on the card?The interfacing with the CPU seems to always work, because you say that the keyboard communication has no problems. The question here is if this is bidirectional communication or just one way from the MCU to the CPU?Very difficult to diagnose what is wrong without the full picture. A schematic of the setup would be helpful, in respect to how the AVR is connected to the 6522 VIA, and of course a peek into the source code that runs on the MCU.Are you using a known FAT32 implementation, or did you write it yourself?You see lots of questions that can be asked on a problem like this, and since for as far as I know there is no real crystal ball that reveals everything you do, that we can use to investigate, the answers have to come from you.

author: Atlan
author_rank: Frequent Contributor
timestamp: March 17, 2025, 07:56:28 am
content: Pullup rezistors on SDcart wires installed?

author: ajb
author_rank: Super Contributor
timestamp: March 17, 2025, 03:45:40 pm
content: Since you're already using JTAG, have you tried using the debugger to see exactly where the data transfer function is hanging? It's been a while since I worked with AVRs but it should be possible to power the target up and then connect while it's running ("Attach to target" or "Start Debugging and Break" in Microchip Studio) without doing a program cycle. It should even be possible to start the debug session after it's hung and see where it's ended up, which may be necessary if debugging disrupts the MCU's interactions with the CPU.My guess is that the programming cycle is zero-filling some memory that isn't normally initialized by your startup code. You could try dumping memory after a normal startup and a post-programming run and comparing to see areas are different. Or attack this from the code side of things, and start adding sanity/null-checks to every object the dir command touches. But using the debugger will be the fastest way to narrow this down.

author: electronix27
author_rank: Contributor
timestamp: March 18, 2025, 05:01:56 pm
content: I've used the ATmega 324PA, which is very similar (same family) but much smaller flash, eeprom and ram. Maybe this is a bit rudimentary, do you use a 10k pull-up resistor from reset pin 9 to VCC and 100nf capacitor between pin 10 VCC and GND. Usually I place the capacitor right between pin 10 and 11 (GND). This can make a difference and maybe why chip starts ok with programmer. Once programmed the programmer should return the reset pin to a high state.EDIT: If you are using brown out, you may also want to try setting slightly lower, 4.2 maybe, in fuse configuration settings.

author: mikerj
author_rank: Super Contributor
timestamp: March 18, 2025, 07:01:28 pm
content: Is it possible to attach the debugger in the crashed state to see the instructions being executed? Are there any busy loops in the AVR code that don't include any a timeout or maximum loop iteration counter?

author: pcprogrammer
author_rank: Super Contributor
timestamp: March 18, 2025, 07:42:03 pm
content: Quote from: electronix27 on March 18, 2025, 05:01:56 pmThe OP mentioned using an old AVR Dragon and not a home brew board, so most likely reset and power are up to specs.https://www.microchip.com/en-us/development-tool/atavrdragon

author: electronix27
author_rank: Contributor
timestamp: March 19, 2025, 01:31:03 am
content: The AVR Dragon is a programmer, debugger.

author: pcprogrammer
author_rank: Super Contributor
timestamp: March 19, 2025, 06:56:57 am
content: Quote from: electronix27 on March 19, 2025, 01:31:03 amOops.I should have read the product page more thorough.

author: GromBeestje
author_rank: Frequent Contributor
timestamp: March 19, 2025, 11:30:54 am
content: Rather then looking at the AVR to 6502 link, may the problem be between the AVR and SD card?Do you have pull up resistors on the SD card lines? Having them float during power up potentially causes issues.An SD card boots up int o SD mode and needs to be switched to SPI mode. If the nCS line ain't kept high before you start talking to it, this might fail.Furthermore, from past experiences SD cards may be rather slow initialising. Try waiting a whole second just to be sure.

author: ajb
author_rank: Super Contributor
timestamp: March 19, 2025, 02:36:58 pm
content: Quote from: electronix27 on March 19, 2025, 01:31:03 amThat sure isn't the impression the product page or manual give...Quote