I can program the ATtiny1634 with Arduino as ISP if I first set the fuse with AS7. But it is fairly clear the fuse is not set when I upload a sketch with Arduino as ISP. I noticed a folder for empty bootloaders so I am starting to think that is the trick, I have to write an empty bootloader to set the fuses. Is that correct?
Are you using my ATtiny1634 core, or a different one? ( GitHub - SpenceKonde/arduino-tiny-841: Arduino core for ATtny841, 828, 1634 and 441 or via board manager JSON in my sig)
If working through the Arduino IDE with a core (like mine) that supports the 1634, you need to choose the board and desired clock options, connect the ISP programmer, and do "burn bootloader" (even if you're not using Optibooot). This is the same as any other bare chip. "Burn Bootloader" does two things - it sets the fuses, and it writes the bootloader.
With my core, I've tested "Burn Bootloader" with Arduino as ISP and USBAsp for programmer through the IDE.
It can also be written using USBAsp + ExtremeBurnerAVR - but due to a bug (presumably in eXtremeBurnerAVR, since it doesn't impact the IDE?) I've found it necessary to manually hold reset low during the process (it must be released after each set of operations).
I have not programmed chips using Atmel Studio, so I can't comment on that, though I'd expect it to work.
Got it working.
I have a clone of arduino-tiny-841 in my Arduino/hardware folder, I am linking to it from my own hardware folder, where I have a boards.txt file. I link to your core with "build.core=arduino-tiny-841:tiny", but I was not clear on the fact that the bootloader was how the flags got set. So I ended up putting your empty bootloaders in my Arduino/hardware/RonS/avr/bootloaders as well. This is what my boards txt file now looks like, and seems to work.
# core is form https://github.com/SpenceKonde/arduino-tiny-841
# I cloned a fork of the repo in my Arduino/hardware folder
############################################################
RPUadpt.name=RPUadpt tiny1634 (8MHz, /w Arduino as ISP)
# Autoreset (DTR line) must be disabled on Uno and Mega for Arduino as ISP
RPUadpt.upload.protocol=stk500v1
RPUadpt.upload.maximum_size=16384
RPUadpt.upload.speed=19200
RPUadpt.upload.maximum_data_size=1024
RPUadpt.upload.tool=avrdude
RPUadpt.bootloader.tool=avrdude
RPUadpt.bootloader.unlock_bits=0x03
RPUadpt.bootloader.lock_bits=0x03
# 8MHz internal, 2v7 B.O.D. Enabled
RPUadpt.bootloader.low_fuses=0xE2
RPUadpt.bootloader.high_fuses=0xD5
RPUadpt.bootloader.extended_fuses=0x1D
RPUadpt.bootloader.file=empty/empty_all.hex
RPUadpt.build.mcu=attiny1634
RPUadpt.build.f_cpu=8000000L
RPUadpt.build.board=AVR_RPUadpt
RPUadpt.build.core=arduino-tiny-841:tiny
Aaaah, I see. Yeah. One of the stupid things about the process the IDE uses to do "burn bootloader" is that even if you don't want to write the flash, you need to give it a .hex file to write. AVRDude will error if you give it a .hex file that doesn't actually change the state of the empty board (ie, a .hex file that says to write nothing other than 0xFF), so you have to give it something to write, just to keep it happy.
Sad news, I changed my blink program and now AVR as ISP has problems (data on the tiny1634 is corrupt). I can grab the hex that Arduino hides and use AS7 to verify it was a bad upload and then load it correctly to see that it runs as expected, so the compiler and core are not the problems. I am using a level converter to go from a 5V UNO to a 3V3 tiny1634, that may be screwing up the SPI timing?
What's wrong with the data on the '1634?
Dump the flash contents - see if it's obvious what's wrong. A few "red flag" problems are only the first 128b (or 256) written (means it died when it tried to commit the first page), or "stripes" 32b long written, followed by 96b of blank, then another 32k (symptom of a bootloader that isn't aware of the 4-page erase behavior of the '1634 and '841). Or is it random garbage?
Does the upload fail in the IDE (with a verification error)?
Can you write the chip successfully through AS7 using same setup?
I have not tried using a level shifter... it's not a very useful level shifter if it doesn't work for this, though. I either program it at 5v, or use a 3.3v arduino to program (one of the nice things about using the bootloader is that once you do this once, you only need to get 3.3v serial adapter, and those are abundant.
I've attached the corruptReadback (some shown),
:100000000C9410000C9442000C9442000C9442009A
:100010000C9442000C9442000C9442000C94420058
:100020000C9442000C9442000C9442000C94420048
:100030000C9402000C9442000C9442000C94420078
and the hex that Arduino hides (some shown),
:100000000C9450000C9462000C9462000C946200FA
:100010000C9462000C9462000C9462000C946200D8
:100020000C9462000C9462000C9462000C946200C8
:100030000C948F000C9462000C9462000C9462008B
and the program (it just blinks)
/*
Blink on RPUadpt /w ATtiny1634 using arduino-tiny-841 core
Turns on an LED on for one-tenth second, then off for nine-tenth
second, repeatedly.
RPUadpt has an LED on PA4 (pin 4 with arduino-tiny-841 core) that you can control.
The led is connected to 5V through a 1.5k (^1+) resistor.
The tiny@3V3 is tolerant of 5V level when the pin is an input, but when set as an
output it will try to pull the led down to 3V3 which results in a dim LED that
should be off.
modified 16 Nov 2015
by Ronald Sutherland
*/
// the setup function runs once when you press reset or power the board
void setup() {
// LED pin is always low, it blinks by togling between INPUT and OUTPUT.
digitalWrite(4, LOW);
}
// the loop function runs over and over again forever
void loop() {
pinMode(4, OUTPUT); // turn the LED on by sinking current
delay(100); // wait for 1/10 second
pinMode(4, INPUT); // turn the LED off by making pin high impedance
delay(900); // wait for 9/10 second
}
Yes, the upload fails with a verification error.
Unfortunately, AS7 does not talk with the STK500v1 protocol so it won't run the Arduino as ISP tool, looks like only avrdude does. I have a dragon that works with AS7 (but not with avrdude, frustrating).
A bootloader would be nice, unfortunately, I need serial0 for a half duplex RS485 and the other serial port is shared with I2C hardware which I also want to use.
I need to look at the level shifter and sort out if it is the problem, I was hoping to use it between an off chip ADC and mega1284 as well but if this is a problem then...
Blink.ino (1.02 KB)
Blink.ino.hex.txt (2.62 KB)
CorruptReadback.hex.txt (45 KB)
eew.
Note that you can still use serial1 for the bootloader (the .hex images are included with the latest versions of my core), despite that that pin is used for I2C.
I had a situation where I wanted to use I2C and serial both during operation, but also wanted to use a bootloader, and couldn't use serial0 for it.
I put the FTDI header on Serial1, and then a jumper that could be removed to disconnect the shared pin (RX1/SDA) from the rest of the I2C bus. Worked great. Then one day I forgot to remove the jumper while there were a few I2C devices connected....
And it worked fine. Which, if you think about it, makes perfect sense. Who cares what-all SDA does, if SCL is staying high the whole time? There's the pullup on SDA, but that's fine, the idle state of a serial line is high anyway. So as long as none of your I2C devices get offended by random transitions of SDA while SCL stays high, you're fine.
That sounds good, it would be nice to have a serial debug port while I work through RS485 stuff as well.
Tried a Loopback test that looks OK at least from what I know about SPI. Got the SPI setting from Arduino as ISP (its an example in Arduino IDE 1.6.6). Lost as to why the ATtiny would get bad data with this.
and the SPI loopback program reports data sent without an error.
SPILoopback.ino (893 Bytes)
Some oddness is sorted out. Turns out the level converter was allowing Pin 10 from the Arduino side to float when the ArduinoISP sets it as an INPUT, which would normally allow the target reset to pull up if it were directly connected. I added a 10k pull-up on the input side. The floating pin caused some sporadic behavior that looked bad, but I don't think it caused any of the programming issues.
Another find is that erasing the tiny1634 with AS7 (dragon) allows a correct flash upload with ArduinoISP. So I guess the erase process is not happening.
I also updated the level converter board I'm using, I had done the edge connector pin-outs wrong.
ron_sutherland:
Some oddness is sorted out. Turns out the level converter was allowing Pin 10 from the Arduino side to float when the ArduinoISP sets it as an INPUT, which would normally allow the target reset to pull up if it were directly connected. I added a 10k pull-up on the input side. The floating pin caused some sporadic behavior that looked bad, but I don't think it caused any of the programming issues.
Another find is that erasing the tiny1634 with AS7 (dragon) allows a correct flash upload with ArduinoISP. So I guess the erase process is not happening.I also updated the level converter board I'm using, I had done the edge connector pin-outs wrong.
Aaah! well that would explain that much.
How were you writing it with ArduinoISP? If you were doing it from command line, did you forget the -e to erase the chip?
I am not using avrdude with CLI, just the Arduino IDE upload button, so a missing -e explains why it worked the first time and not after the change. The Arduino IDE runs avrdude like this:
E:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CE:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -pattiny1634 -cstk500v1 -PCOM3 -b19200 -D -Uflash:w:C:\Users\RSUTHE~1\AppData\Local\Temp\build54c162bcb382a9ad4dcc6202c2ef07ce.tmp/Blink.ino.hex:i
ouch, there is no erase cycle, the bootloader takes care of that... There is also not an upload.extra_params option so I added it to platform.txt and in boards.txt added "RPUadpt.upload.extra_params=-e" (remember my boards.txt, I would not so see post #2)
Now it is acting like I want: the program can be changed and then uploaded without errors.
So now it is time to move past blink, the level converter between 5V ArduinoISP and 3V3 tiny1634 is happy.
Recap: add pull-up on pin 10 to level converter input and add an option to erase, which the (not used) bootloader would normally do.
I'll investigate the erase issue. I almost never program without the bootloader, it is possible there is an issue with my core - programming via ISP without the bootloader should work.