Hello all,
I do not wish to repeat myself as I have addressed this issue in a recent thread, but this is too important to turn a blind eye to as even lives could be at stake which certainly makes it worth a separate thread: I believe I managed to conceive a program that causes a failure of RTX on a LPC2468/2478 (simulator does not induce the failure). Quite some people have reported problems with RTX on this forum, so hopefully they can download my stripped test program here dl.getdropbox.com/.../LPC2468_RTX_Demo_min.zip to try there own variants. I have of course informed Keil support about this issue and I am currently waiting for feedback. I would very much appreciate any feedback you might have.
Tamir
Just a quick status update: Keil support have confirmed that my program exposes a timing problem within the RTX kernel. RTX expert Franc Urbanc will address the problem as soon as possible.
We found no probles in RTX kernel, the problems you describe are most likely a device configuratin or a chip problem.
Device LPC2468 had some problems in the past. Most of them are corrected in the last silicon rev. 'D'
Please read the device errata sheet ES_LPC2468_6.pdf
The items that can cause the application crash are listed under: PLL.1, Flash.1 and MAM.1 topics.
Check your device revision level first and then correctly set the cpu clock and MAM mode.
Franc
I have implemented the errata sheet recommendations (regarding PLL) for the LPC2468 on the LPC2478 with success. The problem is that the LPC2478's errata sheet does not specify any of these issues! Does anybody know which hardware revisions issues of the LPC2468 apply to the LPC2478 ?
Hi,
NXP's link to the ES_LPC2468_6.pdf appears not to be working this morning:
www.nxp.com/.../ES_LPC2468_6.pdf
Any chance one of you could send me the file?
My email address is "erics" at the domain of "forwardpay.com".
Thanks, Eric
Never mind, I have found a copy of the latest errata.
FYI: I am well within the operating limits of all of these listed errata -- running on a 12MHz system clock, PLL output of 96, MAM disabled.
Franc -- doesn't the fact that Tamir got this condition to occur in the simulator mean that this is not a hardware problem?
Eric,
correction: I did not get it to occur on the simulator...!
Oh, I apologize. I read your post wrong.
Just to be clear: you have not yet had this occur in your test application on LPC2478 hardware after making the changes that the LPC2468 errata suggested, correct?
That is correct. I had 2 boards running my test application with the lowest values of M,N (for PLL determination) that yield 72 MHz for about an hour without a failure. I forgot to leave such a system running all night long, though...will do so tomorrow! it is weird that some errata stuff that was written for the LPC2468 applies to the LPC2478 as well - while the errata sheet of the LPC2478 is "clean"...!
I forgot to mention that I have addressed the technical support of NXP regarding the errata sheet (in)compatibility issue.
Hello,
I have received this reply from NXP:
"The PLL.1 erratum has been resolved since version "A" of the silicon. It doesn't apply to the LPC2478. It is therefore unlikely that the PLL frequency is the cause of your system instability.
LPC2478 started with rev C silicon, current LPC2468 are rev B silicon."
Why is it then that choosing the most stable clock settings that yields 72[MHz] on a LPC2478 stops RTX from failing? It is NXP's spread sheet that I used to calculate the clock settings, and nowhere is it specified that some of the results are illegal or that you must choose the lowest possible M,N.
More information: I have conducted additional tests along with Franc Urbanc and found out that M=12, N=1 (=72[MHz] with a crystal of 12[MHz]) and a tick rate of 50 microsecond fail RTX when the startup file is augmented with NOP to align the binary structure compared to the M=24, N=2 version. We are large shifts in generated code and an increase in binary size (4 bytes) compared to settings of M=24, N=1. The errata sheet of LPC2468 does not apply to LPC2478.
I have conducted more tests for Franc. It seems to be a problem with the LPC2478 revision C MAM (not certain yet), as my test program does not crash when executed from RAM.
i'm changed mine to run from ram, it still crashes, maybe less often. still always in that same function.
i haven't run your test program but i will as soon as i get a chance.
Hello Ryan,
Have you tried to shutdown the MAM altogether? Do notice that I have determined, together with Franc Urbanc, that the actual structure of internal flash image determines whether there is a crash or not, as long as the program is runs using the MAM.
tamir,
i ran your test program for a while. I have not seen it crash, but three times so far, the watchdog function in each task shows that some of those tasks are no longer running. this happened after 5-30 minutes of running. i was running this on the lpc2478 board.
I have seen this behavior on my own project lately while doing tests. It seems that sometimes a task is lost, sometimes a task is in the list more than once (next pointer points to itself and gets stuck in a loop), and most often the dabt error occurs on the null pointer.
i've run it with MAM off and these things still happen, perhaps less often. my tests now include a mcb2470 as well as 2 different EA lpc2468 OEM boards on my own base board design.