Back
[00:31:30] <gorroth> the linux simulators suck
[10:36:53] <inkjetunito> good day
[10:38:29] <inkjetunito> anyone happen to know where to find the voltage ratings of old ceramic disc capacitors? these are large and orangisch, with only capacitance printed on them
[10:47:37] <inkjetunito> see when it breaks and divide the voltage by 3?
[10:47:42] <inkjetunito> :p
[10:55:34] <Snert__> I never saw an old disc ceramic rated at 5v
[10:55:43] <Snert__> mostly 35 or 50v
[11:01:04] <inkjetunito> thanks
[11:02:52] <Snert__> that was way back when we really didnt have much that ran at 5v ....12v alot of the time and thay just built 50v.
[11:03:27] <Snert__> 35-50 is a pretty safe assumption if you're trying to do 5v logic.
[11:04:28] <Snert__> but as always I'm sure there were expensive 12v rated disc ceramics I suppose.
[11:04:56] <Snert__> kinda unlikely that yours would be one of them but never know I guess.
[11:18:39] <sebus> inkjetunito "these are large and orangisch" -> most likely Snert__ provided right answer. Some are rated up to 63V iirc and HV-like disc caps usually are rated with additional code / label like this one
http://img.weiku.com/IMG_1%5C%5C0000%5C368%5C886High_Voltage_Ceramic_Capacitor_472K_Y5P_1KV_.jpg
[11:21:44] <Snert__> those are 1KV rated.
[11:22:56] <inkjetunito> yeah. i was hoping to have something in that range, but the ceramic coating is very thin when compared to the 1,5 kV ones i found. so 35-50 V would likely be a safe guess
[11:23:02] <inkjetunito> *a safe range
[11:23:42] <Snert__> I always liked mylar. Much nicer looking cap. Not so rotgut.
[11:24:52] <inkjetunito> heh. theoretically i have the best possible component availability in europe, but the online payment methods are ancient
[12:02:44] <sebus> New AT28C64 eeprom failed after several erase/program cycle. Sounds a bit wierd to me. :/
[14:07:03] <gorroth> hmm, didn't notice that when i moved from the atmega88, which i temporarily bricked, to the atmega168, the SPM_PAGESIZE was double the length. so no wonder my lights blinked less than i thought they would
[14:07:21] <gorroth> anyway, got my code up in atmel studio, and i can finally see all this now in a simulator/debugger :-D :-D :-D
[14:13:01] <antto> u know that's cheating
[14:18:21] <gorroth> any of you know how to make atmel studio start from the bootloader section and set simulator fuses and all that?
[14:18:32] <gorroth> or set lock bits or anything
[14:25:00] <gorroth> found it :)
[14:25:07] <gorroth> i had to click the magic buttons
[15:13:03] <kristoiv> Hello everyone! I've been struggeling for days with this weird problem related to interrupts. My code works perfectly, uses no interrupts, but if I so much as activate global interups (sei();), weird stuff starts happening
[15:13:20] <kristoiv> Specifically writing variables to 0x00 often becomes 0x14
[15:13:47] <Jartza> very hard to say anything without seeing the code
[15:14:47] <kristoiv> Jartza: The code is rather large. Spans about a 1000 lines
[15:15:45] <Jartza> well, if it's not secret, pastie.org it
[15:16:42] <Jartza> and then give link to it and tell the line where problematic things happen :)
[15:18:19] <kristoiv> Jartza: It does contain some secret parts, and the problem isn't really a line. Setting values to zero stops working when global interrups are enabled.
[15:18:43] <Jartza> what values?
[15:19:32] <Jartza> do the interrupt handlers touch those variables?
[15:20:00] <Jartza> and btw. what chip this is?
[15:20:07] <kristoiv> Now I'm seeing the problem in arguments to methods. "Breakpoint 3, PCD_CommunicateWithPICC (command=0xc, waitIRq=0x30, sendData=0x8010c2 "&\n\001", sendLen=0x1, backData=0x80010a <tbuffer> "", backLen=0x800100 <tbuffer_len> "\222@@", validBits=0x8010c1 "\a&\n\001", rxAlign=0xe, checkCRC=0xe)" <-- the last ones there are supposed to be 0x00, but are 0x0e
[15:20:53] <kristoiv> Jartza: Nope. No interrupts in use. Just activating to debug this problem as the more complex interrupts based code didn't work.
[15:21:17] <Jartza> could it be possible that you run out of memory?
[15:21:21] <kristoiv> But I had the same problem using a "volatile unsigned char state"-flag
[15:21:29] <Jartza> so the stack vollides with your variables
[15:21:34] <kristoiv> Jartza: Nope. I have like 3kb left
[15:21:34] <Jartza> collides*
[15:21:46] <kristoiv> Jartza: I checked using a freeRam method
[15:22:51] <Jartza> so, what avr it's running on?
[15:23:04] <kristoiv> Jartza: atmega644p using 1mhz
[15:23:05] <kristoiv> internal
[15:23:37] <Jartza> oh mmkay, quite big then
[15:25:28] <Jartza> interrupts shouldn't affect setting variables as such, unless your interrupt vectors are bonkers
[15:27:39] <kristoiv> Jartza: hmm. Maybe I can uncomment them, just in case. Are there any requirements that have to be set before calling sei()?
[15:27:43] <Jartza> but there are plenty of possibilities, starting from "wild" pointer to wrong interrupt vectors or something
[15:28:32] <Jartza> not really, except of course you should have necessary interrupts enabled before calling sei()
[15:29:01] <Jartza> which actually compiles to single assembly sei opcode
[15:30:09] <kristoiv> Jartza: So, what if I have none enabled and call sei?
[15:35:14] <kristoiv> Jartza: I tried doing sei(); cli();, then my code. Now it works again. There is something corrupting my non-interrupt based code any time I activate interrupts
[15:42:56] <osteri> kristoiv: remember to assign bigger than 8-bit values inside ATOMIC-blocks, volatile doesn't matter
[15:44:00] <osteri> kristoiv: in case you didn't know
http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html
[15:44:23] <kristoiv> osteri: Thanks! The values I'm struggeling with are all 8bit. I'm currently looking into if my disabling optimizations in gcc is the reason behind this
[15:49:44] <osteri> if all variables are 8-bit it shouldn't matter, only 16-bit and bigger that are shared between main and interrupt code
[16:04:33] <Jartza> kristoiv: if you have no interrupts enabled, sei sets the global interrupt flag in sreg but no interrupt is launched
[16:07:04] <kristoiv> Jartza: That is great. But still, if I write code that looks like this: myFunctionCallWhenSeisEnabled(someVar, 0, false); Then my debugger (gdb over jtag) tells me that it was called as: myFunctionCallwhenSeisEnabled(someVar, 0xe, 0xe); (bool is defined in stdbool.h as false=0)
[16:07:20] <kristoiv> Variables that are not constant survive
[16:33:31] <kristoiv> If I turn off all optimizations completely (-O0) and cli()-before my method call, and sei() after, then it works again
[16:36:26] <Jartza> sounds weirdish
[16:36:34] <Jartza> what gcc version?
[16:39:39] <Jartza> it's almost like the ISR doesn't push/pull stuff correctly or something
[16:45:02] <kristoiv> Jartza: gcc version 4.8.1 (GCC). (avr-gcc from CrossPack-AVR-20131216)
[16:45:54] <kristoiv> Jartza: Yeah, this is really confusing and demotivating. I feel like this isn't supposed to happen xD
[16:47:39] <Jartza> it's not :)
[17:00:37] <Jartza> kristoiv: anyway, very hard to help much without any code
[17:01:05] <kristoiv> Jartza: Yeah I get it. Thanks anyway :)
[17:04:12] <Jartza> kristoiv: do the interrupt-functions have "naked" word in them?
[17:04:19] <Jartza> ...by any chance
[17:06:34] <kristoiv> Jartza: No. I commented out all my interrupt functions as my main function doesn't enable any of them before the return statement. I'm currently only running non-interrupt code and seeing the problem appear if I prepend sei();, but there is no problem if I comment it out.
[17:06:49] <kristoiv> My entire interrupt interface is the "sei();" call
[17:17:40] <Jartza> and you have verified inside the called function that the _value_ of the variable is 0x0e instead of 0?
[17:18:42] <kristoiv> Yes. I can step through using gdb. Print the vars live
[17:19:10] <kristoiv> I also checked a function call deeper, to see that the stack wasn't overrun somehow, but parameters (even 0x00) works further down
[17:23:45] <Jartza> that sounds weird
[17:24:42] <kristoiv> Jartza: I'm so f'ing tired of this. Maybe I can just always wrap my calls in cli and don't opimize the code ... xD
[17:27:01] <kristoiv> Jartza: Thanks for all your help. I'm going to quit for the evening. I'm angry, exhausted and hungry. Not a good combo for solving especially illusive problems.
[17:27:10] <twnqx> so i'm not the only one with fun code problems :)
[17:27:28] <kristoiv> twnqx: No ^^,
[17:27:32] <twnqx> i had to hunt down a segfault earlier today that just went away when i ran the program in gdb...
[17:27:43] <kristoiv> twnqx: hahaha
[17:27:50] * Xark notes all "code problem" are "FUN problems". :D (unless they are not)
[17:28:06] <twnqx> in the end it was just an array out of bounds access
[17:28:25] <twnqx> due to a totally wrong constant in data that feeds a code generator :D
[17:28:33] <twnqx> off by a few undred MB even.
[17:28:42] <kristoiv> twnqx: You'd think so here too, but it's mostly plain c code.
[17:28:50] <kristoiv> And it works unless I set the global interrupt flag
[17:29:05] <twnqx> then i found that some months ago i accidently cut&paste code i meant to copy&paste
[17:29:22] <twnqx> so i was missing a very crucial line
[17:29:33] <twnqx> this project is just to large
[17:29:43] <twnqx> 6000 lines + ~15000 lines generated
[17:39:45] <Xark> twnqx: Using source control? :)
[17:39:58] <twnqx> git
[17:40:32] <Xark> twnqx: Cool. It can be really hard to find a bit of missing code without "diff against previous version". :)
[17:40:54] <twnqx> yeah... basically, i told git to show be all commits to that file
[17:41:01] <twnqx> then i saw my hunch was right :P
[20:49:31] <gorroth> omg yes!!
[20:49:42] <gorroth> i wrote some data to the flash from my bootloader!
[20:49:54] <gorroth> i had to break it down into the minimum code possible, but i found out what was missing
[20:50:08] <Tom_itx> now you can build it back up
[20:50:24] <gorroth> yup yup! i actually have the full bootloader in another file; so, i'll just take the fixes over
[20:50:27] <gorroth> :)
[20:50:28] <gorroth> man, i feel stupid
[20:50:55] <Casper> gorroth: oh? just feel?
[20:51:03] <gorroth> lol, you ass
[20:53:16] <gorroth> anyway, thanks for the support, all... now i can get past this and finally move onto getting my xbees going and then use my bootloader to install code remotely
