My customer has recently gone into production with the CC1110 for range of RF ID products and have come across some odd issues.
One of the issues in a number of case was the last page of flash ROM becoming erased. Their configuration goes into this page so devices were failing due to lost configuration. They coded around this by having another copy of the configuration in the 2nd and 3rd last page which the code will check if it finds an empty configuration.
But the latest issue we have come across is a device where the first page of flash ROM has erased itself. As this contains the actually application program the code cannot deal with this issue.
They have gone through their code top to bottom, check it and rechecked it but can find no where that we could ‘accidentally’ erase a page of flash.
Regards
Allen
We are seeing exactly the same. In an earlier attempted design, based on the original cc1110 ref. (with passive parts) we found "it's" own antenna if located too near the xtal would cause this problem as would significant blasts of spurious RF. We have redisigned with Johanson balun which has improved matters significantly, we have followed the latter CC1111 dongle & chronos AP where both have no reset filter.
The problem is now 10 to 100 times worse. We have seen the CC1111EMK mini do the same
My question is simple, can noise in the reset line cause this page erase?
If so is there a workaround, I saw a post mention they were forcing a reset with the watchdog, would this help.
Any solution/update to this? I've been using the CC1110 for several years with no issues and just recently this exact problem has begun cropping up. I've tried everything I can think of and can't seem to figure out what is going on.
Thanks!
Mark
UPDATE: I *may* have found a solution to this. I believe the problem is due to supply rail fluctuations on startup caused by our LDO (the TPS780, extremely low quiescent current but very poor transient response!). I added more bulk capacitance (in the form of a 47uF tantalum) and put some delays in the code to allow the rail to settle before switching to the high speed clock. If this helps anyone else please let me know--it's kind of tough to *prove* whether this really fixed it or if it just decreased the likelihood of it occurring enough to look like it fixed it.
I'm having the opposite problem - I have a bootloader which tries to erase pages of flash. Only some of them get successfully erased. It worked fine in an earlier rev of the board with an earlier batch of ICs. Anybody else seen this?