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.
Home
Help
Search
Login
Register
