Hello,
I was hoping to hear your opinion about a serious problem I have - it is either I solve it or reduce my LPC2478 CPU speed from 72[MHz] to 64[MHz] (11% loss. The problem does not seem to be occurring at lower MHz settings). I posted about this in the past but it was a long time ago. When I place a controller in an environmental chamber and increase the temperature to 80+ Celsius degrees, I often see data abort exceptions, and sometimes I get the impression that the PC takes a hike (even the firmware LED that blinks every 1 second becomes irregular for a while before it stops). The program is launched by a boot loader and has a lower level supporting firmware layer that handles some interrupts (not all). I also see that if RTX is not started at all (but the application hangs in a "for (;;)" loop instead, hence the bootloader and firmware layer were/are involved, but the application is idle) - the system never crashes! I have excluded, as far as I could tell, the roll of external memory or RTX in this situation. However, I still suspect RTX a little (even though my test programs never crashed). My question: did you ever encounter such a situation? Where do I look best? can this be the result of a misbehaving peripheral? NXP have confirmed the LPC2478 is not the reason.
"...the previous one did use some components whose thermal limits were below 80 degree."
And you found it was failing at 80+ degrees. Well, there's a surprise (not).
This thread might well have been started with:
"If you violate the thermal specifications ..."
Note that fast/slow accesses for a DRAM would most often be the actual timing of the signals. How long time for signals to settle, or to hold. Number of wait states.
There are quite a lot of tests needed for memory. Some for prototypes. Some for factory production. Some for every boot or maybe even regularly when run. - correct supply voltages at all temperatures and loads - correct timing of signals - good flanks and high/low logic levels for signals - all unused chip-selects etc having pull-up/pull-down - correctly wired (no shorts/breaks) - all memory cells working - stability at maximum load at low/high temperature - stability at zero load at low/high temperature (refresh working) - low-power retention (mainly SRAM with super-cap or battery) - ...
"I second this!!, thats a real engineer soul, we are in some way... masochist geeks :)"
I would totally agree with that, I've been involved in plenty of projects where I've been totally engrossed for weeks/months on end, keeping a note pad by my bed for when I wake up with 'the ultimate answer' (much to the annoyance of my beloved wife).
But ... the difference is, most don't keep trying to share this random blabber out.
Have you ever been to a party and sat next to Mr. Boring?
The data transfers LCDController <-> Memory are done by DMA, and there is an automatic mechanism for arbitration, This should not be a problem.
But it should be taked into account if the Video Buffer is located in DRAM and you want to test the DRAM PerÂ's suggestion.
related to the external RAM being addressed by both the application and the LCD controller.
A conclusion you made impossible for anyone else to arrive at, by not mentioning anything about an LCD before, much less that it shared external RAM with the CPU. Is that dual-ported RAM, or how else do you organize shared access?
Remember that a loop continuously accessing the DRAM will look like a super-charged RAM refresh. For problems with RAM refresh, it is often better to fill the RAM with a known pattern and then make sure that the RAM is not touched for a long time so that the only refresh there is comes from the DRAM controller performing background refreshes. Then revisit the chip one every hour and verify that the pattern is still correct. True.
Then, for DRAM memories the test case should be: fast access and slow access.
I don't know about you, but for me, these problems are the cream of the crop of this kind of line of work. almost every problem is a mystery, every problem can be solved (?) in different ways. did I enjoy sitting 3 days in front of an environmental chamber (I have a few burn makes!) ? no way, and the problem is not solved yet (but the probable cause known). but in the end, it is/was a lot of fun!
I second this!!, thats a real engineer soul, we are in some way... masochist geeks :)
For the amount of stuff (and content of the stuff) you're posting, you would be better off with twitter :o
this situation seems to be directly related to the external RAM being addressed by both the application and the LCD controller. if the refresh rate of the LCD controller is reduced, or another type of software is flashed on the controller that does not benefit from the LCD controller - the issue disappears. I will have to adjust the timing parameters of my external RAM, it seems.
Just remember how the post started:
"If you violate RTX's rule ..."
Anyway ... As you say, of topic. But slightly more relevant to Keil tools than use of environmental chambers!
This is an off-topic discussion that has been run already, but a quick summary.
Missing information that just should be available for os_itv_wait() is that if you call the function with a delay longer than the timer repeat time, the missed events will be counted and you will get one or more instant returns from the os_itv_wait() when you finally calls it, until you have consumed the back-log.
The reason why Keil did say that os_itv_wait() and os_dly_wait() shouldn't be used at the same time is just that a long os_dly_wait() call will result in os_itv_wait() having multiple ticks of back-log. That is not a no-no reason. That is just a "watch out for this".
If Keil thought it important to mention os_dly_wait() and os_itv_wait() for the same thread, then they should have documented the real reason, since the real reason can be trigged by many other ways. Any other wait function will give the same result. A too high IRQ load will give the same result. A high-priority task with a lot of work to do with give the same result.
So in the end, Keil updated a "think about" into a "no-no" for the wrong reason, and while giving the user too little information to be able to catch all the other _potential_ problems of using os_itv_wait() in relation to other code.
yes.
In that case, a look at the thermal properties of the coating material might be in order. And maybe a test with an uncoated unit, if available.
"... a no-no ... "
If something is stated as being a no-no, and someone decides to use it, then they are (in my book) using undocumented details.
Hmmm... the sign say's don't open this locked door. I'll break it open anyway. Whoops, they didn't tell me that there was a pride of lions on the other side.
Per,
that's a good idea that I haven't tried yet. thanks!
View all questions in Keil forum