SYSDIV is sometimes not applied after reset on LM3S6965 kit

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.