Product design teams endeavor to plan the safe launch of electronics products to prevent re-discovering issues that should have been learned from the previous project. Many Serial Electrically Erasable Programmable Read-Only Memory (SEEPROM) users have never utilized such components and therefore may not have knowledge of potential issues. Here is a personal story from several years ago when I was asked to support a customer working on an issue on a weekend. (You may have already guessed that the call came to me that weekend was from my boss’s boss’s boss.)
Here’s the issue that was described to me over the phone by the customer engineers (hardware and firmware) while they were in their laboratory troubleshooting:
We exchanged emails with DSO (digital storage oscilloscope) captures of the serial protocol after which I would request another DSO capture or two. Once we were drilling down to the issue, a customer firmware engineer held the phone line while the customer hardware engineers made more measurements. The customer firmware engineer asked me, “Why would someone drive the SEEPROM /CS signal low (true) and then back high (false) with no clocks or data in?” I quickly whipped out, “That is a chip select toggle that is utilized to recover from power interruption of the host microcontroller or from a protocol violation, and we have a Juraasic period FAQ about that buried deep in our website.” The customer firmware engineer said, “Uh oh, I didn’t know why anyone would do that, so I took it out.” Soon, the hardware engineers emailed me a DSO capture showing a protocol violation and then no communication from the SEEPROM. I announced that the firmware engineer has the solution to this issue and should be able to produce a new firmware build to mitigate this situation in the future.
Several product lines were brought to a standstill because the task to reduce firmware lines of code took precedence over why the code was there to begin with. Numerous engineers (including myself) have worked weekends unnecessarily. The moral to the story is that if you have product firmware that communicates properly with an Atmel SEEPROM and you do not know why a few lines of code exist, then you may want to ask yourself about the expected benefit of modifying that code before you throw the baby out with the bath water. Sometimes things are there for a reason that may not be all that obvious.
Stick to the adage: “When in doubt, don’t leave it out.”
Oh, and one more thing… Please comment your firmware source files adequately to help the next firmware developer. Remember that person may just end up being a future version of you!
This blog was written by Clay Tomlinson, Atmel Staff Applications Engineer