I had some previous problems involving the LM3S6965's clock circuits and reset pin before, therefore I suppose it's understandable that my eye starts slightly twitching whenever I have a new problem and things seem to point to the same area (not unlike how tech support probably gets the twitchy eye seeing my name on the forum, for much the same reason). Sadly, this is exactly what happened on a closer examination of the Ethernet bootloader sample (the original, unmodified "boot_eth"), which quite often failed to start up after a reset by the hardware reset button on my EK-LM3S6965 evaluation kit.
I quickly established that this was not the previously mentioned problem I had with the "game" demo (the fix I found did not help, and the board could not even be "debugged into" once it failed to start up - it was not going to the hard fault handler as it did in the cited case). I did however find that the issue got triggered in the exact same place - the controller froze up at the instruction that switched off the PLL bypass.
I won't bore you with everything I tried to get to the bottom of the problem but pretty much nothing worked until I got tipped off by looking at an LED I had turn on during a large-ish delay right before the bypass switch-off - a delay long enough to be clearly visible, which had two quite distinct timings corresponding to the board working properly after a reset or freezing up.
This delay was meant to take about 4 seconds normally, but it was taking 0.5 seconds each time the board was going to freeze up. I have to emphasize this - a simple assembly "FOR cycle" delay, with not even interrupts enabled, was randomly taking on occasion exactly 8 times less than it was supposed to (as subsequently timed with a logic analyzer). Which made pretty damn clear what was going on: the SYSDIV clock divisor value the bootloader was trying to set (x16) was sometimes not applied - the smallest possible value of the divisor (x2) was being used instead thus making the MCU run - guess what - exactly 8 times faster than we wanted it to. The only problem with this was that the PLL puts out 200MHz, but the MCU is specified at 50MHz tops - hence, with any divisor smaller than x4, the MCU gets massively overclocked the instant the PLL bypass is switched off and the full 200MHz starts driving the inappropriately set clock divisor, locking up the MCU rather swiftly.
Now I had an explanation - but not a solution. I tried literally everything I could think of, but I was not able to reliably set the "x16" divisor the code was supposed to be running with - every few attempts the MCU kept locking up. This fortunately changed once I noticed that the x16 divisor we were trying to set is coincidentally also the reset default value of the SYSDIV field. Which offered an explanation - I certainly have no proof of its correctness, but my theory is that on reset, the SYSDIV field is always correctly set to the "x16" value, but the clock divisor circuit itself is not reliably conforming to this setting after a hardware reset, and sometimes stays on the smallest "x2" setting. I also assume that there is some kind of internal change detection mechanism responsible of applying any new value we might set SYSDIV to - however, as long as we try to write the "x16" value already present in SYSDIV, it does nothing to rectify the problem, and the system divisor keeps working at "x2" no matter how many times we try to set it to the default "x16".
Thankfully, the theory also suggested the solution - and a simple one at that - which is to write any non-"x16" value to the SYSDIV field first after a reset, and only then try to set it to "x16". Since a change is now detected both times, our setting should actually get applied. Luckily, this seems to be exactly what is happening - since using this fix, I could never duplicate the lockup issue again. I wrote this post to whoever it may concern - since as of today you cannot find this in any errata of the LM3S6965 chip, if you experience the same problem this might hopefully help.
Thank you for an extremely well described problem and workaround - the time you took to help the rest of us is appreciated!
Just to be sure, did you also set the PLL voltage to 2.75V per the errata? I'm not sure if the errata could manifest itself in the manner you experienced, but it does seem plausible there _could_ be a relationship there...
Yes, the PLL voltage gets set to 2.75V as advised - in fact, this is the first thing "ConfigureEnet()" in the original "boot_eth" does. I also tested everything using some quite extensive delays after every step, so settling times were not an issue.
You're welcome & best regards,
Count me as someone who is glad they stumbled onto your posts. I have been trying to diagnose a recent issue in product that has a strong resemblance to what you have reported. However, I am working with a 6918 RevC silicon. Bottom line is that you have probably saved me another week of work (on top of the 4 already spent to get to this point).
And for record, I have been all over chip Errata, Datasheet etc... nowhere are issues like this even mentioned or hinted at.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.