Back
[00:06:30] <Roklobsta> just brute force the key's with a Jupiter sized cabinet of FPGAs
[00:07:34] <Valen> have they not just eaten the FPGA and probed the keys out?
[00:07:41] <Valen> or is it a unique key per device?
[00:14:58] <Roklobsta> farq making an AT parser/state machine for 3g modem. PITA
[00:28:02] <braincracker> Valen <= i don't know, i'd have used a serial number for each device, but the internals are "kept in secret" so it is possible every device at least of the family contains same encryption codes
[00:33:04] <braincracker> http://www.bit-tech.net/news/bits/2010/01/13/researchers-crack-768-bit-rsa/1
[00:33:45] <braincracker> http://hackaday.com/2008/12/30/25c3-hackers-completely-break-ssl-using-200-ps3s/ :)
[06:32:57] <ambro718> In gcc inline asm, what is the allowed input range for "n" type input arguments? Can it be any uint32_t?
[07:40:34] <vectory> RikusW:
http://kripken.github.io/lua.vm.js/lua.vm.js.html :DDD
[07:45:10] <RikusW> interesting
[08:06:53] <meb-us> Hallo! Can anyone tell me how to add a static library ".a" to Atmel Studio?
[09:24:05] <antto> can you read lockbits and/or fuses and print on screen via avrdude?
[09:24:14] <specing> sure
[09:24:19] <antto> how?
[09:25:00] <specing> $ avrdude -t
[09:25:04] <specing> > dump lfuse
[09:25:07] <specing> > dump hfuse
[09:25:09] <specing> > dump efuse
[09:27:45] <antto> oh sh*t
[09:28:19] <antto> when connected usbasp - windowz says that the USB device is malfunctioning and cannot recognize it O_o
[09:29:27] <specing> solution: don't use windows.
[09:30:18] <antto> last time it worked
[09:30:49] <specing> hackvana, CapnKernel: is the chinese internet throwing you out?
[09:31:01] <specing> I thought you were VPN'd
[09:48:29] <antto> "This troubleshooter is unable to solve your problem."
[09:48:32] <antto> grrreat ;]
[10:08:06] <specing> This troubleshooter is you
[10:08:12] * specing hands antto a gun
[10:18:34] <RikusW> http://www.youtube.com/watch?v=FcqQvH41OR4
[10:21:00] <Essobi> whatup
[10:21:01] <Essobi> whatup
[10:21:19] <Essobi> WEEEEEEEEEE.
[10:23:19] <RikusW> there is a proposed new law in ZA, allowing $100000 fines if you warn someone else about bad weather.... :S
[10:23:35] <RikusW> totally nuts
[10:26:21] <Essobi> ...
[10:26:23] <Essobi> bahaha
[10:27:33] <RikusW> its real...
[10:27:48] <RikusW> well not a real law yet fortunately..
[10:29:58] <RikusW> http://translate.google.com/translate?sl=af&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.landbou.com%2Fjou-mening%2Fpraat-saam%2Fstorm-woed-oor-nuwe-weer-wet
[10:52:38] <antto> specing: running ubuntu now
[10:53:01] <antto> usbasp is plugged, altho i didn't see any indication of it anywhere *shrug*
[10:53:39] <antto> avrdude -c usbasp -p m2561 == "error: could not find USB device "USBasp" with vid=0x16c0 pid=0x5dc"
[10:53:41] <vectory> RikusW: wtf? what about weather forecasts, excempt?
[10:54:55] <vectory> reading the article. its basically copy right infringement on weather forecasts?
[10:56:52] <vectory> i'd propose death sentence, tbh. do you have that, btw?
[10:57:07] <RikusW> its only the weather service thats allowed to provide that info...
[10:57:53] <RikusW> vectory: unfortunately that death sentence disappeared since 1994
[10:58:03] <vectory> unfort ... what?
[10:58:21] <RikusW> s/that/the/
[11:47:28] <antto> is my usbasp dead?
[11:49:04] <RikusW> try it on a different AVR
[11:49:23] <antto> i don't have other AVRs
[11:51:02] <antto> it has 3 LEDs, "RUN" and "PWR" light up when i plug it in the USB
[11:51:08] <antto> "BUSY" doesn't
[11:52:01] <antto> two months ago - it worked, under windows as well
[12:02:26] <antto> RikusW: i mean.. it *seems* that it acts as if it's gone broken
[12:03:26] <antto> i am not familiar with linux/ubuntu, but on windows, it *detects* that a USB device gets plugged in, but fails to recognize what it is at all
[12:03:34] <antto> "Unknown Device"
[12:07:00] <antto> hm... after retrying 10 times i got this: "avrdude: Warning: cannot query manufacturer for device: error sending control message: Operation not permitted"
[12:09:54] <specing> antto: what does dmesg say?
[12:10:05] <antto> what's dmesg?
[12:11:03] <antto> if i press on the pcb of it - it appears to restart itself (for a short moment the RUN led goes off and BUSY led goes on
[12:11:05] <antto> wtf
[12:11:15] <specing> antto: Kernel log
[12:11:16] <antto> is it not making contact with the components
[12:11:38] <antto> oh
[12:11:43] <specing> You may also have crappy cables
[12:11:44] <antto> i see lots of things there
[12:12:05] <specing> I have two USB cables that refuse to work
[12:12:16] <antto> the last few lines are: [ 5139.445028] hub 1-0:1.0: >connect-debounce failed, port 7 disabled
[12:12:59] <antto> hm
[12:13:10] <antto> there are more errors before that
[12:13:24] <antto> like that it can't enumerate the port and what not
[12:13:52] <antto> but a bit above that i can see a succesiful one where it got the vendor stuff and "USBasp"
[12:14:22] <antto> but i have no idea if that's from today or from 2 months ago?
[12:14:51] <antto> [ 4979.467054] usb 5-1: >Product: USBasp
[12:14:54] <specing> [ 5139.445028] <- timestamp
[12:15:02] <antto> in what format is that?
[12:15:19] <specing> seconds.microseconds/nanoseconds
[12:15:32] <specing> of uptime
[12:15:35] <antto> oh?
[12:15:41] <antto> so it's from today then
[12:15:45] <specing> yes
[12:15:52] <antto> i've had one successiful connect
[12:15:57] <specing> first is from 1h 20 min
[12:16:01] <antto> then it must be cable and/or bad connection
[12:16:09] <antto> grr
[12:16:10] <specing> and the second from ~1h 25min
[12:16:13] <antto> damn chinese cable ;]
[12:16:17] <specing> try a different cable
[12:17:57] <antto> can't find another such usb cable >:/
[12:18:51] <antto> but when i press my finger under the resonator on the USBASP (on the under side, the solder points) - the two leds PWR and BUSY start to "dance" randomly
[12:19:01] <antto> this smells like it's not the cable
[12:19:12] <antto> and that's the same cable i used two months ago
[12:19:37] <specing> my cables got gradually broke
[12:25:55] <antto> okay, now plugged again and the last thing in "dmesg" is that it recognized it as USBasp
[12:26:32] <antto> when i try "avrdude -c usbasp -p m2561" - avrdude still says it can't find a USBasp :/
[12:27:02] <antto> and "cannot query manufacturer"
[12:27:04] <antto> grrr
[12:27:16] <antto> okay, so at least it's not completely dead
[12:27:21] <antto> there's hope
[12:28:46] <braincracker> h
[13:12:22] <antto> is there a way to "watch" the stuff that gets logged in this "dmesg" ?
[13:13:39] <john_f> --follow
[13:13:54] <john_f> ctrl-c to exit
[13:15:38] <antto> doesn't have this param O_o
[13:16:26] <john_f> see --help for it then
[13:16:32] <antto> i did
[13:16:40] <antto> there's nothing like it
[13:16:56] <antto> --console-on ?
[13:18:11] <john_f> tail -f /var/log/dmesg.log maybe
[13:18:39] <antto> no such file O_o
[13:19:00] <john_f> everything.log?
[13:19:19] <john_f> or ask in ubuntu ;)
[13:24:36] <antto> kern.log
[13:25:12] <antto> so i see it is constantly printing errors "connect debounce failed..."
[13:25:40] <antto> chinese cable + chinese ubsasp == trouble ;]
[13:26:27] <john_f> so my board is as good as theirs. good to know
[13:26:37] <john_f> at least when it is warm
[13:26:57] <antto> your board?
[13:27:11] <RikusW> cat /proc/kmsg
[13:27:25] <john_f> started getting those errors
[13:28:07] <john_f> just an atmega32u2
[13:29:38] <john_f> or just crappy software...
[13:31:44] <antto> is it normal that it sort of "reboots" when i touch the resonator's two legs with my finger?
[13:32:16] <antto> resonator or crystal or whatever it is "12.000"
[13:33:00] <john_f> the crystal may stop with the added capacitance
[13:33:45] <antto> should i try something like re-heating the solder joints?
[13:33:59] <antto> or is it really the usb cable doing this
[13:45:17] <RikusW> http://theconversation.com/more-data-storage-heres-how-to-fit-1-000-terabytes-on-a-dvd-15306
[13:59:20] <Nutter> does anyone here have experience with using the upper 128k of FLASH on the mega 2560?
[14:00:14] <Nutter> at >128k addresses you have to be using pgm_read_*_far(), and not the regular PROGMEM section - however even after doing this I still have issues data, where part-way through reads just return 0xFF rather than the correct data
[14:09:28] <braincracker> do you use bleeder resistor in your circuits from vdd to vss ?
[14:10:40] <braincracker> advantage is low current high voltage will not avalanche the thing, disadvantage is it cuts off the storage capacitor's hold-up time;/
[14:15:14] <antto> Nutter: i'm dealing with a 2561 here, what's that?
[14:22:15] <Nutter> the issue? I guess I'm not convinced that the data's going to the expected/specified section, and as such seems to be pushing something that shouldn't be beyond the 64k limit, beyond it
[14:22:56] <Nutter> nm/objdump seem to be very unhelpful about giving me information on the sections too... maybe I just need some help/pointers there?
[14:25:52] <Nutter> i.e. I specify __attribute((section(".fini7"))) on my data, but no such section is reported by "avr-objdump -h myfile.elf"
[14:32:24] <antto> today i noticed this:
http://www.nongnu.org/avrdude/user-manual/avrdude_4.html
[14:32:29] <antto> (**)
[14:34:21] <antto> Nutter: i know about the 2561 and 2560 that the flash is addressed in "words"
[14:34:38] <antto> so that might work since words are 2 byte long
[14:35:31] <antto> my hex hasn't reached 128kB yet
[14:38:22] <Nutter> well the first 64k can be addressed with words :) it's the rest that's causing me grief... it should be just a matter of putting the data in the right section, getting the 32bit address from the symbol, then calling pgm_read_*_far with an offset from that address... should :P
[14:40:46] <Nutter> right now it's back to not even getting to main() due to what I'm guessing is something being pushed beyond 64k that shouldn't be... Removing a single large (~18kb) piece of data that's *supposed* to be in the .fini7 section lets it run just fine
[14:41:41] <Nutter> from everything I've read on avrfreaks, .fini7 should avoid issues with things GCC needs in the lower 64 being pushed beyond, but... yeah
[14:53:15] <antto> this is kinda way beyond my understanding
[15:14:42] <tzanger> actually there are some avr-gcc hackers here
[15:15:03] <tzanger> what exactly does -fno-tree-scev-cprop and -ffreestanding do?
[15:16:30] <tzanger> ahh freestanding means main() doesn't have to return (saves a bit of code)
[15:17:20] <tzanger> found
http://www.tty1.net/blog/2008-04-29-avr-gcc-optimisations_en.html
[15:21:15] <Essobi> ⌐■_■
[15:35:59] <moemoe> Hi, just started to go from arduino to directly c programming atmels, and now got stuck. I looked up the correct macro names in /usr/lib/avr/include/avr/iotn2313a.h, but the compiler complains about »‘OC1A_PORT’ undeclared«. Probably some stupid mistake, but I'm currently a bit clueless.
[15:37:15] <moemoe> Trying to compile with »avr-gcc -c -mmcu=attiny2313a -I. -g -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 -DF_CPU=8000000 main.c -o main.o« 'stolen' from some makefile template.
[15:46:34] <tzanger> hm, does avrdude support CBUS bit banging on the ft232? I guess I could use DTR/DSR/DCD/RI
[15:53:59] <RikusW> moemoe: OCR1A maybe ?
[15:54:26] <moemoe> RikusW: > grep OC1A_PORT /usr/lib/avr/include/avr/iotn2313a.h
[15:54:27] <moemoe> #define OC1A_PORT PORTB
[15:54:38] <moemoe> but now it somehow compiled, can't figure out what I changed
[15:55:20] <moemoe> compiles as in compiles, but the linker fails.
[15:55:50] <RikusW> that define wasn't included in the file
[15:55:58] <RikusW> did you set the proper mcu ?
[15:56:16] <RikusW> and #include <avr/io.h> ?
[15:56:51] <theBear> like, clipsal cbus ?
[15:57:06] <moemoe> http://paste.nnev.de/3703 that's what my makefile does, and the code is
http://paste.nnev.de/3704
[16:10:13] <Gumboot> I don't suppose there's any way of faking a three-operand ADC when one operand is zero, is there? That is, Rd = Ra + C.
[16:23:54] <moemoe> RikusW: Great, I found a bug report for this:
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=972384
[16:38:04] <Casper> moemoe: but is it a valid bug report?
[16:38:58] <moemoe> Casper: Don't know, but changing MCU attiny2313 works fine. And as far as I can see, they should be binary compatible, so I don't care anymore.
[16:39:03] <Casper> and... I never saw a code using OC1A_PORT, double check that your code is valid
[16:41:14] <moemoe> Casper: The code compiled, and as it is defined in /usr/lib/avr/include/avr/iotn2313a.h you can use it.
[16:41:46] <moemoe> But iotn2313.h doesn't define it, so perhaps some guy thought it would be a nice extension, but it's not really used elsewhere.
[16:41:55] <moemoe> I know also stopped using it ;)
[16:51:37] <Roklobsta> holy crap this is useful:
http://gcc.gnu.org/wiki/avr-gcc
[16:53:03] <braincracker> yes, some people use gcc with success
[16:54:13] <Roklobsta> i do
[16:54:18] <Roklobsta> so far
[16:54:32] <Roklobsta> are you an asm user?
[16:55:37] <braincracker> i'm usually good with C
[17:00:27] <tzanger> hm. avrdude-serjtag looks like I can combine uart and jtag with one ft232
[17:00:56] <braincracker> tzanger <=
http://hackaday.com/2008/12/30/25c3-hackers-completely-break-ssl-using-200-ps3s/ :)
[17:01:00] <tzanger> needs the d2xx lib though and there are some reports that that interferes with regular uart operation after
[17:01:09] <braincracker> http://dangerousprototypes.com/2012/03/12/hacking-the-fpga-bitstream/
[17:01:25] <tzanger> braincracker: yeah I saw you posted that earlier
[17:01:32] <braincracker> kk
[17:01:52] <braincracker> it is odd from an fpga manufacturer to talk bullshit
[17:01:58] <braincracker> ;/
[17:02:12] <tzanger> that isn't as interesting as learning the internal mapping so you can do your own p&r but it is interesting if you want to clone a device
[17:03:07] <braincracker> hm, yeah it would be awe to have an opensource tool for them
[18:58:51] <Roklobsta> wow avr-gcc with -O0 generates some god awful and redundant asm
[19:00:07] <Roklobsta> -O1 as expected produces something way more sensible
[19:09:12] <Roklobsta> interrupt question... i am using the SPMIE as a software generated interrupt. right after the bit is set to generate the irq with "out 0x37,R24" can i expect the next instruction executed to be the IRQ or should I insert a tonne of NOPs Stepping with the debugger doesn't show the IRQ being called right after - i suspect the IRQ isn't triggering because of stepping through the disassembly.
[19:09:58] <Roklobsta> An old school ICE would show if this was happening or not.
[19:12:08] <Casper> do a test case on the actual hardware
[19:13:05] <Casper> set a register to something, trigger the interrupt, set the register to 1, then 2, then 3 and then 4, have the interrupt check for whatever value is in that register so you know how much cycles it take for it to trigger
[19:14:03] <Roklobsta> the avr data sheet seems to allude the irq should be serviced right away.
[19:16:12] <Casper> that is what I understood, but I hear other stuff, like it preload stuff, so may take an extra cycle or 2... if you rely on such precision... do the test case
[19:19:18] <Roklobsta> maybe i should put some nops in. there might be a rare time when a higher pirority interrupt occurs. the software unterrupt kicks off a task yield, i really don't want the yielding code to execute any more code after the "out 0x37..." until that task is context switched in again.
[19:20:46] <Roklobsta> Meh, i'll stick in 5 nops for now. it can't hurt.
[19:21:06] <Casper> I don't think it's needed, but if you wish
[19:22:18] <Roklobsta> it'll deal with the rare case of "out 0x37..." followed by the timer irq which then returns, executes one opcode then the next irq should trigger. The manual says one non-irq opcode is executed between a reti and a new irq.
[19:24:13] <Roklobsta> "When the AVR exits from an interrupt, it will always return to the main program and execute one more instruction before any pending interrupt is served."
[19:26:52] <Roklobsta> i guess the amount of NOPs needed depends on how likely the worst case of higher priority interrupts are pending at the same instant the SPMIE is triggered by executing the "out 0x37"
[19:27:30] <Roklobsta> you know, like the planets aligning
[19:28:08] <Roklobsta> ahead of spie are timer1, uart1tx,uart1rx,uart0tx and uart0rx.
[19:29:51] <Roklobsta> so at least 5 NOPS needed between the SPMIE triggering 'out' and the 'ret'
[19:32:02] <Roklobsta> it's unlikely but possible cases like that which can cause an embedded programmers hair to be torn out.
[19:32:32] <Roklobsta> because it'll happen once in a blue moon on a device in the field 1000'km away.
[19:32:38] <Roklobsta> which has happened to me in the past.
[19:34:54] <Roklobsta> an you know, as rare as it is for the planets to align, it does happen from time to time and you have to be prepared for all the earthquakes.
[20:18:40] <RikusW> http://www.elektor.com/news/ideal-diode-bridge-controller-minimizes-rectifier.2494929.lynkx
[22:30:21] <beaky> hello
[22:30:26] <beaky> does avr do automatic debouncing?
[22:30:36] <theBear> no such thing
[22:30:46] <beaky> ah
[22:31:10] <GuShH> on software you mean?
[22:31:10] <GuShH> some micros do, not sure about newer avrs...
[22:31:22] <GuShH> but on those that do, you have to set it up anyway
[22:31:29] <GuShH> nothing is "automatic"
[22:31:41] <beaky> I thought there was builtin hardware debouncing on microcontrollers
[22:32:00] <GuShH> what sort of switching do you have
[22:32:01] <GuShH> not all of them
[22:32:01] <beaky> that is as simple as GPIOGCR |= 1<<DEBOUNCE
[22:32:10] <beaky> I have a pushbutton
[22:32:30] <Casper> RC debounce circuit
[22:32:32] <GuShH> tons of debouncing methods you can use
[22:32:38] <Casper> delay code
[22:32:40] <beaky> ah
[22:32:41] <GuShH> on softwrae you can just average multiple samples
[22:32:54] <beaky> averaging sounds nice
[22:32:56] <beaky> or _delay_ms
[22:32:59] <GuShH> and use a threshold value
[22:33:02] <GuShH> lots of ways to do it
[22:33:39] <GuShH> sometimes a tiny cap in parallel works just as well, but it relies on inherited delays from other code running in the system if it's not done with a hardware timer!
[22:34:04] <GuShH> so sometimes it'll work, sometimes it won't... not a good solution
[22:34:07] <GuShH> if you add the R component it'll be a lot more reliable
[22:34:19] * GuShH sneezes on Casper
[22:34:20] <beaky> ah
[22:34:33] * Casper burps in GuShH's face
[22:34:33] <beaky> alright I will go witht he RC circuit
[22:34:38] <beaky> but aren't RC circuits funky?
[22:34:57] <Casper> funky?
[22:35:05] <beaky> they are nonlinear
[22:35:08] <GuShH> funky was Casper's burp
[22:35:12] <beaky> ah
[22:35:22] <GuShH> what did you eat!
[22:35:37] <theBear> slap guitar and wah is funky !
[22:35:41] <theBear> level42 is funky !
[22:35:45] <theBear> or is it level43 ?
[22:35:49] <GuShH> wahwah
[22:35:49] <theBear> either way, funky 1
[22:35:52] * Casper farted...
[22:35:56] <GuShH> funky town!
[22:35:57] <Casper> ... I must be very healthy...
[22:36:13] <GuShH> by the smell of your place... you must be very dead on the inside
[22:41:49] <theBear> oh, i am
[22:41:53] * Casper throws a popstickle stick at GuShH
[22:42:42] * Casper puts a suspicious capped beer bottle in a corner
[22:50:07] <theBear> suspicious eh ? snooping around, asking you questions ?
[22:53:48] <beaky> how do i protect my dragon?
[22:53:59] <GuShH> cocaine
[22:54:20] <theBear> keep knights away from it
[22:54:37] <beaky> atm i keep it in its box
[22:54:52] <beaky> and cut holes for the usb jack \
[22:55:08] <beaky> and just have a ribbon cables out for JTAG/ISP
[23:33:49] <Casper> beaky: if you are so worried, use an anti-static wrist band... and don'T short anything
[23:33:57] <Casper> but avr are quite robust
[23:34:29] <beaky> ah
[23:34:42] <beaky> I once connected mine to 15V
[23:34:53] <beaky> it became very hot and started to smell funny
[23:35:06] <beaky> I wondered why my firmware wont run
[23:35:53] <Casper> yeah, that will kill it
[23:36:22] <Casper> (5.6V zener in parallel with the supply, and an inline fuse can help for that)
[23:37:31] <beaky> ah
[23:54:59] <braincracker> beaky<= digital filter