Back
[00:12:25] <Tom_itx> abcminiuser around?
[02:51:23] <ServTheNick> Has anybody ever seen the problem where you write to EEPROM and read form it with the correct values... .THEN reset the MCU and only read from the EEPROM and then get BOGUS data?
[02:53:01] <Casper> look like a faulty chip
[02:53:02] <Casper> or
[02:53:10] <Casper> code error, or power issue
[02:54:01] <ServTheNick_> SOrry I DCed ...did anbody say anything to my message?
[02:54:43] <Casper> <Casper> look like a faulty chip
[02:54:43] <Casper> <Casper> or
[02:54:43] <Casper> <Casper> code error, or power issue
[02:54:43] <Casper> * ServTheNick_ (2985c43d@gate
[02:54:58] <Casper> hmmm woops pasted 1 line over :D
[02:55:53] <ServTheNick_> Are you sure? I have a TON of these chips and I also accidentally placed a 12V source on one of its pins but it still seems to read ADC values just fine
[02:56:30] <ServTheNick_> Thing is how do I work out if I have a power issue? And if it was a power issue why would I be able to read the correct data from it but only if I restart the MCU I get bogus data
[02:58:06] <ServTheNick_> Casper: But thats the only 3 viable errors anyway haha
[03:04:34] <Casper> do you have a decoupling cap across the power pins?
[03:05:02] <ServTheNick_> yes... 1000uF
[03:05:15] <Casper> that is not a decoupling cap
[03:05:32] <Casper> those need to be ceramic and 0.01-0.1µF
[03:05:58] <Casper> and be as close as possible to the ic pins
[03:06:44] <ServTheNick_> Also...power does not seem to be the issue though since I can read from the eeprom after I wrote to it for that instance. When it is restarted then it can not read properly anymore. It does not make to much sense
[03:07:00] <ServTheNick_> Casper: Yea I actually have that cap on there also
[03:07:22] <ServTheNick_> Casper: I do not get it. Its as if it holds the Data until power down
[03:07:33] <Casper> yeah dosen'T make sense, might be software related
[03:08:21] <ServTheNick_> Casper: ->
http://pastebin.com/tfXhyHzF
[03:08:24] <ServTheNick_> my EEPROM functoins
[03:08:33] <ServTheNick_> Normal AVR Doc functions
[03:08:41] <Casper> too late for me to analyse code
[03:43:37] <ServTheNick_> Casper: About to go to bed or something?
[03:44:03] <Casper> I'm about to
[03:44:32] <ServTheNick_> Casper: Mmmkay
[03:44:50] <Casper> was hungry, so had to eat
[03:45:01] <Casper> now, will soon go to bed again
[03:45:02] <ServTheNick_> Casper: I see
[04:14:29] <gorroth> i do believe it was Casper that got me using shunt caps
[08:01:11] <cart> Is it possibly for the Serial Communication to lock up the MCU?>
[08:03:28] <cart> possible`
[08:09:19] <Lambda_Aurigae> yes.
[08:09:26] <Lambda_Aurigae> depending on how your software is written.
[08:13:57] <cart> Lambda_Aurigae: Well I have never had such a problem...tell me...if I accidentally placed 12V on an ADC pin... Could that blow up the ADC making it forever WAIT for the sample to finish?
[08:14:46] <cart> Lambda_Aurigae: also -- >
http://community.atmel.com/forum/atmega-328p-works-fine-breadboard-replacements-do-not-0
[22:36:42] <rue_house> yes
[22:37:01] <rue_house> if you push 12V into an adc pin it will blow things up
[22:37:29] <Thrashbarg> heh
[22:38:14] <rue_house> he must have a clocking problem too
[22:38:37] <rue_house> dunno why, they should come defaulted to internal RC
[22:39:11] <Casper> hey rue_house
[22:39:15] <rue_house> hey
[22:39:33] <Casper> do you have experience with raspberry pi as a media player?
[22:39:50] <rue_house> nope!
[22:40:07] <Casper> :(
[23:13:10] <gorroth> any of you know if avrdude sends the hexfile start code (:) when it's connected to serial?
[23:18:18] <Casper> it do not send the hex file
[23:18:58] <Casper> it convert it to binary, with the proper packet length, with the address decoded then recoded and all...
[23:20:07] <gorroth> hmm, okay. then it must be that when people write bootloaders and then people send data to them, they must using something other than avrdude
[23:21:42] <Casper> basically, the line is: address record type data multiple lines of that.... avrdude look for "flash data", find the address, transpose that to flash page, figure out if it need to pad the begening, then read enought data to fill one page, if not enought it fill it up. then it talk to the bootloader and tell it "erase page X, fill buffer with this data, write page x" and repeat
[23:21:59] <gorroth> yeah, i know what hex records look like
[23:22:22] <Casper> there is however some bootloader that accept hex directly, but those tend to be big
[23:22:42] <gorroth> okay, yeah, the boot loader i'm looking at looks like it takes hex directly
[23:23:09] <gorroth> but you're saying that avrdude will send the raw binary of the hex lines to the uart
[23:23:22] <gorroth> which would actually make my code a little simpler, since it won't need to decode the ascii bytes
[23:24:01] <Casper> it would be a bit stupid when you have a pc side application to make the bootloader work harder and waste the precious flash space
[23:24:18] <Casper> specially since if you need more space you need to double the reserved space...
[23:24:50] <Casper> oh midnight... better take that shower...
[23:29:15] <gorroth> Casper: that might be, but i'm going on what i saw in a bootloader. i guess they used their own serial sender instead of avrdude, in the end. so let's say you have a line of ihex like :100000000C9434000C9451000C9451000C94510049. avrdude would transmit 0x10 0x00 0x00 .... 0x00 0x49 over the wire?