We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Picking up http://www.keil.com/forum/59213/
With tracing issues on M3/M4 parts pay VERY close attention to the speed you tell Keil the chip is running (Core Clock), and what you're actually running the part at.
I wish this forum would read-only threads before some lost soul posts to them, not afterward. Oh look someone revived an old thread, lets close it now. Not sure of the logic here, someone should decide upon some behaviour that makes sense, ie make it read-only after timeout so you can't post against it, or start the timeout over if someone posts against it.
That randon thread-lock functionality has been bug-reported a number of times for quite a number of years. But Keil doesn't spend much time worrying about errors with the web forum. Trying to keep up with all uVision needs probably consumes all available resources.
But the thread locks are directly customer-hostile, since the new user who manages to make that last post in an old thread doesn't know that no one else may respond. And if someone else responds in a new thread, there will be no mail to notify the new visitor.
I don't think it's random at all?
It seems to be a perfectly straightforward logic error - thoroughly deterministic: instead of the lock being applied when the thread times out, it is applied when the next post is made in a timed-out thread.
Of course it isn't random - but the victims will see it as random rudeness since the threads so obviously wasn't locked before they posted.
And that is why it's so strange that Keil can't even invest one or two hours to fix what should have been trivially simple to fix - unless the lock is in some compiled module that they have lost the source code for...