Back
[04:04:13] <mux_> abcminiuser, I need you! :P
[04:04:48] <mux_> well, if you're available that is
[04:05:17] <Valen> help me abcminiuser you're my only hope?
[04:05:49] <mux_> seems a bit dramatic on second thought, but yes
[04:18:37] <mux_> alright, different problem, maybe somebody can help me with this
[04:18:48] <mux_> the interrupts in my bootloader don't seem to work
[04:21:49] <Roklobsta> mux_: have you tried turning it off and on again?
[04:22:09] <mux_> of course, I'm in IT
[04:22:18] <Roklobsta> just checking.
[04:22:21] <Roklobsta> me too
[04:23:01] <Roklobsta> i play devils advocate and ask to see if your global interrupt is on?
[04:23:07] <Roklobsta> SEI
[04:23:10] <mux_> yes
[04:23:15] <mux_> I should note, this is on an xmega
[04:23:30] <Roklobsta> oh poop i don't have one of those.
[04:23:42] <Roklobsta> no one here can help you. we only deal with attiny's.
[04:23:45] <mux_> they're not super-different from other avrs
[04:23:47] <mux_> heh :P
[04:25:03] <Roklobsta> DMA
[04:25:24] <mux_> they have some awesome features that make life very easy like DMA, yes
[04:25:43] <mux_> and a proper interrupt controller and much better usb and etc. etc.
[04:26:18] <mux_> but at least as far as this bootloader crap is concerned they shouldn't be too dissimilar
[04:26:49] <mux_> the reason I was asking Dean is because I'm trying to adapt his mass storage bootloader to xmega
[04:28:02] <mux_> it compiles now (with a modified boot.h) but it doesn't seem to fire any interrupts
[04:30:47] <Roklobsta> maybe it's a damp squid.
[04:32:47] <mux_> :D
[04:32:57] <mux_> everybody has blind spots
[04:36:27] <mux_> omg, I never knew that a simple interrupt service routine had that much boilerplate assembly
[05:03:09] <abcminiuser> Wha?
[05:03:23] <abcminiuser> Dang, totally forgot XChat doesn't do the Windows flashy thing
[05:08:48] <mux_> abcminiuser hey
[05:08:53] <mux_> xchat, fancy
[05:09:04] <abcminiuser> Yeah I'm a young'n
[05:09:18] <mux_> so, I put xmega support into boot.h
[05:09:20] <abcminiuser> Could have sworn it used to pulse the entry on the Win7 taskbar
[05:09:51] <mux_> bit of a pain as boot.h was written before good c compilers apparently, and it's all a mess of uncommented asm
[05:10:12] <abcminiuser> Some bits are cycle dependent on some devices
[05:10:30] <mux_> they are, but the timing requirements are pretty loose and it seems to work from C
[05:10:51] <mux_> although there is no macro for the spm instruction and some other stuff, so I still needed to put in volatile inline asm in some places
[05:11:01] <mux_> anyway
[05:11:24] <mux_> it compiles now, no guarantee that it works but the first problem I encounter is interrupts not working, or at least it seems like they don't work
[05:12:12] <mux_> it definitely boots into bootloader mode, it executes the hardware setup, I redirected the interrupt table to the bootloader section using PMIC.CTRL |= PMIC_IVSEL_gc; and the appropriate CCP call
[05:12:26] <mux_> know what, I have to double check that
[05:14:48] <abcminiuser> Yeah, check the CCP timing
[05:14:59] <abcminiuser> Also check you've relocated the binary to the right address in the makefile
[05:16:10] <evil_dan2wik> abcminiuser, I use hexchat (based off xchat) and there is an option under alerts in preferences.
[05:17:04] <mux_> oh, I'm using atmel studio, I'm used to porting your stuff to there
[05:17:04] <abcminiuser> And now the damn taskbar pulses, go figure
[05:17:27] <abcminiuser> mux_, OK, in that case it's a linker configuration in the project settings
[05:17:54] <mux_> yeah, but I already have confirmation that the code is in the right place because it does actually run
[05:18:11] <mux_> if I do non-interrupt based stuff (e.g. flashing a LED with _delay_ms's in between) it works
[05:18:39] <mux_> I think my problem is indeed the CCP call, I need to find it in the .lss to see what happens
[05:18:49] <abcminiuser> Assuming the compiler itsn't making nice relative jumps everywhere...
[05:19:35] <abcminiuser> Try XMEGACLK_CCP_Write() from LUFA/Platform/Platform.h
[05:24:38] <mux_> oh, I was already using asf, but if it's in lufa I'll use that
[05:24:39] <mux_> thanks
[05:27:26] <abcminiuser> Either one
[05:27:49] <mux_> your one is a lot nicer actually
[05:28:11] <mux_> the ASF version has a bajillion lines of register-saving stuff that isn't necessary for me
[05:31:33] <mux_> no, that wasn't the problem
[05:48:36] <mux_> well, that's all the time I had to fiddle with this, thanks for the pointers abcminiuser
[09:15:21] <specing> After a long time I'm again doing avrs
[09:15:31] <specing> and C/C++
[09:15:43] <specing> u32 current_time = 0;
[09:16:02] <specing> avr/main.c:117:2: warning: left shift count >= width of type current_time += (1 << 16);
[09:16:14] <specing> but when replaced with += 65536, it doesen't warn
[09:16:16] <specing> wtf
[09:44:18] <dunz0r> specing: Do share some code on some paste-thing.
[10:03:37] <rewolff1> specing: 1 is an int (16 bits). Leftshift it 16 bits and you get zero.
[10:03:58] <rewolff1> 65536 MUST be a long (32 bits) because it is longer than an int.
[10:04:01] <rewolff1> any int.
[10:07:45] <rewolff1> Specing, Just compiled: return a + (1 << 16);
[10:07:45] <rewolff1> and it compiles to: "ret".
[10:08:20] <specing> ypedef uint32_t u32;
[10:08:25] <rewolff1> return a + (1L << 16); -> adiw r24,1
[10:08:26] <rewolff1> return a + 65536; -> adiw r24,1
[10:08:56] <rewolff1> (the first has a warning, the last two don't, and compile as expected).
[10:09:55] <specing> uint32_t is long enough to accomodate 1<<6
[10:09:59] <specing> 16*
[10:19:22] <specing> avrdude: error: no usb support. Please compile again with libusb installed.
[10:19:32] <specing> /o/
[10:23:09] <twnqx> even uint8_t :P
[10:23:17] <twnqx> oh wait
[10:23:30] <twnqx> i thought you corrected that 32->16, not the 6->16 :P
[10:46:24] <specing> Bus 003 Device 007: ID 03eb:2104 Atmel Corp. AVR ISP mkII
[10:46:53] <specing> What to do with this? my svr scripts seem to expect avrdude: Error: Could not find USBtiny device (0x1781/0xc9f)
[10:47:07] <specing> I remember modifying avrdude.conf
[10:47:12] <specing> but with what?
[10:47:19] <twnqx> well
[10:47:25] <specing> grrr so much RAM lost
[10:47:28] <twnqx> probably the -p line?
[10:47:39] <twnqx> given you have a mkii and not a usb tiny...
[10:48:08] <specing> I have something I flashed on a ATmega8u2
[10:48:35] <twnqx> if it identifies as a mkii, it's a mkii
[10:49:02] <twnqx> repalce usbtiny with avrispmkII
[10:49:32] <twnqx> (is that really you, specing? you normally don't sound this helpless :P)
[10:50:31] <specing> I haven't done AVRs for atleast a year now
[10:50:44] <specing> It feels like Im freshly starting
[10:52:52] <specing> avrdude: stk500v2_recv_mk2: error in USB receive
[10:52:53] <specing> ugh
[11:04:42] <rewolff1> Specing: uint32 is long enough for 1 << 16, but the math is done (according to C-spec) as "int" by default. So 1 is an int. 16 is an int, so it calculates (1 << 16) in an int (16 bits) and comes up with zero.
[11:05:09] <rewolff1> So the function f1(uint32 a) { return a + (1 << 16);} compiles to "ret".
[11:06:07] <specing> right.
[11:08:18] <MrMobius> cant you do 1u<<16 to fix that?
[11:08:20] <MrMobius> or 1ul
[11:09:16] <twnqx> i would have expected that works, yes...
[11:09:42] <twnqx> on an unrelated note
[11:09:53] <twnqx> why are there so few compilers with 128bit ints.
[11:10:16] <MrMobius> just guessing, because there are so few numbers that really need to be that big?
[11:11:02] <twnqx> but how do you detect a 64bit overflow without 128bit maths!
[11:11:40] <twnqx> and also get reliable results, given that the C standard does list results of overflows as "implementation specific", so any value is ok
[11:11:48] <MrMobius> carry bit in your cpu?
[11:12:12] <MrMobius> oh, from a C perspective
[11:14:06] <specing> twnqx: you asm check the overflow bit ;p
[11:14:21] <MrMobius> specing, thats what I said!
[11:14:22] <specing> (that I do remember, not that it help me currently)
[11:15:43] <specing> https://paste.debian.net/hidden/95d2c0f8/ likely cause?
[11:16:17] <twnqx> missing -P usb
[11:16:32] <twnqx> no rights for the user to access raw usb devices
[11:16:38] <twnqx> > debian
[11:16:57] <Thrashbarg> sudo
[11:17:03] <specing> avrdude: stk500_send_mk2(): failed to send command to serial port < why is it communicating with serial port if the thing is on USB?
[11:17:16] <twnqx> because you gave no -P usb
[11:19:58] <specing> https://paste.debian.net/hidden/90214355/ now with -P usb.
[11:20:25] <Thrashbarg> sudo it
[11:20:38] <specing> Thrashbarg: SUBSYSTEM=="usb", ATTR{idVendor}=="03eb", ATTR{idProduct}=="2104", GROUP="users"
[11:21:38] <Thrashbarg> specing: is it chmod 664?
[11:21:44] <specing> stat /dev/bus/usb/003/010
[11:21:50] <specing> Access: (0664/crw-rw-r--) Uid: ( 0/ root) Gid: ( 100/ users)
[11:22:04] <specing> but yeah, will try root
[11:22:05] <Thrashbarg> and group says you're in the users group
[11:22:27] <Thrashbarg> (always good to check IMO)
[11:22:52] <specing> Nope, same error
[11:23:11] <Thrashbarg> well it fails the sanity check :)
[11:23:41] <specing> ?
[11:23:54] <Thrashbarg> never mind
[11:25:03] <Thrashbarg> I imagine lsusb shows it too
[11:25:05] <specing> Well the device enumerates
[11:25:10] <Thrashbarg> yeah
[11:25:22] <specing> so the errors could be on the other side
[11:25:23] <Thrashbarg> I'm out of ideas then... but then I haven't been trying for long
[11:25:26] <Thrashbarg> yeah
[11:25:29] <specing> maybe I wired MISO/MOSI wrong
[11:25:34] <specing> or reset is not triggering
[11:25:37] <specing> or -.-
[11:25:52] <Thrashbarg> etc etc been there... lots of fun
[11:27:03] <specing> its like USB, you can never get MISO/MOSI right the first time
[11:27:12] <Thrashbarg> yup
[11:27:22] <Thrashbarg> four dimensional properties
[11:28:16] <Thrashbarg> it's always wrong until you try it the third time
[11:29:20] <specing> though the errors sound like the problem is on the usb side of things
[11:29:30] <specing> but I think it has always been that way
[11:33:26] <specing> avrdude: stk500v2_command(): failed miserably to execute command 0x03
[11:33:29] <specing> Mwhahaahaha
[11:33:32] <specing> "miserably"
[11:34:24] <specing> RESET is pulldown, so I stuck a LED there that got lit up 2s after I started avrdude
[11:34:30] <specing> so its probably miso/mosi
[11:37:14] <specing> Nope, wasn't that
[11:37:23] <specing> hrrrmbl
[11:39:24] <specing> Or maybe the programmer spec is wrong?
[11:48:38] <specing> Why can't I find avrusbmkII vid:pid pairs in avrdude.conf?
[12:02:33] <specing> grrrr
[12:02:45] <specing> can't even read signature bytes
[12:24:20] <specing> How fast is the avrispmkii clock supposed to be?
[12:24:24] <specing> the data clock
[12:29:41] <specing> There doesen't seem to be anything given out the programmer's SCLK or DO pins
[12:53:03] <Tom_itx> specing depends where you set it
[12:53:09] <Tom_itx> iirc 250khz is default
[12:53:24] <N1njaneer> 125khz
[12:53:29] <Tom_itx> yeah
[12:53:48] <N1njaneer> Less than 1/4 of standard clock, which is generally 1Mhz internal for Atmel devices from the factory
[12:53:57] <N1njaneer> Hi Tom!
[12:54:31] <Tom_itx> you can go up quite a bit as long as you stay crystal/4 below the crystal
[12:55:15] <specing> not even -B 10 helped
[12:55:31] <N1njaneer> Or you just use the 125Khz, set the clock to whatever you are using, then kick the ISP clock up a lot higher. Pretty much a requirement if you are needing to production-program any serious quantity of larger-capacity devices.
[12:55:41] <specing> I probed the spi lines with a scope and it seems like there is no activity there
[12:56:02] <N1njaneer> specing: Do you have voltage supplied from the target to the programmer?
[12:56:19] <specing> only some noise and the voltage varies by abour 0.2V
[12:56:26] <specing> N1njaneer: supplied by programmer
[12:56:42] <N1njaneer> specing: Which programmer? Hardly any should every do this, as it's bad practice.
[12:56:49] <N1njaneer> None of Atmel's programmers will.
[12:56:55] <N1njaneer> +ever
[12:57:47] <specing> N1njaneer: my hacked up avrispmkii from LUFA
[12:58:19] <N1njaneer> Reason being is the target might run anywhere from 1.8V - 5.5V, and the programmer needs to know what voltage levels to drive. Plus your device might require 10ma or 10A to function correctly, and the programmer cannot guarantee enough power to successfully power up your device correctly.
[12:59:04] <N1njaneer> specing: If it's not a known good programmer, then you're kind of on your own :)
[12:59:55] <N1njaneer> There's many things that could prevent it from working.
[13:00:11] <specing> N1njaneer: its just an avr on the protoboard
[13:00:29] <specing> And it worked a year ago lol
[13:00:34] <N1njaneer> But if you are not seeing any clock signal or such on the ISP lines, probe as far up the chain as possible to where they are being generated in the programmer and see why it's not working.
[13:01:16] <N1njaneer> specing: You need to either have a virgin AVR, an AVR guaranteed to be set to internal clock, or be supplying it with external clock as per the clock fuse settings. Else even if you send ISP signals at it correctly you won't get a response.
[13:07:17] <N1njaneer> Hopefully that helps :)
[14:58:02] <specing> The programmer should pull reset high, right?
[14:58:09] <specing> It doesen't.
[15:00:32] <specing> https://paste.debian.net/hidden/4ef6f0b7/
[15:17:31] <specing> MISO/MOSI/SCLK/SS all dead
[15:17:56] <specing> could the chip be dead
[15:18:47] <specing> the programmer chip, that is
[15:25:41] <N1njaneer> Anything is possible I suppose..
[15:26:03] <N1njaneer> Without a schematic and knowing specifically what you are trying to do it's difficult to make additional suggestions
[15:41:29] <specing> I'll roll dasa out and connect to it
[16:08:03] <specing> damnit
[16:08:07] <specing> dasa ain't working either
[16:21:51] <specing> I can see communication
[16:21:54] <specing> but nothing back
[16:23:47] <specing> On the SCK pin
[16:25:35] <specing> and data on DI
[16:25:39] <specing> but nothing on DO
[16:32:14] <specing> I would have expected these problems with PICs, but not AVRs :/
[16:33:31] <jadew> specing, reset is active low
[16:33:57] <jadew> so the programmer will drive it low, while the MCU will pull it high (internally)
[16:37:44] <specing> Yeah, seen it
[16:38:23] <specing> so, my observations@dasa: puts reset low, I can see bitbang on DI and SCK
[16:38:27] <specing> DO is dead
[16:38:37] <specing> So maybe
[16:38:42] <specing> avrdude is broken
[16:38:46] <jadew> do you have a proper clock?
[16:38:54] <specing> I have a bitbanged one
[16:38:56] <jadew> what chip is that?
[16:38:59] <specing> tiny45
[16:39:09] <jadew> did you program it before?
[16:39:17] <specing> yes, more than a year ago
[16:39:28] <jadew> ok
[16:39:50] <jadew> now, do you have a crystal connected to it? or maybe an external clock (actual clock for the mcu, not the SPI clock)
[16:40:03] <specing> nope
[16:40:06] <jadew> maybe you set the fuses to use an external clock
[16:40:18] <jadew> in which case you can't program it with out one
[16:40:18] <specing> doubt it, tiny only has 6 pins
[16:40:33] <jadew> doesn't matter, you can still have a crystal on it
[16:40:35] <specing> whatever I was doing I would probably be dry on pins
[16:40:41] <jadew> you may have simply missconfigured it
[16:40:47] <specing> I know you can, but I doubt I would have done it
[16:41:09] <specing> maybe
[16:41:28] <specing> or maybe I actually did change it to use a crystal
[16:41:32] <specing> I don't remember
[16:41:42] <jadew> then just feed a clock to it and try it again
[16:42:13] <specing> k, will have to solder some wires though
[16:43:32] <Tom_itx> tiny54 is 6 pin?
[16:43:36] <Tom_itx> 45...
[16:43:43] <jadew> I think it's 8
[16:43:48] <Tom_itx> me too
[16:43:54] <jadew> but 6 usable
[16:43:57] <jadew> - reset
[16:43:58] <jadew> so 5
[16:44:03] <Tom_itx> the only 6 pin i'm aware of are the tiny4 5 9 & 10
[16:44:33] <jadew> yeah, I have a bunch of 10s around here, never used them
[16:44:42] <jadew> just thought they're cute and that I may need them someday
[16:45:06] <jadew> it's been almost 3 years since then
[16:45:10] <Tom_itx> for a 4 (useable) pin chip, it's pretty powerful
[16:45:27] <Tom_itx> 16bit timer, adc, pwm etc
[16:45:41] <Tom_itx> 12Mhz internal osc
[16:45:42] <jadew> I just didn't find an application for it
[16:45:56] <Tom_itx> they blink leds really nice
[16:46:02] <jadew> haha
[16:54:32] <specing> cool
[18:04:51] <specing> k soldered
[18:16:24] <specing> WORKIGN!
[18:16:31] <specing> OAWJDFPAGWHOAHPAWIGHCVNAIVNHAWOIFBNAWIN WOOOHOO
[18:17:48] <evil_dan2wik> specing, set it on fire
[18:19:12] <specing> not an option for the only working programmer
[18:19:19] <specing> inspecting fuses now
[18:21:18] <specing> (H:FF, E:D7, L:EE)
[18:21:23] <specing> this can't be right
[18:21:43] <specing> it says serial program download (==ISP) is disabled?!
[18:22:54] <specing> Oh I see, hfuse is E: and efuse is H:
[18:22:56] <specing> obvious.
[18:23:17] <Casper> of course
[18:23:23] <Casper> why make it simple when you can do complex?
[18:29:20] <wondiws> I fucked up the fuses on one of my MCU's
[18:29:37] <wondiws> basically 0xff ff
[18:29:56] <wondiws> now with all the programming options disabled, how can I change the fuses?
[18:30:02] <wondiws> is only High Voltage programming left?
[18:30:11] <megal0maniac> Yip!
[18:30:32] <wondiws> megal0maniac, what was that?
[18:31:09] <Lambda_Aurigae> he got nipped in the bud by the obvious chicken.
[18:31:26] <megal0maniac> Only hvpp left
[18:31:41] <megal0maniac> That is sad for you. I'm sorry
[18:31:55] <wondiws> is that not doable then?
[18:32:05] <megal0maniac> It's totally doable
[18:32:10] <megal0maniac> Just a pain
[18:32:20] <wondiws> it needs to be 12V?
[18:32:23] <wondiws> not 5V?
[18:32:52] <megal0maniac> I see smoke in your future
[18:33:22] <wondiws> If you mean what I think you mean, that's not good news
[18:33:24] <megal0maniac> Only the reset pin is 12V tolerant. You need a programmer that does this, though
[18:33:30] <megal0maniac> Google. There are loads of examples
[18:33:48] <Lambda_Aurigae> fusedoctor.
[18:34:03] <Lambda_Aurigae> it will reset your chips to factory default fuses using hvsp and/or hvpp.
[18:34:45] <megal0maniac> wondiws: Or talk to RikusW when he's back here. He makes a programmer which does hvpp
[18:34:55] <megal0maniac> I have 2 of them. They're great
[18:35:15] <wondiws> I need a new programmer?
[18:35:22] <megal0maniac> which one do you have?
[18:35:36] <wondiws> I have the mySmartLight
[18:35:40] <wondiws> a USBASP
[18:35:45] <megal0maniac> Then yes
[18:35:51] <wondiws> I can bit-bang on the parallel port
[18:36:07] <wondiws> what about breadboard?
[18:36:17] <megal0maniac> Dude...
[18:37:10] <Lambda_Aurigae> usbasp is not capable of HVSP or HVPP...it would take a total software rewrite for it.
[18:37:15] <Lambda_Aurigae> along with some hardware changes.
[18:37:19] <specing> jadew: you were right, it was configured for crystal
[19:26:33] <specing> all AVRs are responding to DASA
[19:26:53] <specing> now to find the programmer firmware and verify it
[19:32:16] <specing> Which is ofcourse nowhere to be found
[19:33:08] <timemage> http://picpaste.com/pics/14834d28df56783a0b4431b91ccb22d8.1407888655.png - i've already sent this to atmel. so far, no response. maybe someone here to tell me what i'm messing. this in the attiny841 pinout as shown in the current datasheet. trying to figure out why some of the pins share labels.
[19:33:19] <Tom_itx> specing, it's right there where you left it..
[19:34:22] <specing> avrdude: ERROR: address 0x2010 out of range at line 513 of /home/specing/./store/programmer/LUFA-110528-BETA/Projects/AVRISP-MKII/AVRISP-MKII.hex
[19:34:26] <specing> so much for that lol
[19:34:40] <specing> thats what I get for buying the lowliest low chip available >_>
[19:35:56] <Tom_itx> ?
[19:36:06] <Tom_itx> are you using a lufa alike programmer?
[19:36:09] <specing> atmega8u2
[19:36:15] <specing> yeah, avrispmkii
[19:36:21] <Tom_itx> too small for that one i think
[19:36:26] <specing> I barely squeezed it in
[19:36:35] <specing> nah, older gcc compiles it under 8k
[19:36:44] <specing> is what I've been told
[19:36:55] <specing> now I just need to find the hex that I flashed onto that sucker
[19:37:13] <Tom_itx> i've got it on my site if the pinout is the same
[19:37:40] <specing> will look
[19:37:48] <specing> not sure if pinout is the same though
[19:38:04] <specing> probably doesen't matter because MISO/MOSI/SS/SCK pins are on the same spot
[19:38:16] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_index.php
[19:39:44] <Lambda_Aurigae> is not responding from here Tom_itx
[19:40:04] <Tom_itx> http://tom-itx.ddns01.com:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_index.php
[19:40:07] <Tom_itx> that one will
[19:40:12] <specing> nah, board is totaly of my design
[19:40:18] <Lambda_Aurigae> that works.
[19:40:27] <specing> Lambda_Aurigae: the first one worked for me
[19:40:30] <Tom_itx> specing, it should use the same hardware pins
[19:42:46] <specing> yeah
[19:42:59] <specing> Im gonna die of old age before DASA finishes download
[19:43:12] <Tom_itx> haha
[19:52:35] <specing> avrdude: error opening /tmp/o1: No such file or directory
[19:52:46] <specing> it tells me that after 10 mins of download >_>_>_>_>_>
[20:31:08] <specing> https://paste.debian.net/hidden/ecfae629/
[20:31:16] <specing> Not sure if read errors or foobar or both
[20:34:06] <Lambda_Aurigae> doesn't look good.
[20:34:18] <Lambda_Aurigae> multiple reads result in the same thing or different data each time?
