#avr Logs

Jun 29 2021

02:52 AM specing_ is now known as specing
04:06 AM twnqx: vmt: my mind is exploding with things to build, and the VCF stuff is actually just a project to find the source of an annoying, very low volume (inaudible over daytime sounds like birds), low frequency sound that keeps me from finding sleep at night, occasionally
04:07 AM twnqx: so low you can't hear where it's coming from.
04:39 AM Sponge5: Hi, I'm having trouble with .eep programming. I'm able to program it with a "base" firmware, however when I use a "full-featured" bigger one, I get "avrdude: verification error, first mismatch at byte 0x0008". I'm using -D option with avrdude when uploading new firmware, could that be a problem?
04:47 AM Sponge5: Ahh, according to here it IS a problem. https://tinkerlog.com/2007/06/16/using-progmem-and-eemem-with-avrs/
04:53 AM Sponge5: Aaaaand -V option for avrdude appears to be what I was looking for
05:44 AM SamantazFox_ is now known as SamantazFox
10:18 AM FozzWorth is now known as Guest2469
02:51 PM specing_ is now known as specing
05:43 PM evidlo: I'm having trouble communicating with my ATTiny85. Do these signals look right? https://imgur.com/a/eQ3rChW
05:43 PM evidlo: I'm using "avrdude -c usbasp -p ATtiny85 -P /dev/ttyUSB0 -U lfuse:r:-:i -v", but I get "target doesn't answer"
05:46 PM Phantom: for me, miso and mosi look suspicious
05:47 PM Phantom: or it's a scope display issue
05:52 PM evidlo: Here's the schematic
05:54 PM * evidlo uploaded an image: (88KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/zDJrSMvXkikMTSKLxLumMNVL/index.png >
05:56 PM evidlo: I'll try a bare chip with a SOIC clip
06:52 PM JanC_ is now known as JanC
09:26 PM rue_mohr: whats with the diode on vcc of the programming header?
09:27 PM rue_mohr: hmm I suppose programmer can power target..
09:27 PM rue_mohr: and, was there a pot connected when you tried to program?
10:38 PM evidlo: rue_mohr: no pot connected, but resistors were
10:38 PM evidlo: The diode is to prevent reverse current into the progrqmmer
11:34 PM Guest76 is now known as _ami_
11:43 PM evidlo: rue_mohr: Phantom: so if I set -B4 in avrdude it works
11:43 PM Phantom: long wire maybe?
11:44 PM evidlo: only about 12 inches
11:44 PM rue_mohr: thats up there
11:45 PM _ami_: evidlo which programmer are you using?
11:45 PM evidlo: is it possible there is some configuration mismatch?
11:45 PM evidlo: I'm using a chinese usbasp
11:45 PM evidlo: configuration mismatch between chip and programmer, with the SCK speed?
11:46 PM _ami_: i think it's probably due to fast clock speed of programmer. is your AVR running at low clock speed?
11:46 PM evidlo: I don't know. it's a virgin attiny85.
11:47 PM _ami_: https://github.com/amitesh-singh/FASTUSBasp
11:47 PM _ami_: https://github.com/amitesh-singh/FASTUSBasp#bit-clock-speed
11:47 PM evidlo: my programmer is based on atmega8
11:48 PM _ami_: yes, usbasp is based on mega8. i know. :)
11:48 PM evidlo: so what are you showing me with this link?
11:48 PM _ami_: that's why i wrote a better programmer for AVR.
11:49 PM evidlo: ah I see. I'm teaching a class of ~150 about AVRs, so I can't make dozens of programmers for it unfortunately
11:49 PM evidlo: I have to stick with the chinese programmers
11:50 PM Phantom: isn't virgin tiny85 at a very low speed by default?
11:50 PM _ami_: bluepill board is pretty cheap. < 2$ earlier.. i think its price is increased a bit recently.
11:50 PM Phantom: 1MHz it seems
11:50 PM _ami_: Phantom i think its 1 MHZ?
11:50 PM evidlo: Phantom: I don't fully understand the problem, but the default speed on these programmers is too fast?
11:51 PM Phantom: evidlo: it can be too fast
11:51 PM evidlo: why can't the programmer just keep trying slower and slower until it works
11:52 PM Phantom: why would it do that?
11:52 PM evidlo: also why is there even a preset speed? isn't the point of the SCK line to provide a clock?
11:52 PM Phantom: yes, but no
11:52 PM _ami_: evidlo you can't change mcu speed of AVR at run time.
11:52 PM Phantom: the sck does provide the data clock
11:52 PM Phantom: but the AVR need to be able to process the data
11:52 PM Phantom: if you send it too fast, it 'crash'
11:53 PM evidlo: so this usbasp is assuming I'm working with some more advanced AVR?
11:53 PM Phantom: nope
11:53 PM _ami_: No. it's just the speed mismatch
11:53 PM Phantom: it just default to a clock speed that work well for reprogrammation
11:53 PM _ami_: you can burn the fuses to increase the internal clock speed of attiny
11:54 PM Phantom: usually what you would do is use a slower clock speed to burn the faster fuses, then go default speed for the data
11:54 PM evidlo: yes, but why doesn't the attiny just use the external SCK clock during programming?
11:54 PM Phantom: it does
11:55 PM evidlo: then how can there be a mismatch
11:55 PM Phantom: but it need x amount of cpu clock speed to be able to process the SCK
11:55 PM Phantom: UART for example require 16 cpu clock for each bit
11:56 PM Phantom: at 15 it may or may not work, if it does it will be unreliable
11:56 PM evidlo: maybe they couldve clocked the cpu from SCK in programming mode
11:56 PM Phantom: nope
11:56 PM Phantom: the cpu clock need to be way faster than the SCK
11:57 PM Phantom: next time, flash the proper fuses at the slower speed first, then you can use the proper speed for data
11:57 PM evidlo: anyways, there seems to be a JP3 jumper on these programmers that slows down SCK
11:57 PM Phantom: as to why a programmer will not try the slower speed: each time you try to program, it use 1 write cycle out of the possible 10k cycles
11:58 PM Phantom: if it have to try 10 times, it mean that now you are at 1k cycles only
11:58 PM Phantom: plus, there is a risk of bricking the chip
11:58 PM Phantom: due to invalid data
11:59 PM evidlo: I'll just solder a wire into JP3 on all the programmers