#avr | Logs for 2015-11-24

Back
[00:58:28] <m4t> http://www.avrfreaks.net/forum/fuse-programming-error solved
[00:58:43] <m4t> 0xFD = 0x05 since only the last 3 bits are used, apprently
[01:01:07] <Xark> m4t: Cool. I was thinking this might be the case, but wasn't sure (so didn't speak up).
[01:01:59] <Xark> m4t: I think I got bit by that too (but I just switched to AVR Studio and AVRISP-USB).
[01:12:06] <Haohmaru> could it be a problem that my PDI cables are kinda long? about 35cm.. avrispmkii, xmega32a4..
[01:13:37] <Xark> Haohmaru: Maybe, but that doesn't sound too long. Perhaps slow down programming clock?
[01:16:10] <Haohmaru> how?
[01:16:38] <Haohmaru> i tried -B50 but it doesn't appear to actually change anything
[01:17:59] <Xark> Are you using avrdude?
[01:18:06] <Haohmaru> yez
[01:18:07] <Xark> Try -B1 :)
[01:18:22] <Xark> ...or is that fastest (I forget)
[01:18:37] <Haohmaru> still nope
[01:18:58] <Xark> Does it kind of work? Or just not work at all?
[01:19:31] * Xark has only been able to use his AVRISPmkII from AVR Studio (not avrdude).
[01:19:51] <Xark> (I think avrdude only works with old firmware or something)
[01:20:33] <Haohmaru> well i hooked up this stuff in friday, changed the firmware of the programmer and had to install older version of avrdude (5.10) and since i hooked up the xmega - i've not got any sign of life from it
[01:20:47] <Haohmaru> the programmer acts as if there's nothing connected
[01:21:03] <Haohmaru> same errors if the cable is disconnected
[01:21:19] <Xark> Interesting. Do you have windows and can try AVR Studio?
[01:21:28] <Haohmaru> i do have windows
[01:21:50] <Xark> Might be worth a try...
[01:21:59] <Haohmaru> haven't ever tried avr studio
[01:22:00] <Xark> (but it is a big download if you don't have it). :)
[01:22:08] <Haohmaru> ouch
[01:22:40] <Xark> It is pretty much Microsoft Visual Studio with avr-gcc compiler, assembler, debugger, simulator and programmer. Also does ARM, AVR32 etc.
[01:23:25] <Haohmaru> tbh i am okay with my setup.. CodeBlocks avrgcc avrdude..
[01:23:26] <Xark> A nice environment to develop in (if you like IDEs). Ships with Visual Assist even ($100 add-on to give you "code completion of the gods" etc.).
[01:23:45] <Xark> Yeah. Same compiler pretty much.
[01:24:23] <Xark> Maybe there is just a programmer component (but I think only integrated into AVR Studio).
[01:24:39] <Haohmaru> how does avrstudio program the stuff?
[01:25:00] <Haohmaru> ah, avrdude is not a tool by atmel, right
[01:25:27] <Xark> No, open source I believe.
[01:25:45] <Xark> It has a GUI and supports *every* AVR chip etc.
[01:25:51] <Xark> (or damn near)
[01:25:59] <Xark> Also XMega, ARM etc.
[01:26:16] <Haohmaru> i saw avrdude even supports pickit2 o_O
[01:26:29] <Xark> Okay, that is a mind blower. :)
[01:27:10] <Haohmaru> yeah.. microchip's apps just suck, i'm getting pissed off quite often with their crap
[01:27:16] <Xark> Ahh -> http://dangerousprototypes.com/2010/04/07/program-your-avr-with-pickit2/
[01:27:51] <Xark> I don't use them. PIC32 is kinda nice, but Microchip are tools. After their GCC shenanigans, I avoid them.
[01:29:00] <Haohmaru> i use pk3cmd cuz it's the least evil, yet it manages to annoy you by being uber slow.. it loads java underneat x_x
[01:29:46] <Xark> AVR has their DFU uploader in Java (Flip IIRC), but it wasn't too annoying (surprisingly).
[01:30:23] <Haohmaru> i used that flip thing on friday.. didn't noticed anything bad/wrong about it
[01:30:50] <Xark> Yeah, that is what surprised me (for a Java utility). :)
[01:30:52] <Haohmaru> it just worked
[01:31:25] <Haohmaru> no idea how microchip managed to make even their commandline tool so slow
[01:31:29] * Xark had to use it to update an AVR on an FPGA board...
[01:31:38] <Haohmaru> takes like 5 seconds till it even prints its name
[01:31:49] <Xark> Poor coding or something.
[01:32:12] <Xark> (Or machine translated from Visual Basic or something). :)
[01:33:43] <Haohmaru> huhu
[01:35:16] <Haohmaru> so i'm finding "Atmel Studio" but not quite "AVR Studio"
[01:36:40] <Xark> Yeah, renamed (since supports ARM etc.)
[01:36:46] <Xark> Same deal though
[01:38:24] <Haohmaru> wow.. it requires 6GB harddisk space
[01:38:29] <Haohmaru> dayum
[01:39:23] <Xark> It is not a "light" environment (but runs much smoother than Eclipse). :)
[01:55:08] <Haohmaru> well, this is gonna take a long time to download..
[01:56:23] <Haohmaru> i hope this webinstaller is smart enough to resume if the connection goes bad
[02:03:01] <Casper> Haohmaru: lol?
[02:04:02] <Haohmaru> wat
[02:04:48] <Haohmaru> many apps which download from the internetz assume that the connection is perfect
[02:06:31] <Haohmaru> the atmel webinstaller is downloading with barely 30kB/sec
[02:07:00] <Haohmaru> maybe cuz i'm not registered ;]
[04:20:08] <Haohmaru> how can i test if the avrispmk2 actually works?
[04:21:05] <Haohmaru> i see it blinking and it appears to respond to avrdude, but either the xmega is playing dead, or the programmer
[04:58:17] <Haohmaru> it does stuff on the icsp header when i tell it to talk to some atmega, so the programmer isn't broken
[04:58:41] <Haohmaru> must be the xmega i guess :/
[06:27:24] <Haohmaru> wow.. installation complete
[06:27:47] <Haohmaru> i feel like i installed a whole OS
[06:28:57] <Lambda_Aurigae> you did.
[06:29:12] <Lambda_Aurigae> now to reboot windows 3 to 5 times.
[06:31:02] <Lambda_Aurigae> I still believe windows has a random-reboot-on-application-install() function that gets called every time you install something.
[06:34:22] <sebus> Lambda_Aurigae++;
[06:42:28] <Lambda_Aurigae> ok...time to for be going off worky to.
[06:42:45] * Lambda_Aurigae doesn't channel Yoda very well...
[07:01:52] <Tom_itx> or yoga
[07:06:52] <Haohmaru> yes.. it wants to reboot
[07:07:16] <Haohmaru> it installed 98443897 things even tho i selected only 8bit avr support and no other bullsh*t
[07:07:31] <Haohmaru> now.. to reboot.. grr
[07:24:06] <Haohmaru> i just remembered something.. the avrispmk2 has to be flashed with the other firmware in order to be used with atmel studio?
[07:29:26] <Haohmaru> "Unable to connect to tool AVRISP mkII (000200312345)" .. i guess so
[07:40:34] <Haohmaru> "Failed to enter programming mode. Error status received from tool: Result received is 0x01"
[07:40:40] <Haohmaru> that's with atmel studio
[07:40:45] <Haohmaru> :/
[07:44:21] <Haohmaru> how can i test if the xmega is dead or not?
[07:44:54] <Haohmaru> that is, a new xmega which hasn't been used before (if that helps)
[07:48:10] <cehteh> hook it up to a programmer, read signature bytes
[07:48:30] <cehteh> mabe upload some test programm
[07:49:00] <cehteh> check your cabeling
[07:49:05] <Haohmaru> it doesn't talk to the programmer
[07:49:26] <Haohmaru> i checked the cables like 10 times :/
[07:49:48] <cehteh> try another µC ..
[07:50:10] <Haohmaru> well that's harder
[07:50:51] <cehteh> maybe the fuses are programmed wrong, then if you dont know how wrong only HV programming will help you
[07:51:20] <cehteh> if you have an idea whats wrong in the fuses you can sometimes work around, providing external clock, change programmers speed etc
[07:51:50] <cehteh> hv programming should always work, but you need a programmer for that
[07:53:03] <Haohmaru> wait a minute, i thought you cannot mess up the fuses on an xmega
[07:53:28] <Haohmaru> i mean, since the programming interface is not SPI
[07:54:01] <cehteh> mhm maybe i dont know the xmegas, read datasheet
[07:54:39] <cehteh> ah ..just see
[07:54:41] <Haohmaru> well it uses a dedicated pin for programming, and it cannot be disabled
[07:55:12] <Haohmaru> and this is my first xmega, so i haven't yet used/programmed/flashed it
[07:55:17] <Haohmaru> it should be clean
[07:55:32] <cehteh> you have no 2nd one?
[07:55:36] <cehteh> just to cross check
[07:56:48] <Haohmaru> i have, but it's just a bare chip.. this one would have to be desoldered from the breakout board, and the other one would have to be soldered onto it
[07:57:03] <Haohmaru> which i am not gonna attempt to do myself ;]
[07:57:28] <cehteh> smd?
[07:57:50] <cehteh> what package?
[07:57:52] <Haohmaru> i think the whole xmega family is smd only
[07:57:57] <Haohmaru> smd and 3.3V
[07:59:45] <cehteh> http://www.hobbyking.com/hobbyking/store/__27195__Atmel_Atmega_Socket_Firmware_Flashing_Tool.htm i have one of those, and build other for other chips (tinys) by myself
[07:59:46] <Haohmaru> "TQFP44"
[08:00:21] <cehteh> you could do the voodoo method :)
[08:01:23] <cehteh> http://www.christophreinhardt.ch/images/2012/12/2012-12-02-23.44.28.jpg
[08:01:40] <cehteh> http://s019.radikal.ru/i621/1307/6d/6e78e0a0be8b.jpg
[08:02:08] <Haohmaru> what the hell o_O
[08:03:06] <cehteh> i used that successfully before i had the other tools too :)
[08:03:33] <Haohmaru> that looks.. mean
[08:03:35] <Haohmaru> ;]
[08:04:41] <cehteh> easier than desolder/resolder
[08:06:09] <Haohmaru> the amplitude of my hand shake covers an area as big as the chip ;P~
[08:06:45] <Haohmaru> i'll have to wait till the guy who knows how to solder these comes back
[08:07:56] <Haohmaru> xmega: y u no thru-hole :~(
[08:09:34] <cehteh> i'd guess you configured something wrong, timing etc
[08:10:29] <cehteh> so far i never had a dead avr
[08:12:56] <Haohmaru> configure where?
[08:13:24] <Haohmaru> this is the first time i am trying to deal with xmega
[08:13:50] <cehteh> configure your programmer
[08:14:13] <Haohmaru> from where?
[08:14:21] <cehteh> well you saied avrstudio? i dont know that
[08:14:37] <Haohmaru> there's no settings for it
[08:14:45] <cehteh> i am in linux, using avrdude and usually configure things in a makefile
[08:15:24] <Haohmaru> i also want to use avrdude, not this nightmare studio..
[08:16:23] <Haohmaru> what kinds of things do you configure?
[08:16:41] <cehteh> haha .. a friend of me has that, and a fast xeon cpu computer with lots ram .. still starting avrstudio up is a coffee break :D
[08:16:55] <Haohmaru> the only thing that comes to my mind is to try and slow it down, but i tried -B and it doesn't actually change anything
[08:17:05] <cehteh> just read the avrdude manpage
[08:17:09] <Haohmaru> the programmer is communicating at some fixed, and quite high rate
[08:18:01] <cehteh> usually you have to set the chip you are programming . .and by what method/programmer .. like usbasp, arduino bootloader, stk500 etc
[08:18:16] <Haohmaru> i'm doing all that
[08:18:43] <Haohmaru> -c avrispmkii -P usb -p x32a4
[08:18:58] <cehteh> -v for verbose
[08:19:24] <Haohmaru> yes, i know.. but it fails in the very beginning
[08:19:30] <cehteh> well i dont know, there is a chance that you have a dead chip, but you only find out when you can cross check with a known working
[08:19:34] <Haohmaru> basically, i think the chip doesn't respond
[08:19:59] <cehteh> check if the chip is correctly powered
[08:20:04] <Haohmaru> it is
[08:20:10] <cehteh> well i cant say more
[08:20:21] <cehteh> swapped miso/mosi?
[08:20:32] <Haohmaru> ugh.. spi is not used
[08:21:06] <Haohmaru> i've put it on breadboard and i've only connected GND, VCC, and the programming interface
[08:21:15] <Haohmaru> i haven't yet put a LED even
[08:22:15] <Haohmaru> i predicted i'd have bad luck with the programmer, so i didn't hurry to put stuff and did everything very carefully before powering it up
[08:23:30] <Haohmaru> despite all that, the programmer failed, and keeps failing the same way, it fails the same way if the cable is not plugged, which means (i think) that the chip doesn't respond
[08:24:36] <Jartza> evening
[08:24:46] <Haohmaru> the other little detail is that this is a avrispmkii clone, from olimex.. but afaik it should be able to deal with PDI
[08:25:43] <Jartza> and you have switched the firmware to avrdude compatible?
[08:25:51] <Haohmaru> yes
[08:26:10] <Haohmaru> and now i changed it to the one for atmel studio and it doesn't work there either
[08:26:35] <Haohmaru> i mean.. the programmer works, but it says that there is something not right about the "target"
[08:26:48] <Haohmaru> tells me to check voltage/cables/everything
[08:27:43] <Haohmaru> fails to read anything from the chip
[08:27:59] <Jartza> hmmh. I have some xmegas and the same programmer, but I haven't had time to play with them at all
[08:39:14] <Jartza> I've been too busy with other stuff
[08:40:58] <SM0TVI> Haohmaru: Tried another chip with it?
[08:41:27] <cehteh> my saying :D
[08:42:18] <SM0TVI> Haohmaru: TL;DR if another chip works, but this one doesn't, problem lays in either the cabling or in one of the params (e.g. clock speed, chpol and chpha).
[08:42:36] <SM0TVI> Haohmaru: Or in the chip itself being kaput, ofc.
[08:42:49] <cehteh> which is quite rare
[08:43:01] <cehteh> (for a prime unused chip)
[08:43:26] <SM0TVI> Haohmaru: And I assume you did not wear synthetics while handling it?
[08:44:35] <SM0TVI> cehteh: I have this synthetic coat and clogs that tend to be a shocker for me.
[08:45:01] * SM0TVI can do 10kV easy with those.
[08:45:10] <cehteh> ok thats another thing. while atmels are particulary quite robust compared to other µC's
[08:45:55] <cehteh> inputs are clamped with diodes ... ok they wont protect against any abuse
[08:46:01] <SM0TVI> That's why I suggested params double-check before returning the item.
[08:47:40] <SM0TVI> cehteh: The reset pin should always be low on the ISP header, no?
[08:47:47] <SM0TVI> Erm. High*
[08:49:05] <cehteh> no
[08:49:16] <cehteh> the ISP control the reset pin
[08:49:36] <cehteh> high = normal operation .. and the atmel chips have weak pullup there
[08:49:42] <cehteh> low= programming mode
[08:49:59] <cehteh> so when the isp wants to program a chip it pulls the reset down
[08:50:41] <SM0TVI> Just a thought, verifying in-system that the signals get there.
[08:52:34] <Haohmaru> no, i haven't tried another chip cuz.. smd.. i'm not brave enough to touch those with the iron
[08:52:48] <Haohmaru> what params?
[08:53:40] <Haohmaru> i don't think i can change the clock speed (the B switch doesn't change anything), chpol/chpha sounds like SPI?
[08:53:47] <Haohmaru> this is xmega.. PDI
[08:53:59] <Haohmaru> it connects to just 2 pins
[08:55:08] <SM0TVI> Haohmaru: You have an oscilloscope?
[08:55:14] <Haohmaru> yez
[08:55:30] <SM0TVI> Haohmaru: Have you probed the signal pin?
[08:56:05] <Haohmaru> i can see the programmer trying to do its thing, but the signal looks the same as when the cable is not connected to the board at all
[08:56:36] <Haohmaru> well, specifically the PDI pin on the xmega appears to have an internal pull-down resistor
[08:56:43] <SM0TVI> So the xmega is not responding. Have you gone over the solders under magnification?
[08:57:11] <Haohmaru> as much as i can tell, it appears that it doesn't respond at all
[09:00:29] * SM0TVI thinks that the above is about the limit of what he can help with.
[09:02:31] <Haohmaru> the chip has like VCC and GND on all four sides more or less, i've connected all of them
[09:18:37] <Haohmaru> when i specify -B in avrdude, and -v -v, it says "SCK period X us" with X being what i specify, the default is 8 us.. however, watching the clock signal on the scope - it's always 250kHz
[09:19:29] <twnqx> use avrdude <6
[09:19:36] <twnqx> everything newer is broken for me
[09:19:51] <Haohmaru> yes, the programmer didn't work at all with avrdude 6
[09:19:57] <Haohmaru> i installed 5.10
[09:20:21] <twnqx> well, might be that your programmer ignores the bitrate setting
[09:20:32] <Haohmaru> yeah, i think so
[09:22:25] <Haohmaru> hm..
[09:30:20] <Haohmaru> from the "xmega A schematic checklist" datasheet, i think it says that if you don't need external reset circuit - you can omit the pullup resistor too
[09:31:08] <Haohmaru> so it has internal one, i guess.. but does that mean that if i measure the reset pin, it should be high just as long as the chip is powered?
[09:31:51] <cehteh> some programmers come with old firmware less features, cant change programming rate etc
[09:32:01] <cehteh> but usually you can upgrade the firmware on those
[09:46:02] <Haohmaru> crap
[09:47:15] <Haohmaru> the tiny chunk of cable i used to transfer the reset pin to the programmer.. it's 2cm long.. it was causing this issue
[09:47:19] <Haohmaru> >8(
[09:47:57] <Haohmaru> the chip responds now and gives back its signature bytes
[09:48:54] <Haohmaru> i feel dumb
[10:30:30] <Haohmaru> holy sh*t.. it's blinking.. xmega is alive
[10:31:25] <cehteh> ahha :))))
[10:31:55] <cehteh> what did i say at very very first? .. check your cabeling :DDDD
[10:32:54] <Haohmaru> i checked it, but on the wrong side
[10:34:12] <Haohmaru> it was at the point where 4 or so cables join into the reset pin, so it was messy on the breadboard, and that little cable was doing something weird
[12:52:53] <Strangework> e
[12:53:02] <Strangework> Pardon me
[18:41:07] <yids_> hello
[18:41:36] <Lambda_Aurigae> olleH
[18:43:00] <yids> im kinda new to avr programmiong and programming in general and i have a problem, I am using the arduino-mk build system to compile for an atmega328, and i want to use the AVRCryptoLib,
[18:43:15] <yids> during compiling i get a lof of these erros /usr/share/arduino/libraries/AVRCryptoLib/md5_test.c:77:23: error: variable ‘a_md5’ must be const in order to be put into read-only section by means of ‘__attribute__((progmem))’
[18:43:42] <yids> and i kindoff have the feeling that maybe the attribute for putting stuff in PROGMEM is not set or something or is not valid
[18:43:59] <yids> because I kindoff remember that i compiled it succesfully before
[18:44:37] <yids> and before i manually add the word const to 50 lines in 10 different files, i thought maybe ask here because i think im just overlooking something stupid
[18:44:46] <Lambda_Aurigae> because arduino is involved, I have no clue.
[18:45:14] <Lambda_Aurigae> someone else might, however.
[18:45:27] <Lambda_Aurigae> PROGMEM access is not the same as CONST
[18:45:50] <yids> but does it make sense that the compiler wants things that go in PROGMEM to be constants?
[18:46:03] <yids> kinda makes sense, iirc PROGMEM is the rom no?
[18:46:11] <Lambda_Aurigae> yes.
[18:46:28] <Lambda_Aurigae> and there are special procedures needed for putting things in progmem.
[18:46:35] <Lambda_Aurigae> have you read the avr-libc section on progmem?
[18:46:44] <yids> nope
[18:46:57] <Lambda_Aurigae> http://www.nongnu.org/avr-libc/user-manual/pgmspace.html
[18:47:05] <yids> ill have a look
[18:47:45] <Lambda_Aurigae> https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html not to confuse, but a different way to put data in the program space.
[18:50:37] <Lambda_Aurigae> now, how any of that would integrated to anything arduino, I have no clue.
[18:57:12] <yids> i think arduino is not much more than avr with a prebuilt makefile and some standards for libraries paths and tools
[18:58:34] <Lambda_Aurigae> lots of idiotic libraries that abstract you from the hardware too much for my taste.
[18:58:46] <yids> in general is there a way of telling avr-gcc "whenever you see a var for progmem, make it constant"
[18:58:55] <Lambda_Aurigae> no main,,,they have their own startup.
[18:59:28] <Lambda_Aurigae> use find/replace?
[18:59:40] <yids> yeah maybe true, but it makes it more accesible to start with.. i probabably wouldnt be here if it werent for arduino..
[19:00:20] <Lambda_Aurigae> I just wish they hadn't gone with things like the wiring library and such rubbish.
[19:00:27] <Lambda_Aurigae> but, to each their own.
[19:00:43] <Lambda_Aurigae> I started with avr long before arduino existed.
[19:01:13] <Lambda_Aurigae> and before any irc channel existed for it that I could find too...
[19:01:19] <Lambda_Aurigae> but, I'm an old bastard.
[19:08:23] <yids> hm and do you know of a way to tell avr-gcc not to complain about me trying to put a non const in progmem ?
[19:18:50] <yids> hm in the pgmspace documentation it doesnt mention anything about having to make something a const before putting it in progmem
[19:22:33] <Xark> yids: Make it cost? :)
[19:22:37] <Xark> const*
[19:23:46] <Xark> yids: You can probably suppress the warning too (-Wno-non-const or something like that), but why lie to the compiler?
[19:24:21] <yids> oh because i have to change a lot of declarations in a lot of files
[19:24:50] <yids> and according to the docs it is not needed to declare them as constants
[19:32:00] <Xark> yids: It is "needed" in newer builds or you (rightly) get a warning. :)
[19:32:07] <yids> Xark: im looking for such a supressing mechanism here http://www.nongnu.org/avr-libc/user-manual/using_tools.html and http://www.atmel.com/webdoc/atmelstudio/atmelstudio.Projects.GCC_projectOptions.CompilerOptions.html here, but i dont see one
[19:32:53] <yids> why do you _have_ to declare it a constant? i mean it is obviously not gonna change when you put it in progmem
[19:34:31] <Xark> Because it is a constant and it would be incorrect to have it non-const.
[19:35:45] <yids> but appart for correctness` sake is there any other real reason why they should be defined as consts?
[19:36:22] <Xark> It is not even a warning, it is an error, it seems.
[19:36:42] <Xark> Correctness sake is what gcc strives for.
[19:37:51] <Xark> It will also prevent "unexpected problems" if someone were to say var = 7; when var is in PROGMEM (without const it would trash SRAM, with const a proper error).
[19:38:45] <Xark> So, my recommendation is quit being lazy and add const to your declaration. :)
[19:41:19] <yids> okay on to the regex school
[19:41:54] <yids> anyway, does anyone know of any asymetric crypto implementations for avr?
[19:46:06] <yids> oh wait regex school is over, s/unsigned char PROGMEM/unsigned const char PROGMEM is enough :P
[19:48:00] <yids> that moment when you spend half an hour trying to find out how to prevent spending 5 minutes of work
[19:48:22] <Xark> :)
[19:49:19] <Xark> However, every programmer needs a bit of laziness (often can encourage you to find a "better way"). :)
[19:50:13] <yids> true
[19:50:17] <rue_shop3> unless your a reacreational coder, who is making ART
[19:54:00] * Xark links http://threevirtues.com/
[20:19:21] <yids> okay so, anyone knows of a assymetric crypto implemantion for avr?
[20:50:55] <Xark> LMGTFY perhaps => http://avrcryptolib.das-labor.org/trac
[20:52:05] <Xark> ...or perhaps not. Looks like slim pickings.
[21:57:23] <Shavik> Anyone an Agilent/Keysight user? Thinking about a DSO3000T for home. Not sure though