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.
No experience of this problem but just a random thought: how susceptible to high temperatures is the quartz crystal that you are using? A quick Google search came up with this statement from a manufacturer:
"Operating Temperature: Standard Operating Temperature ranges are generally considered as -20-+70 degrees Celsius (considered "commercial" Operating Temperature), and -40-+85 degrees Celsius (considered "Industrial" Operating Temperature)"
thanks for your attention. there is no casing involved (yet): the product is required to operate at temperatures of up to 70 degrees, but it might exceed that if the casing is installed, thus the vigorous testing. the crystal does not seem to be the problem - at least our hardware people said that... NXP claim that the LPC2478 was tested at their labs at up to 105 degrees, and some applications allow for us to 120 degrees...!
can it be that the coating in the print disturbs heat dissipation?<p>
Hm, the whole print is coated (including the components)?
yes.
"humidity: 0%."
Whew, dry heat man. Doesn't sound likely to use.
Are you absolutely sure about that?
well, the control panel of the chamber says: "current value: 0". my girlfriend could use the air inside to feed her hair dryer...do you think I should test another setting (but I think that increased humidity will hurt heat dissipation, not...?) ?
It may say 0, but it's very unlikely that humidity in the test chamber is really 0%.
of course, I realize that.
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.
Per,
that's a good idea that I haven't tried yet. thanks!
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.
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.
For the amount of stuff (and content of the stuff) you're posting, you would be better off with twitter :o
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 :)
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.
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?
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.
View all questions in Keil forum