Back
[04:15:05] <madist> Tom_itx: microsoft has siezed your domain.
[04:15:19] <madist> *seized
[07:48:54] <inflex> Can you get a full stack wifi SoC these days? Something I can just do serial-in, wifi out?
[07:50:58] <wondiws> yes
[07:51:05] <wondiws> I had one
[07:51:23] <wondiws> something like WiFly it was called i think
[07:52:21] <inflex> nice... rough price?
[07:52:49] <inflex> aah, shield from Sparkfun $69
[07:52:57] <wondiws> that was probably it
[07:56:44] <wondiws> I was here yesterday with a question about my ATmega8-16pu chip on a breadboard, now I did get the wrong signature from it with my stk500 programmer
[07:57:39] <wondiws> I don't have a crystal at hand right now, is it possible to use an FPGA board to generate a clock to the avr chip on the breadboard?
[08:30:08] <RikusW> use the stk500 itself
[08:30:23] <RikusW> there are an onboard generator
[08:32:04] <wondiws> oh, it's not the real stk500 by the way
[08:32:22] <wondiws> I just use the stk500 switch in avrdude
[08:55:07] <RikusW> use an avr to generate a clock
[13:50:09] <Jordan_U> I was happily programming my ATMEGA64M1 via ISP using a JTAGICE3 when I decided to try debugwire. I selected debugwire in Atmel Studio, it said that the DWEN fuse needed to be enabled and asked if I wanted to do so, I said yes. At that point debugging failed, and now programming via ISP also fails. Debugging fails with "Atmel Studio was unable to start your debug session..." and ISP programming fails with "Failed to enter ...
[13:50:15] <Jordan_U> ... programming mode... Error status recieved Got oxc0, expected 0x00". How can I get at least programming to work again?
[13:52:52] <_abc__> You need a hv programmer to reset dwen
[13:53:47] <_abc__> Jordan_U
[13:54:56] <Jordan_U> _abc__: I should also be able to just get debugwire to work, then disable it via debugwire, correct?
[14:07:36] <_abc__> In theory. Iirc debugwire does something with the reset pin and any large capacitance on it or pullups downs will interfere. There's an app note somewhere Jordan
[14:08:14] <_abc__> Also fuses can't be reset via debugwire iirc
[14:13:37] <jonored> Getting some surprising results from an attiny2313A, trying to use the USI for SPI :
http://tcita.com/~jonored/program3.c when I send 100 0x01 bytes returns (after an expected block of 0x00 given that CS is the _RESET_ line, so it has to start up) 0x43 repeated over and over. If I don't set initialize, I get 0x01. I don't get the values changing beyond that. Any ideas? I'm feeding it SPI with a bus pirate at 125KHz.
[14:16:00] <_abc__> Framing error? 43 is 01000011
[14:16:31] <jonored> I initialize the variable to 42 when I initialize it at all.
[14:16:36] <_abc__> Wait, spi slave?
[14:16:48] <jonored> ...er, to 0x42, rather.
[14:16:54] <jonored> Yeah, trying to do SPI slave.
[14:17:24] * _abc__ can't see link on phone so is just opinating
[14:17:41] * jonored nods.
[14:20:52] <jonored> I'm basically trying to write an incrementing number out SPI slave, and I'm getting what I expect as the first number, and only that number - I've just been beating my head against this trying to get it to work so I can try to do what I actually was trying to get done.
[18:19:34] <Jordan_U> I still can't figure out why debugwire isn't working. Evernything seems fine (the wires are connected properly, I see changes on the reset pin on the oscilloscope when I attempt to start debugging), but it just keeps failing :(
[18:38:13] <Jordan_U> I'm trying avrdude to see if it get's me anywhere (at least a more helpful error message). What part number should I use with -p for an ATMEGA64M1?
[19:27:44] <Jordan_U> Could my problem possibly be solved by upgrading to Atmel Studio 6.2? I'm downloading it now and will try either way.
[20:07:50] <malinus> Jordan_U, man avrdude
[20:09:17] <Jordan_U> malinus: ATmega64M1 isn't listed in the available parts, only ATmega64, which avrdude claims doesn't support debugwire (leading me to believe that "m64" is not the correct option for my ATMega64M1, which does support debugwire).
[20:09:48] <Jordan_U> (I started with man avrdude, moved on to googling, then asked here).
[20:09:52] <Lambda_Aurigae> time to upgrade avrdude.
[20:10:14] <Lambda_Aurigae> and/or modify the avrdude config file to add the chip.
[20:10:20] <malinus> Jordan_U, oh that sound annoying. May I ask how you got such an "exotic" avr? Also maybe upgrage like Lambda said?
[20:11:11] <Jordan_U> malinus: We ordered it from digikey, it fits our requirements quite well (though we may not have chosen it had we known that it was "exotic").
[20:13:17] <Lambda_Aurigae> http://lucidarme.me/?p=3301
[20:13:28] <Lambda_Aurigae> you have to patch avrdude to support the atmegaXXm1 chips.
[20:14:22] <Lambda_Aurigae> and it looks like an update to the avrdude.conf file
[20:15:17] <jonored> (if anyone could take a glance at
http://tcita.com/~jonored/program3.c , I think I'm just missing something that should be obvious... attiny2313a trying to get an incrementing number out of spi with the usi as a slave.
[20:15:19] <Lambda_Aurigae> that page talks about the atmega32m1 but with some minor mods you can change that patch to the atmega64m1
[20:16:42] <Lambda_Aurigae> what is with the wdt_reset() in there? if your watchdog timer is disabled those shouldn't be needed.
[20:18:31] <jonored> I think I was uncertain the watchdog was actually getting turned off.
[20:19:21] <Lambda_Aurigae> you do wdt_disable() so it should be off.
[20:20:06] <Lambda_Aurigae> beyond that, you have 2 while(1) entries in sequence...with no way to skip out of the first one so the second is unnecessary.
[20:20:21] <Lambda_Aurigae> and I would have to read the USI docs to figure out what you are doing with it.
[20:21:03] <Jordan_U> Lambda_Aurigae: Thanks, though I'm more than a little warry of modifying avrdude.conf manually. One of the things I like about avrdude is that I have a (hopefully reasonable) expectation that it is configured properly to not do anything unsafe to my chip, and me mucking with the avrdude.conf might break that (and my chip).
[20:21:41] <Lambda_Aurigae> Jordan_U, if you don't muck with it then you won't be getting that chip working unless that chip is included in a new release of the software.
[20:22:11] <Lambda_Aurigae> I have version 5.11.1 from april 2013 and it's not included.
[20:23:06] <jonored> k. The behavior I'm getting is that I get 0x43 out (after a block of 0x00 while the chip starts up), at least if I have initialize set to 1.
[20:23:22] <Jordan_U> Lambda_Aurigae: Understood. I'll try poking around with Atmel Studio more and use manually modifying the avrdude.conf as a last resort.
[20:24:28] <jonored> ...Huh, which is inconsistent reasoning anyways, if it were reset related or something then it'd be delaying again.
[20:26:27] * Jordan_U might try http://lists.nongnu.org/archive/html/avrdude-dev/2010-02/txtNzYHxIZIvm.txt though.
[20:27:21] <Lambda_Aurigae> looks like the 6.1 version of avrdude supports your chip Jordan_U
[20:28:31] <Lambda_Aurigae> jonored, looking at the datasheet now to see what you are doing.
[20:28:50] <Jordan_U> Lambda_Aurigae: That's what I'm currently using and I don't see it listed from "-p ?".
[20:28:55] <jonored> Thanks very much!
[20:29:17] <Lambda_Aurigae> Jordan_U, well, it exists in the docs for 6.1...you might need to apply that patch you posted.
[20:31:00] <Jordan_U> Lambda_Aurigae: Where in the documentation?
[20:31:27] <Lambda_Aurigae> Jordan_U, don't remember...I just did a grep for the chip name and it showed up in the sources.
[20:31:36] <Lambda_Aurigae> already deleted it.
[20:32:57] <Lambda_Aurigae> jonored, you wanting to run this in master or slave mode?
[20:33:22] <Lambda_Aurigae> looks like slave mode from your code.
[20:33:37] <jonored> slave. it's plugged into a bus pirate, and I /think/ it's the same as the programmer pins..
[20:34:57] <jonored> ...would be really surprised by getting anything if it isn't.
[20:35:22] <Lambda_Aurigae> D0 and USCK pins both need to be set to output...you are only setting D0..
[20:36:13] <jonored> USCK is an output for slave mode?
[20:36:33] <Lambda_Aurigae> The code example
[20:36:33] <Lambda_Aurigae> assumes that the DO and USCK pins have been enabled as outputs in DDRA.
[20:36:42] <Lambda_Aurigae> just going by what the datasheet says there.
[20:36:44] <Lambda_Aurigae> page 160
[20:37:19] <Lambda_Aurigae> http://jaxcoder.com/Projects.aspx?id=280385176
[20:37:24] <Lambda_Aurigae> look through their code.
[20:37:31] <Lambda_Aurigae> although, that one uses interrupts on the slave.
[20:38:52] <Lambda_Aurigae> http://wiki.mcselec.com/bavr/index.php?title=Using_USI_%28Universal_Serial_Interface%29&redirect=no
[20:39:28] <Lambda_Aurigae> spi slave with usi about half way down the page.
[20:42:14] <Jordan_U> Lambda_Aurigae: It's listed as being a chip supported by the routing socket card STK600-RCPWM-22, not as being supported by avrdude :(
[20:42:31] <Lambda_Aurigae> Jordan_U, then apply the patch you found.
[20:43:03] <jonored> Thanks - that'll keep me chewing on it for a bit :) - hopefully I get to do the point after..
[20:43:04] <Lambda_Aurigae> either manually or with the patch command from the link I posted earlier for the atmega32m1
[20:46:47] <Lambda_Aurigae> aaand, I'm off to bed.
[22:38:25] <Jordan_U> Can I provide 12 volts to the RESET pin via a power supply, then program the ATMEGA64M1 using a JTAGICE3 connected normally to the rest of the pins?
[22:51:31] <Casper> HV programming, I am unsure if the same protocol is used...
[22:57:53] <Jordan_U> Alternatively, if someone can recommend a fusebit doctor that they expect will work with an ATMEGA64M1 I'm more than willing to buy one pre-made to get past this problem.
[22:58:52] <Casper> what is the actual issue you are trying to solve? wrong clock source?
[23:03:18] <Jordan_U> Casper: I had an ATMega64M1 working fine with Atmel Studio, programming it via ISP until I tried to use debugwire. Atmel Studio asked if I wanted it to enable debugwire, and even though I knew that would disable ISP I took the risk (which I now regret deeply) expecting that DebugWIRE would work, and that I could switch back to ISP programming and reset the fuse. DebugWIRE is failing, and I can't program via ISP because of the DWEN fuse.
[23:03:53] <Casper> ok
[23:03:58] <Jordan_U> Casper: I can't figure out why DebugWIRE isn't working. Getting DebugWIRE working would solve my problem as well.
[23:04:10] <Casper> not all programmer support DW
[23:04:29] <Jordan_U> Casper: The JTAGICE3 does.
[23:05:04] <Jordan_U> http://www.atmel.com/webdoc/jtagice3/jtagice3.connecting_debugwire.html
[23:10:17] <Casper> never used DW so can't say...
[23:10:34] <Casper> but could be something you could try
[23:11:04] <Casper> afaik, DW is an highish impedance output, so won't be an issue with reset getting 12V
[23:11:10] <Casper> at worse, it won't work
[23:12:05] <Jordan_U> Casper: I don't understand, what are you suggesting I try?
[23:13:09] <Casper> the 12V on reset
[23:31:47] <Dagger2> anybody use Windows + Eclipse + (avr-eclipse +) gcc 4.8 here? is this a thing I can get to work?
[23:32:21] <Jordan_U> The patch to the avrdude.conf failed to allow me to program the chip with avrdude. The configuration added by the patch doesn't include debugwire.
[23:32:37] <Dagger2> I'm trying it with the Arduino toolchain (which was updated to 4.8 about 5 days ago), but it's... not working so great
[23:34:13] <Dagger2> /usr/bin/avr-ld: cannot open output file CDC.o C;C:\Progra~2\Arduino\hardware\tools\avr\utils\Build\Arduino\hardware\arduino\avr\cores\arduino\CDC.cpp -v: No such file or directory <-- not the sanest error message ever...