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.
As promised, I have an update that might interest operators of a LPC2470/78 using the LCD controller. I have found that: 1. lowering the CPU clock speed to 64[MHz] at 80+ degrees seems to stabilize the system. There are no additional legal PLL settings between 72[MHz] and 64[MHz] that support USB, I'm afraid. 2. This code
AHBCFG1 &= ~1 ; AHBCFG1 |= (3<<12) ; AHBCFG1 |= (4<<16) ; AHBCFG1 |= (2<<20) ; AHBCFG1 |= (1<<24) ; AHBCFG1 |= (5<<28) ;
when placed in main() {the data sheet does not specify that these fundamental settings are disallowed in application code and indeed they work}, will put the LCD in the most preferred position to access the AHB1 bus. This prevents image jitter and distortion when doing time consuming drawing on the LCD at 64[MHz].
"(I have a new, interesting post)"
Where?
There's a new post, but surely interesting is not a true description?
Or was that an attempt at irony?
Not knowing your true name, I must wonder: have you ever posted something useful on this (or any other) forum? please stop hijacking my thread. I'm trying to be informative (=helpful). if you are in a mood for child's play, I suggest you go to a kindergarten.
Is that you being serious again?
Have you tried looking for the Keil command line option -SetMaxTemp=80
You'll not find it. It's not a Keil related problem.
There are no additional legal PLL settings between 72[MHz] and 64[MHz] that support USB, I'm afraid.
Have you eliminated the PLL as the cause of the problem? We do some very high temperature stuff and have had problems with PLLs becoming unstable or ceasing to function altogether in devices that have worked fine with an external oscillator.
this really is beyond you, ha? this is an issue that might effect Keil USERS and the safety of their product since Keil supports the LPC2478, thus very much their concern. Apart from that, I don't remember asking you when, if or what I may or may not post. Just go away, it won't help you.
Jack,
As I have mentioned, I have another flavor of this product that does not use the LCD controller but is almost identical in any way (processor print, external RAM etc.). It does not crash under the same conditions. Our hardware guy promised me that the crystal is not the issue. He did not measure yet, though.
Ok.
You're obviously happy with your tenuous links.
A small update: Our hardware guy has installed an extra resister across the DRAM clock input and it seems to do wonders! We saw that the first 2 clock pulses of a refresh cycle were far from perfect. On the other hand, this could be an issue with the particular DRAM. Soon we will try another one, and will know for sure.
What do you mean "across"? Having a resistor in series with high-speed signals will reduce the rise/fall times. It will reduce the amount of radiated noise but can also solve problems with ringing signals where the input side may see multiple toggles. Having too large resistor will on the other hand produce a shark tooth waveform where you either don't reach the full voltage swing fast enough or where the flanks are so slow that an input without schmitt-trigger will get false readings.
I meant: "in series". Sorry!
No problem. I did write a bit of ambiguous text too.
I wrote "will reduce the rise/fall times" but should probably have written "will slow down the rise/fall", since the rise and fall times are actually increased :)
Whatever happened to the days where people involved in firmware knew something about the fundamentals of the hardware on which their code would run?
Whatever happended to the days when people on the net always tried to help and be productive, instead of focusing 100% of all comments on harassing people?
Stunned character, I never used this word on this forum (I apologize to the rest of you in advance) as far as I can recall, but you really are an idiot. Really.
<sigh/>