SpeedyCraftah / avr-pico-programmer

A programmer for the AVR architecture microcontroller, specifically the ATTiny84A by Microchip, for the Raspberry Pi Pico.
6 stars 1 forks source link

Voltage? #1

Open alexnagelberg opened 10 months ago

alexnagelberg commented 10 months ago

I tried everything you have listed and ran in to the same thing you listed on the README -- that running at 3.3v didn't work. Just wondering -- why does it need 5v? I don't see anything in the datasheets about it and the attiny84 should support >= 1.8v (I've run the chip itself at 3.3v directly, just can't program it with this).

Something I saw somewhere: someone mentioned the current drawn by signals will pull as much as it can and I'm wondering if that is the issue somehow, not the voltage, and by pulling from VSYS instead of 3v3 out, it's not affecting anything. I know the 3v3 out on the pico has about 2-300mA available and the GPIO may have only 20 or so mA.

Anyway just wanted to put this out there and see if there was any way to do this because I'd really really like to run this stuff all at 3v3! Thanks!

SpeedyCraftah commented 10 months ago

Hey Alexander,

I had the same exact thought when I first attempted to enter programming mode using 3.3V - since the documentation states that it only needs +1.8V at the minimum I thought this wouldn't be an issue, nor was it ever an issue for projects similar to this I've done in the past.

I can only imagine it's because Microchip overlooked this detail when writing their documentation since they usually have their own proprietary programmers for programming their microcontrollers (I believe it involves turning an Arduino Uno into a programmer using their SDK which features 5V GPIO pins) or making use of existing ones - the engineer I was speaking to also emphasized the fact that I should be using their official programmers as they do not support 3rd party hardware/code; but comes the question why even include a section on serial programming if we're only supposed to be using their tools?

I don't exactly know the hardware reason for this or the minimum voltage that's required to program the controller (I suspect you can get away with +-1V when programming) but I can only imagine it may be potentially because the dedicated hardware for programming the controller (temporary flash buffer/processor/program memory) may require slightly more power especially since the communication over SPI on it's own may be drawing some power, and the whole process may be voltage driven as opposed to current, but I'm not a qualified electrical engineer, at least yet!

Your current draw theory may very well be true though; but then the GPIO pins are not exactly designed to power anything (although you can get away with powering an LED), I believe they are mostly to be used as logical switches for things like transistors and communication protocols, where a high amount of current is not required, the logical 1s and 0s (3V3 and 0V) just need to be distinguishable, so I don't think the current itself may be the issue, it may just be a weird quirk in the engineering process of this chip.

I would recommend you to play around and try find another solution to this potentially and maybe share notes, but as far as I know you would either need to use a 5V capable controller or use my method of converting the voltage levels between the SPI pins (these converters are extremely cheap and can even be made easily with own components like transistors, but I opted in for a pre-made PCB to simplify the process).

alexnagelberg commented 10 months ago

It definitely has to be possible. I currently have some cheap usbasp programmer that runs 3v3 and even the microchip datasheet includes the steps for serial programming (unless this programmer uses a different method somehow). The programmer is not proprietary, unless they have different ways of flashing the chip across the 16 pins, and these documents may even be older than Arduino itself (the Atmel days).

GPIO pins are definitely not designed to power anything, which is why there could be an issue if current isn't limited and the AVR is clumsy. Again I don't know exactly what is going on there, but I could see there being some properties of having a level shifter that would prevent brown outs or detectors to trip by taking the power externally and driving the signal. I'm going to experiment a bit with this by using transistors with an external power supply and give it different voltages.

My reason for pushing getting 3v3 working has to do more with the design of the board I'm making rather than cost -- the QFN package of attiny is incredibly small, which goes out the window with adding shifters and plus the chip needs to operate on 3v3 in my design after being programmed, so that would add extra complexities to this board (basically I'm designing something where the rp2040 and attiny84 are working together with a special programming mode where a user can connect and flash both chips through the rp2040 and then they operate their respective firmwares communicating with each other after programming).

I appreciate the fast reply and research on this. If I crack this I'll update with my findings.

alexnagelberg commented 10 months ago

I got it! It may be as simple as a pull-up but I added 270R across reset, MOSI, and CLK as well a 10k pull-up from reset to 3v3. I think it's the pull up mainly and the level shifter may have acted as one on reset but it doesn't hurt to put them across the signals.

Here's the schematic for the ASP based programmer I used on my attiny with arduino: https://www.fischl.de/usbasp/ (runs at 3v3 and 5v).

SpeedyCraftah commented 10 months ago

That is very interesting - thank you for sharing!

I did not do much experimentation with trying to run off of 3.3V since I've gone through enough attempts to get it working and was happy to see it work with the logic shifter and my lack of electrical engineering knowledge, but it is interesting to see that it can be done.

I will try to replicate this to see if it does indeed work when I have time - it is quite disappointing to see that Microchip made no real effort to document this or at least mention this in the documentation, probably since selling their hardware and programmers is more lucrative.