How do we know if software has way too many EEPROM writes? - Page 1
Forum section: electronics / general

author: ocset
author_rank: Super Contributor
timestamp: January 29, 2018, 08:12:21 pm
content: Hello,Please help explain why our software engineer has programmed our PIC16F18856 microcontroller to write to its EEPROM for 15 seconds continuously when it only needed 5ms to do this?As you know, since it should only take 5ms to write to EEPROM (Pg 611 of datasheet says so), this means he has done 2999 EEPROM writes which he did not need to do. As such, we are concerned that every time he is writing a byte to EEPROM he is actually doing it 3000 times, instead of just once. –As you know, after so many EEPROM writes, a microcontroller EEPROM dies. It looks to me that he has been deliberately trying to kill our microcontroller in our lamp, and thus bring the lamp’s life to a premature end.The lamp periodically stores ambient light readings into microcontroller EEPROM. (These light readings are obtained through the micro’s ADC after reading a SFH5711 light sensor). The readings are taken several times per day…..once every 15 minutes.We are actually concerned because we only discovered that he was doing this 15 seconds worth of EEPROM writes when we realised that the microcontroller consumed over 5mA for the first 15 seconds after being switched ON. If we hadn’t have noticed this and challenged the software guy about this, it would never have come to be known what was actually going on.. After being switched ON, the lamp should just take one light reading and store it to EEPROM.....this should take only 5ms, not 15 seconds. Another point is that the micro is fed by a linear regulator which feeds off rectified mains, so this heavy writing to EEPROM is overheating the linear regulator that supplies the micro.For all we know, the lamp may, at some time in the future , embark on continuous EEPROM writes, which would kill the lamp……he has obviously no control over what he is doing with EEPROM writes…unless of course he is deliberately trying to destroy our company…what do you think?PIC16F18856 datasheethttp://ww1.microchip.com/downloads/en/DeviceDoc/40001824B.pdf

author: fourtytwo42
author_rank: Super Contributor
timestamp: January 29, 2018, 08:30:37 pm
content: I have to say the ongoing conspiracy theories at your company are highly entertainingAre you sure OUR hardware and OUR software engineer are not in fact yourself ?Did you track down the enemy agent destroying your streetlamps in Budapest or wherever it was ?

author: capt bullshot
author_rank: Super Contributor
timestamp: January 29, 2018, 08:33:25 pm
content: Sounds like pure stupidity to meYes there are SW guys that work that way out there (doing some stupid mistake by mis-reading the datasheet, or solving a PEBKAC in a "clever" way) . Congrats on finding one

author: rstofer
author_rank: Super Contributor
timestamp: January 29, 2018, 08:48:22 pm
content: If you don't have a formal 'code review' process, it's your company's fault. Every single line of code should be reviewed by a panel of experts. Not just another 'contractor'.There should be a similar hardware review process. You can't let some kid design a product and just hope it all works out. There are real EEs who do this kind of thing for a living.Mistakes happen even with formal code review. But there are a lot fewer of them!I'm surprised your company is still in business.

author: nctnico
author_rank: Super Contributor
timestamp: January 29, 2018, 08:50:46 pm
content: Quote from: rstofer on January 29, 2018, 08:48:22 pmI'm surprised he still works there

author: T3sl4co1l
author_rank: Super Contributor
timestamp: January 29, 2018, 08:52:46 pm
content: Quote from: rstofer on January 29, 2018, 08:48:22 pmAlas, there's a disturbing amount of free money out there, even (especially?) if you skimp on engineering budget.Tim

author: mariush
author_rank: Super Contributor
timestamp: January 29, 2018, 08:55:16 pm
content: Why don't you post the source code here, maybe removing any proprietary information... if we're bored, maybe we can give you some code reviewIt's not like someone here would clone your product.Maybe he's erasing each byte one at a time, reading back to verify it's erased, then writing just a bunch of bytes.How much data is that light information ? If you want longer life or a more even write spread, maybe you can keep in that eeprom the last 20-50 or so measurements and loop through those overwriting the oldest one with the newest measurement.

author: ocset
author_rank: Super Contributor
timestamp: January 29, 2018, 09:04:22 pm
content: Thanks, may i ask , is it the EEPROM writes which make the high current draw of the micro?Because we understand that every micro has only a limited possible number of EEPROM writes before EEPROM dies.We know that the current draw was way excessive for 15 seconds immediately after switch on...and the software guy has confessed that that is because of EEPROM operations........i presume he must mean writes? (he should mean writeing because the lamp should take a single light reading shortly after switch-ON and store it in EEPROM).......Presumably you can read EEPROM as much as you like and it means no high current draw of the micro and does not impact the life of the micro?The ADC reading of the light level, is, i beleive, either an 8 bit byte or 16 bits.......i am sure its nowhere near long enough to take 15 seconds to write to EEPROM.I think we've been done over.I reckon the software guy, ( who lives in another country) will say its a mistake. But i am not sure how you can make that kind of mistake..without it actually being deliberate.I understood that my company had gotten another software guy to inspect the code.QuoteThanks, so you mean the EEPROM may not die quickly, like we thought it might?...in other words, there may be hope for us yet?

author: Gyro
author_rank: Super Contributor
timestamp: January 29, 2018, 09:04:38 pm
content: Quote from: rstofer on January 29, 2018, 08:48:22 pm^^ What he said!Quote from: treez on January 29, 2018, 08:12:21 pmWhat a very strange question to ask - why shouldwebe explaining it - your software engineer should be doing that.When you say "our software engineer", I assume that you mean the software engineer of the company in China that you are buying your product from.You need to take FAR greater control of your supplier's development strategy and processes than you currently are if you are to stand any chance of staying in business. You should be closely reviewing the design process, every step of the way.Do you even have a copy of the source code? If not, then you have no reasonable chance of controlling the project.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 29, 2018, 09:15:48 pm
content: Quote from: treez on January 29, 2018, 09:04:22 pmThere's your problem.Can you seriously not find anyone local to do the job?or at least just do code (and hardware design) reviews.What does the source code look like?If the answer is "we don't have it" then this simply an incompetent product design process.From what you have posted it seems you don't even know if that's actually what happenned and are jsut taking the word of an idiot.

author: ocset
author_rank: Super Contributor
timestamp: January 29, 2018, 09:22:58 pm
content: I have some of the old source code...there's been so many code re-writes, so many bugs , that i personally dont know where the code is.....my boss knows. So do our software test guys, who also do many other jobs in the company.I usually work on the hardware......thats why i noticed the input cap to the linear regulator that feeds the micro was getting pulled right down to dc negative and realised that high current was being drawn, and that it could only be the micro doing this.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 29, 2018, 09:24:57 pm
content: I wouldn't expect writing eeprom to draw appreciably more current than running.Excess current draw is more likely due to selecting the wrong clock, i/o clash or floating input pins.What is the actual current draw you're seeing in the first 15 secs, and afterwards ?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 29, 2018, 10:19:27 pm
content: With MCU based products you just can't get by with having a seperate "hardware guy" and "Software guy". Both must have a good knowledge of the other's field.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 29, 2018, 11:31:37 pm
content: EEPROM endurance is listed in the datasheet, usually 100,000 erase/writes.If the software writes to EEPROM for 15 seconds, it is probably not writing the same byte, but different bytes. So, it's a very little chance you kill the EEPROM during just few starts.You're telling this amazing stories about your software guy doing lots of stupid mistakes, but you don't want to fire him anyway. I don't believe this.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: January 30, 2018, 12:11:29 am
content: Back to the original question: You would either have to take a look at the sources to see what is going on at startup or use an in-circuit debugger (MPLAB ICD or PICkit).Personally I would not bother with either. Simply ask the programmer - even if you do not get a sufficient answer, that might be your answer (-> code review et al.).

author: rstofer
author_rank: Super Contributor
timestamp: January 30, 2018, 02:52:41 am
content: You really need a formal version control system. That way changes are tracked.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: January 30, 2018, 05:01:00 am
content: Quote from: treez on January 29, 2018, 08:12:21 pmParanoid much? Cock ups are nearly always incompetence not conspiracy.Your company obviously does not have sufficient control of your software development, that is a management problem. Sounds like someone there is trying to destroy your own company.But maybe even that function is outsourced nowadays.

author: TJ232
author_rank: Frequent Contributor
timestamp: January 30, 2018, 05:36:41 am
content: OMG, another "treez production" story.Your saga looks like a heavy run after any possbile mistake that can be done in terms of business development, project management, hardware/software development, testing, etc, you just name it. I have seen a lot in 25 years of engineering but this one is way to muchIf somebody can find any silly mistake that treez can say they didn't done it, I think it should be posted here for posterity.PS: I still don't believe that all these stories are real, but at least they are very good examples that can help starters in building their own DO_NOT_EVER_DO_IT_IN_THAT_WAY checklist.

author: ocset
author_rank: Super Contributor
timestamp: January 30, 2018, 06:15:21 am
content: QuoteThanks, so each byte of the eeprom can be written 100000 times before that byte dies?...so for a 256 byte eeprom like the pic16f18856, we have 25.6 million eeprom writes before it fails?QuoteI think its an EU grant, and we have to pick someone from a different EU country other than our own.QuoteThanks, strangely the datasheet doesnt say how much current is drawn when eeprom is writing.Sorry i do not understand what is meant by "i/o clash", please could you possibly advise?( i think it means an input has accidentally been declared as an output and this output is possibly soucing loads of current....this is possible with us because we have dipswitchs to inputs which go direct to ground...so if these were declared as outputs then lots of current would flow to ground from that pin....recently, our software test guy noticed that the micro rail was short-circuit, but only when one of the dipswitchs was switched to ground)We also wonder whether he is doing repeated ADC readings of the light reading...and maybe thats drawing this excess current?Strangely the elec specs of the micro dont tell what is the current draw of things like ADC or EEPROM writing/erasing etc.I must admit i am surprised it can write to its EEPROM with just a 2v5 rail...i thought writing to eeprom took 9v or so?The normal running current for the 2V5 rail is 2.2mA. Thats the micro and some really low current drawing things like SFH5711, MCP9700 and an opamp buffer with an output resistor of 100k........so the 7.5mA of current draw we see at startup is unquestionably from the micro.

author: Nusa
author_rank: Super Contributor
timestamp: January 30, 2018, 06:24:42 am
content: In any case, if the eeprom fails to write, your software should fail in a manner that gives the light basic function as a default case -- you've still got the real-time sensor reading, after all.What, you didn't think of those things in the design? Who's fault is that?

author: djococaud
author_rank: Regular Contributor
timestamp: January 30, 2018, 07:33:23 am
content: Just a thought :What if the micro just measures the light one time each second, do it 15 times and then averages it and store the value in the eeprom ?Thats would be only one eeprom write and 15s of full speed micro activity (doing nothing between measures, wich causes the regulator to overheat).(Then, the regulator could olso be undersized)...

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 30, 2018, 09:44:53 am
content: Quote from: treez on January 30, 2018, 06:15:21 amYes. Incorrectly setting input pins as outputs.QuoteNo - ADC won't draw that much. You may want to do multiple readings to avarage out values to reduce noise.QuoteWhich is why I doubt the draw increases significantly when writing, thought may be that it's for a short enough time that they don't think it's worth documentingQuoteIt does. There is an on-chip charge pumpQuoteThis is exactly why hardware people need to know enough software to be able to write some trivial code in a few minutes to fire up the MCU and check current draw in various situations.Looking at the datasheet, 7.5mA is twice the max current spec at the highest clock, so something odd is occurring - continuous ee write is one possibility, probably too low to be an I/O clash but could be a floating input pin.Do not spend another second on this until you have the source in front of you - it's just a waste of time guessing until you know exactly what is happenning.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: January 30, 2018, 10:39:20 am
content: Quote from: mikeselectricstuff on January 30, 2018, 09:44:53 amThis.

author: JPortici
author_rank: Super Contributor
timestamp: January 30, 2018, 10:45:10 am
content: which is exactly what they keep telling him at the microchip forums

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: January 30, 2018, 11:25:47 am
content: I get that an external consultant is used, that is actually quite common. I also get that the contract may be offset by grants or subsidies, I've worked in some of those. But it's sheer insanity to enter a contract where the scope of supply is to only provide binary files, and not *at least* source, more likely also requiring some design documentation, precise instructions on how to build.The first thing I do when using an external consultant is to get someone in house to build the software and verify that the binary is byte for byte exactly the same as the delivered binary. Otherwise, it's like you have just loaded a gun and pointed it at your head.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: January 30, 2018, 11:49:53 am
content: Quote from: treez on January 29, 2018, 09:22:58 pmThe OP mentioned that there are sources somewhere in the stratosphere, but it really sounds like very badly managed. Could as well be, that something is buried somewhere in a cluttered folder structure telling you: Important_final_version_edit2_bugfixes.zipBesides the imminent problem of not knowing what is going on with a certain product, I would highly suggest to spend some money on audit, process management and a reliable version control system. This does not even have to be overly complicated and it will greatly increase the level of convenience for everyone involved in new projects also.Also, it sounds like code that a lot of different people "fixed" occasionally.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: January 30, 2018, 12:17:34 pm
content: Quote from: frozenfrogz on January 30, 2018, 11:49:53 amI get the impression it is one of those "one man and his dog" type companies, where employees jealousy guard their little domains and don't cooperate well. Management is either ineffective or unable to change personnel because they have made themselves indispensable. Hiring a cheap replacement and training them up is too disruptive for small companies. Auditing and process management (or any sort of quality approach) are purely theoretical concepts for them. I speak from experience...The fact that employees are desperately seeking solutions on web forums is a sign that the company is beyond repair.

author: abraxa
author_rank: Frequent Contributor
timestamp: January 30, 2018, 02:07:45 pm
content: I'm surprised people here are so quick to dismiss the possibility of deliberate sabotage. What if the firmware developer feels scorned and wanted to add something that won't cause a problemnowbut will break the product much later, when he's long gone? I wouldn't be surprised.

author: wraper
author_rank: Unknown
timestamp: January 30, 2018, 02:11:48 pm
content: Quote from: abraxa on January 30, 2018, 02:07:45 pmBecausetreezalready wrote so many fairy tales that many people think about all of this as a nothing but a joke. It's like everyone around is sabotaging, including UK with it's mains voltage.

author: andersm
author_rank: Super Contributor
timestamp: January 30, 2018, 02:11:59 pm
content: Quote from: abraxa on January 30, 2018, 02:07:45 pmMainly because the OP hasn't posted anything except really wild claims and speculation. Whatever's going on at their company, it's not a technical issue, but management and personnel problems.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 30, 2018, 02:12:26 pm
content: Quote from: treez on January 30, 2018, 06:15:21 amIf it writes evenly to all bytes then yes. If it writes to only one location, the will wear out sooner. There are different algorithms which distribute write to prolong the life.The power is specified at 5 mA max during programming (in the table 3-3 of the Programming Specification, parameter IDDP), which IMHO includes EEPROM programming, so 7.5 mA is too much.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 30, 2018, 02:49:52 pm
content: Quote from: abraxa on January 30, 2018, 02:07:45 pmGiven the choice between incompetence and conspiricy I'd say the former is the most plausible.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: January 30, 2018, 03:43:06 pm
content: Quote from: abraxa on January 30, 2018, 02:07:45 pmEven if for the sake of argument, we assume that there is deliberate sabotage, the advice would be to get the source code, then cut contact with this developer. Do it in house or find someone competent (and honest).That is the same advice we have been giving anywayI did some endurance testing with a Microchip serial EEPROM, the results were interesting, but the technology used may not be the same as on the MCUs. Anyway, our rule of thumb is one write every hour stays within the limit of 100K writes, for a 10 year product lifetime. When I hit about 5 million cycles, errors started to appear, but the failure mode was not how I expected.The investigation was prompted by a colleague who accidentally triggered an EEPROM write several times a second, and I left the code running over a weekend which killed the part of EEPROM being written to.

author: C
author_rank: Super Contributor
timestamp: January 30, 2018, 05:42:57 pm
content: Think about what could be done by firmware to kill device.If programmer really wanted it to fail, power up is not the best time to hide killing EEPROM. This is stupid programming error area.Long term too many writes to EEPROM is not playing by rules limits & easy to hide error.Your 15 minutes writes to EEPROM is to get history. Would not be that hard to hide increasing writes over time, would just have to not update last history value location on every write.incompetence is easy, just need a value going out of range to cause a failure.

author: dmills
author_rank: Super Contributor
timestamp: January 30, 2018, 11:56:24 pm
content: Post the source (And the real schematics, not some butcherised thing in spice!), nobody here is going to copy the piece of shit, nobody here needs the pain.At this point folks here around would I suspect take such a set of design files as a 'spot the cockup' contest!This is almost certainly just a bug and may well not involve the eeprom at all, I would bet on some floating inputs, but who knows without seeing the real diagrams.As to a cockup Treez has not yet claimed, I will admit to a tin/gold connector pair choice 'issue' that only became apparent after we had a couple of hundred units in the field (Expensive!). Obvious enough once we got some back, but embarrassing as all hell because I knew about the problem.This sort of crap is what design reviews are for!BTW: SVN is a free version control tool, reasonably good and works well for both software and hardware design files, the cool kids are all pushing GIT like mad, but SVN is simpler if you have never used such things and works well, you will quickly wonder how you ever lived without versioning.Regards, Dan.

author: MT
author_rank: Super Contributor
timestamp: January 31, 2018, 06:56:14 pm
content: Quote from: wraper on January 30, 2018, 02:11:48 pmTreez actually "thanked" your post! That's quite some achievement either way..

author: Psi
author_rank: Super Contributor
timestamp: January 31, 2018, 07:28:30 pm
content: I'd laugh so hard if the 15s was some crazy implementation of wear leveling where every bootup it moves all eeprom data by 1 byte so data slowly moves it's location across all ee memory.

author: fourtytwo42
author_rank: Super Contributor
timestamp: January 31, 2018, 07:54:43 pm
content: Quote from: Psi on January 31, 2018, 07:28:30 pmNow that could easely be the case if it's some rubbish C library code garnered from somewhere!IMOP many dont know how to write software or design hardware anymore, they just cobble together a load of stuff seen on the web, after all they got used to that method getting there degrees and phd's right

author: T3sl4co1l
author_rank: Super Contributor
timestamp: January 31, 2018, 08:10:58 pm
content: Quote from: MT on January 31, 2018, 06:56:14 pmIf you've been paying attention (I don't mean this perjoratively: just that, others here have been following this slow-motion train wreck for dozens of threads), you'll notice that treez thanks almost every post in reply, even the highly critical ones.Alas, words -- not even words, the mere press of a button rather -- are rather shallow. I'll pay attention when "has thanked this post" turns into "has donated $5 in thanks for this post".Tim

author: Delta
author_rank: Super Contributor
timestamp: February 01, 2018, 11:44:52 am
content: EEPROM write times increase with mains voltage. As your superb product is running on the UK's 292 VAC RMS for periods of several minutes, 15s is to be expected.

author: voltsandjolts
author_rank: Unknown
timestamp: February 02, 2018, 07:21:22 pm
content: I'm just posting here to get thanked by treez. This is the best thread I've seen today.

author: imidis
author_rank: Frequent Contributor
timestamp: February 02, 2018, 08:22:44 pm
content: Are we sure it is not a rogue chip that was sabotaged by another company?

author: dmills
author_rank: Super Contributor
timestamp: February 02, 2018, 09:56:50 pm
content: The CIA/NSA/Illuminati/Lizards diddled a C Compiler somewhere back up the chain and pulled a "Reflections on trusting trust" style attack to break eeproms containing keys in a predictable way and this is just a false positive.....Or it is just a stupid bug.Regards, Dan.

author: Ice-Tea
author_rank: Super Contributor
timestamp: February 02, 2018, 11:38:46 pm
content: Quote from: T3sl4co1l on January 31, 2018, 08:10:58 pmThere; fixed it for you.

author: KL27x
author_rank: Super Contributor
timestamp: February 03, 2018, 12:54:47 am
content: Treez: Remember 6 months back, when more than half your units were fail, right out of the box?One of the things we asked was if the working units eventually failed, as well?And remember when we said that if this were the case, this type of behavior is possibly due to bad EEPROM write, probably due to EEPROM values being written too soon after startup? Rather than a read-modify-write error, which you were trying to find?And apparently, you got this problem sorted out, because you have working lamps, now.The coder might have discovered that this was the problem. When you asked about this (perhaps new) behaviour, he did mention something to that effect, right? That's why you are asking about EEPROM writes? And to fix it, perhaps he simply added a startup delay with a very generous margin of safety. This would be perhaps a tiny bit lazy to not get the delay closer to, say, twice w/e the datasheet says is needed. If I were too lazy to look it up, I'd probably throw my dart at ~100-200mS. But this is because I've had the same problem, and I while I don't remember the actual figure for a given PIC, I am pretty confident that 100mS is way more than enough for any of them. (It's also important for anything where EEPROM can brick it that power good and brown out detection are both being utilized). But this 14.8ish seconds is quibbling over nothing. In the bigger picture, 15 seconds of the micro counting sheep before finally doing its thing and going to sleep? On something that runs on mains, and which is switched on/off only a few times a day, and for which the micro max draw is probably not even a tenth of a percent of the total power consumption, 15s is really meaningless.Additionally, if a bad EEPROM write (or a worn out EEPROM) is going to cause some serious/lasting problem, it might be nice to have a valid parameter check/overwrite in the code, so the lamp at least turns on if there is an error. I don't know if that's reasonable for what this micro needs to do, mind you. And it looks like you are not actually coding, just that you're being a backseat driver to your actual coder. (Maybe not very productive if you don't know how to drive). Unless there's some major communication barrier between you and your coder, you should be able to figure out what he did; and he should make a fix if he is not delivering what you originally specified. This may or may not be the case (it sounds like you're chasing a phantom whatif) . Email, man. Copy and paste the technical stuff, here, if you don't understand it. Relaying second or third hand information (he said this/that) is sketchy. If you can't write it yourself, you might not understand what he actually said.If you continue to be concerned (for reasons real or imagined), you could perhaps shoot an email to your programmer. I would simply ask him what is the expected lifespan of the EEPROM. If he bothers to track them all down and count them up for you, he might answer in cycles and/or time depending on what the code is doing, based on the min EEPROM writes in the datasheet. I imagine the guy that wrote it might be able to accurately figure out which EEPROM registers are used the most, insert a few lines of code into the save subroutine(s) to increment an internal software counter or an external counter and output pin, and play with the lamp for you. Sending him a fully assembled lamp or 2 (at least with all the important bits that you plan to use in production) and a few bucks might help him out because he probably doesn't have this hardware, anymore. And this shit doesn't do itself. Esp where human interface/input may be involved with dials and whatnot, it's not necessarily possible to make a decent estimate without a working, assembled, finished product.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: February 03, 2018, 09:11:40 am
content: I've come to the conclusion that this is all part of an elaborate troll. I wonder if this company that is the victim of all manner of unfortunate and improbable events really exists.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 03, 2018, 09:33:03 am
content: Quote from: donotdespisethesnake on February 03, 2018, 09:11:40 amIME the situations are entirely plausible - it may well be that treez is firefighting the results of incompetent management above him.

author: 3db
author_rank: Frequent Contributor
timestamp: February 03, 2018, 12:57:54 pm
content: Quote from: voltsandjolts on February 02, 2018, 07:21:22 pmEpic !!

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: February 03, 2018, 01:28:15 pm
content: Quote from: mikeselectricstuff on February 03, 2018, 09:33:03 amSure, that is one way of looking at it, there are others.

author: janoc
author_rank: Super Contributor
timestamp: February 03, 2018, 03:14:44 pm
content: QuoteI think this is both pretty symptomatic of these threads started by treez:- Wild guesses and fishing expeditions with no evidence or trying to actually verify them- However, ample evidence ofterribly terriblydesigned piece of crap product. If a voltage regulator overheats only because a micro writing an EEPROM (which is a perfectly normal thing for a micro to do), then what is that regulator going to do when it is 40C outside, with Sun frying the metal enclosure? Which is also something a street lamp should be able to deal with.And a linear reg for dropping rectified mains (i.e. some 300V) down to 3.3-5V?!?! I do hope there is at least some pre-regulator there ...Oh and it is always easier to look for intentional sabotage than own incompetence (admitting incompetence hurts and could get one sued). Seriously, dude ...

author: Ice-Tea
author_rank: Super Contributor
timestamp: February 03, 2018, 09:36:28 pm
content: Quote from: janocIn theory nothing wrong with that. Microchip has a few nice LDOs for this purpose.

author: ocset
author_rank: Super Contributor
timestamp: February 03, 2018, 10:11:44 pm
content: Thanks, i have the main.c code now, but they still havent given me the header files.We were just wondering, we realise that PIC16F1704 has 128 bytes of EEPROM.Therefore, to "Initialise" this flash, would need 5ms per byte?That would mean about 640ms seconds would be needed to erase and write each EEPROM byte at startup?We realise this is still way short of the 15 seconds of continuous ~6-7mA of current draw that we are getting from the 2V5 rail.(The other ICs on the 2V5 rail only draw 1mA.)

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 03, 2018, 10:14:48 pm
content: Why would you want to initialise EEPROM at runtime?If you need specific defaults these can be programmed via the hex file when the code is written.

author: BrianHG
author_rank: Super Contributor
timestamp: February 04, 2018, 12:23:18 am
content: Quote from: donotdespisethesnake on February 03, 2018, 09:11:40 amBased on treez's history of posts, I would say he has a company who doesn't have the budget & guaranteed forecast sales to warrant properly getting a loan of enough money to get the right test gear and the right engineers on hand as full time employees to achieve a small to medium sized one time custom purchase order they were lucky to get. Or, unlucky if you take into account all the problems which will end up costing more in the long run than if the project was done with the appropriate budget and personnel from day one.

author: MT
author_rank: Super Contributor
timestamp: February 04, 2018, 01:08:34 am
content: Quote from: T3sl4co1l on January 31, 2018, 08:10:58 pmyes i haved noticed he thanks even critical posts but is there a "requirement" to pay attention?What if i just feel to be lazy and ignorant?Anyho, no have not paid attention to Treez and the other threads but i'm perfectly fine witheveryone else is paying attention to his his eventual train wreck.QuoteYes, i concur and when Dave implemented this i "verbally objected" to it as shallow.QuoteI think you should request at least 10 bitcoins instead of Donald dullars.

author: janoc
author_rank: Super Contributor
timestamp: February 04, 2018, 01:18:23 pm
content: Quote from: Ice-Tea on February 03, 2018, 09:36:28 pmThen I am very curious about model numbers because even an LDO will have to dissipate significant amount of power with such a large voltage drop.If I assume 0.1V LDO drop, I still have:300V - 2.5V - 0.1V = 297.4V, let's say the micro takes 10mA -> that's almost 3W of power to dissipate somewhere. If the thing doesn't have a good heatsink it will likely get really toasty and possibly stop working due to the thermal protection kicking in.What am I missing? Sounds like a very marginal design to me.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: February 04, 2018, 01:50:14 pm
content: Obviously not very practical for such high currents.If typical operating current is a few mA, it's more or less practical. Most small offline switching regulators are powered this way, at least during startup. The efficiency is poor, but it's a 5V 1A USB charger, say; who cares, right?A dropping capacitor on the AC side can also be used.Tim

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 04, 2018, 02:28:11 pm
content: Quote from: Ice-Tea on February 03, 2018, 09:36:28 pmIt wouldn't be an LDO as you don't care about dropout voltage if the input voltage is high - just a linear reg ( vs. switching) .You may want to have a resistor on the input to spread the dissipation and improve surge/transient resiliencee.g.https://www.digikey.co.uk/product-detail/en/microchip-technology/LR8N8-G/LR8N8-GTR-ND/4902851

author: janoc
author_rank: Super Contributor
timestamp: February 04, 2018, 03:29:47 pm
content: Quote from: mikeselectricstuff on February 04, 2018, 02:28:11 pmThanks Mike, I was wondering about this.However, still at least a resistor or a capacitive dropper would be the thing I would prefer to use, followed by a normal regulator, especially if it is meant for outdoors use and things can (and do) get hot.If the OP's regulator is cooking itself because the MCU is drawing 7mA, something isn't right with that design, IMO. An extra cap or resistor would be only marginally more expensive and avoid that problem.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 04, 2018, 03:53:27 pm
content: Quote from: janoc on February 04, 2018, 03:29:47 pmYes, if it really needs 7mA then it needs a cap dropper or switcher. However it appears maybe it was designed on the basis of drawing a lot less and bad software is making it draw more than it should for reasons that are still unclear.

author: Ice-Tea
author_rank: Super Contributor
timestamp: February 04, 2018, 04:57:58 pm
content: Quote from: janoc on February 04, 2018, 01:18:23 pmLR645. Available in TO-220, so you can cool it without much issue.QuoteWithdecentSW and HW design (not to mention choosing a decent mcu), I don't see why the design has to be marginal.

author: mariush
author_rank: Super Contributor
timestamp: February 04, 2018, 05:02:36 pm
content: I think he should also investigate at what frequency is the microcontroller running? Maybe he's running it at 16-24 Mhz, while it could work at 1-2 Mhz or even lower and use less than 1mA of current.As for eeprom, no need to erase or initialize it, makes no sense. By default, the memory is either 0 (0xx) or 255 (0xFF) and you can program it when you program the microcontroller for the first time. ( or, you could add a tiny pad or something on the circuit board that, when connected to ground and you start the light, it does the eeprom erase once)You can reduce the eeprom "wear and tear" by spreading the writes across a larger part of memory.For example, if the data you need to store in memory is 2 bytes, then you can use 3 bytes for each record, and store the last 16-32 records in 96 bytes, leaving you the other bytes for other settings. That one byte you use to keep track of which record is the last and all that, for example just use numbers between 1 and 254 (because 0 and 255 tell you it's unused eeprom memory)So at boot, quickly read up to 32 bytes (one byte per record) to determine which is the newest measurement and which is the oldest, then read the 2 bytes associated with the newest record .When you want to write, you overwrite the oldest measurement or use some of the unitialized memory (which you detect by reading 0 or 255 in those header bytes)

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 04, 2018, 05:03:23 pm
content: Quote from: Ice-Tea on February 04, 2018, 04:57:58 pmExactly.Which is why it makes no sense to do this sort of stuff with a third-party software person in one contry and and a hardware person in another unless both are so experienced in embedded design that useful specs can be communicated.In practice one person doing both will be far more productive.

author: mrflibble
author_rank: Super Contributor
timestamp: February 04, 2018, 08:41:12 pm
content: Damn, I never would have guessed this from a thread on excessive eeprom writes. Comedy gold!

author: mrflibble
author_rank: Super Contributor
timestamp: February 04, 2018, 09:04:03 pm
content: Quote from: TJ232 on January 30, 2018, 05:36:41 amYou mean there is more?This was highly entertaining! I'm saving those other threads for later this week. Always good to have some comic relief on standby!

author: TJ232
author_rank: Frequent Contributor
timestamp: February 05, 2018, 06:29:01 am
content: Quote from: mrflibble on February 04, 2018, 09:04:03 pmOh, yeah! Just search the forum fortreezposts

author: T3sl4co1l
author_rank: Super Contributor
timestamp: February 05, 2018, 07:56:02 am
content: Quote from: TJ232 on February 05, 2018, 06:29:01 amEasier to follow the link on the user's profile:https://www.eevblog.com/forum/profile/?area=showposts;sa=topics;u=139928Tim

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 05, 2018, 05:06:49 pm
content: That's a good one!Do you have just one software engineer at your company and isn't anyone else capable of reading and reviewing the code he wrote? If so, you have a bigger problem than you may think anyway.Additionally, the fact that nobody at your company seems to know what your product actually does and that you're thinking of shipping it is very concerning as well.That aside, most EEPROMs are rated for around 1 million of write cycles or more. In your case, I don't know if it's actual EEPROM or just Flash used as an embedded EEPROM in the µC (didn't check). If it's Flash-based, the number of write cycles is a lot less. So that may be even more concerning. There are schemes to circumvent the write cycles limitation, such as distributing the writes evenly in the whole memory space, and of course avoiding unnecessary writes.

author: Quarlo Klobrigney
author_rank: Super Contributor
timestamp: February 05, 2018, 05:27:08 pm
content: Yes correct and so on.. Here's an example of a wrong cycle...

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 05, 2018, 06:14:49 pm
content: Looking at that datasheet - this PIC doesn't have EEEPROM, it has a high-endurance (100K) flash area with a 32 byte row erase size.If you were to do something like write individual values to the whole area one at a time, maybe using a manufacturer library with a "write single byte" API call , chances are it would be reading the row, updating one value then doing a row erase and 32 byte rewrite every time.Datasheet indicates 2ms for row erase and byte writes, so although in principle you could write the whole 128 bytes in 128*2+4*2= about 250mS, it could be a lot longer if the code doing the writes didn't have visibility of the calling code, and so did an read/erase/rewrite for each byte written, which would be around (32+1)*128ms = 4.2 secs, so in the rough ballpark for the OPs quoted 15s timeThe data shows a supply current during programming of 10mA max. Again, in the quoted ballpark.10mA for 128mS from an LDO from mains would be OK, but if the writing was being done in a stupid way, the reported 15s would probably not.or it may be that something is simply browning out and it's getting stuck in a write loop.

author: Buriedcode
author_rank: Super Contributor
timestamp: February 05, 2018, 07:30:56 pm
content: Its pretty clear that if the OP wants help here, he is going to have to post the code, and preferably the schematic.Although one generally wouldn't post code for products in a public forum - the fact treez regularly comes here to ask questions and discuss problems (which is worrying, as surely debugging is part of his job) means he might as well go the whole nine and post the design files. Otherwise we're going to get a steady stream of vague questions as to what *he* believes causes the issues, rather than the issues themselves.

author: MT
author_rank: Super Contributor
timestamp: February 05, 2018, 09:36:36 pm
content: Quote from: T3sl4co1l on February 05, 2018, 07:56:02 amYou have to give some credit to Treez for saying "Hello" in every thread start except for the one that was political!

author: nctnico
author_rank: Super Contributor
timestamp: February 05, 2018, 10:11:53 pm
content: Quote from: mikeselectricstuff on February 04, 2018, 05:03:23 pmYes and no. There aren't enough engineers capable of doing both hardware and software and it will be easier to find a good software engineer and a good hardware engineer. I have been involved in several projects where the software and hardware where done by seperate persons. In the end it comes down to having engineers which are capable of doing a good job.

author: janoc
author_rank: Super Contributor
timestamp: February 05, 2018, 10:35:33 pm
content: Quote from: Ice-Tea on February 04, 2018, 04:57:58 pmThat assumes a lot of things being right, IMO. If this is for an outdoors lighting fixture where large temperature swings are the norm, where a bug in the code can fry it ... I don't know, that doesn't sound like there is a lot of margin for error.Could it be made to work? Probably. Is it robust? I somehow doubt that, especially given the history of OP's posts (like the one about the overvoltage in UK's mains) and the fact that the code is being written by a 3rdparty the OP doesn't control.At the very least a capacitor to reduce the load on the regulator would be my choice. Then the micro can do whatever it wants and it won't kill the device because of some silly EEPROM writing code or something else that will make it draw few mA of current more or longer than usual. Or because the Sun is heating the enclosure up so much that the regulator cannot cope with the extra heat due to the MCU current anymore and shuts off.That's a few cents of hw buying a lot extra margin & protection against newbie mistakes by some intern somewhere who got tasked with writing that code. In the worst case it would be a wasted few cents for an over-engineered solution. There are worse things to waste them on, IMO.Belts and braces ...

author: janoc
author_rank: Super Contributor
timestamp: February 05, 2018, 10:44:21 pm
content: Quote from: nctnico on February 05, 2018, 10:11:53 pmExactly. Usually the hw guys are not that great in software and the sw guys tend to give hw engineers grey hair. And on some projects it is simply unfeasible to do have a single person do everything due the size and complexity.What is more important is to have those two persons/teams actually sit together and constantly communicate and test, not just ship out specs to some outsourcing/contracting outfit and expect working code/hw back (as it often happens - with predictable results).

author: TomS_
author_rank: Frequent Contributor
timestamp: February 13, 2018, 02:14:37 pm
content: Easiest way to get thanks on the EEVblog forum .. respond to a treez thread.Seriously, what is with that? Even posts that seem to criticise and poke fun get thanks!!?

author: 3db
author_rank: Frequent Contributor
timestamp: February 14, 2018, 10:48:43 am
content: :TomS_Even your one.

author: bson
author_rank: Unknown
timestamp: February 14, 2018, 11:01:01 pm
content: To answer the original question, if you have a hardware debugger and can access the chip with it, you can disassemble enough to find the EEPROM writing code and set a hw breakpoint there. Configure the breakpoint to automatically resume and use it to count the number of times that code is executed. If fusing prevents access, see if you can find a copy of the binary/hex/elf file that gets programmed and program it yourself to a blank device using the debugger, then find the EEPROM write code and count using a breakpoint. If it needs to run on the actual board just reflow your own unfused and accessible one onto it.