#avr | Logs for 2016-03-03

Back
[04:59:13] <flyback> https://www.youtube.com/watch?v=IvUU8joBb1Q
[05:39:51] * twnqx just found a 4bit µC from atmel...
[05:40:03] <h4x0riz3d> wat
[05:40:14] <twnqx> atmel t6020m
[05:43:03] <flyback> 4 bit is still used in low low end stuff
[05:43:21] <flyback> mostly all 8 bit now but I have a nicd/nimh charger that has a 4 bit uc
[05:57:40] <h4x0riz3d> hmz
[05:58:02] <h4x0riz3d> the chips in the RFID might be 4 bit too..
[05:58:41] <julius> hi
[05:58:50] <h4x0riz3d> and iirc atmel had some of those, read/write-able
[05:59:00] <lorenzo> just got a AT91SAM9G20 dev board :D
[08:16:39] <daey> what advantage do 4bit µCs have over their 8bit counterparts?
[08:17:20] <daey> im guessing you can shrink the die size even further because the logic parts only need half the space?
[09:46:50] <aczid> can anyone think of a way to let avr-ld link my flash code in such a way that it can skip over a (supposedly) broken flash page?
[09:47:41] <aczid> i got a verification error from avrdude at flash addr 0x100, a chip erase doesn't fix the problem, so I'm guessing the flash is really broken :(
[09:48:03] <aczid> and I don't have a spare device...
[09:48:44] <liwakura> iirc there were some things to place code at certain places
[09:49:08] <liwakura> as long as the interrupt table is still functional
[09:49:14] <aczid> yeah luckily it is
[09:51:39] <liwakura> look into --section-start=.text=0x0200, thats where the arduino bootloader is written to
[09:51:55] <liwakura> if you have results, i'd like to know
[09:53:22] <Casper> aczid: also, be sure to have a stable supply, and short wires. that the lock fuses are not set and that you are not trying to flash too fast for the chip clock
[09:55:36] <aczid> thanks
[10:05:59] <aczid> that worked, but now my verification error starts at 0x300!
[10:06:06] <aczid> something else must be up :)
[10:29:59] <aczid> ok, it's something to do with my programmer
[10:30:45] <aczid> I was using a recently updated usbasp without issues on other AVRs, but not this atmega64. programming and verification works fine when I use the dragon programmer
[10:31:01] <aczid> thanks for the help, I think I found the related USBASP issue too https://savannah.nongnu.org/bugs/index.php?41561
[10:37:15] <h4x0riz3d> my usbasp was NEVER verifying even tho the code was there when you did a flash dump with the same usbasp
[10:45:26] <cehteh> usbasp doesnt verify .. you have to tell avrdude to do so
[10:51:13] <flyback> https://www.youtube.com/watch?v=IvUU8joBb1Q
[10:57:57] <aczid> yeah the offending byte was actually programmed it seems, and came back out when I dumped flash to binary
[11:01:09] * flyback sinks his teeth deep into aczid'S LEG meat
[11:01:18] <flyback> how about that for a offending byte bitch
[11:01:34] <flyback> :P
[11:25:28] <aczid> flyback: as long as I can still have my ARMs :P
[11:26:04] <aczid> yak shaved, and I got done what I wanted to in the avr firmware :)
[12:48:54] <NTQ> Hi I have a Atmel AVR Xplained Mini Board and somehow I write the wrong fuse bits to the atmega168pa. I can not enter programming mode. Is it possible to revive the device?
[12:50:12] <LoRez> NTQ: do you know what you wrote to the fuses?
[12:51:31] <NTQ> LoRez: We tried to flash the bootloader from the Arduino IDE without further adjustments. Then AVR studio was no more able to recognize the device.
[12:52:16] <LoRez> or you put a bad bootloader on it?
[12:52:41] <LoRez> the fuses are very specifically away from the programming area for the bootloader (or the rest of program memory for that matter)
[12:53:39] <NTQ> So the bootloader alone could be the problem?
[12:54:25] <LoRez> yeah, if you're depending on the bootloader to write new code to it. Are you trying to program it via serial/usb or ICSP?
[12:54:51] <NTQ> I tried the onboard programmer and an external AVR ISP programmer.
[12:55:30] <LoRez> to recover it you'll probably have to use the external ISP programmer. You may have to provide a clock to the chip as well.
[12:56:50] <NTQ> Okay, I will try to figure out where I can connect an external clock.
[12:58:26] <LoRez> Worst case, high voltage programming would be required.
[13:00:13] <NTQ> I read about this but it seems to be highly complicated with that board without unsoldering the chip.
[13:02:29] <LoRez> yeah, you'd have to put it into the programmer to do so.
[13:04:04] <NTQ> But its a MLF package with 32 pins.
[13:04:28] <phinxy> Why is atmega's so sensitive to interference.. Is there a circuit somewhere that shows how to make it insulated in a noisy environment?
[13:06:21] <phinxy> nope. its always the hard way. got to learn everything inside out to get anywhere
[13:11:08] <LoRez> NTQ: that's a pain. Easier to just get another MLF and reflow it.