IHTH Last time i saw this message it was related with the SDRAM physical bus. We have also a custom system-application around the MCF5282, i was stuck about this stuff along one month (not fully time of course i couldn't writing right now) but our case was quite quite erratic so hard to sample.
We solve the issue decreasing the theoretical maximum speed of 66MHz to 48MHz if i remember.. The software crashing begins to appear with a new version of our custom hardware. The SDRAM programming setup was reviewed a lot without any result cause it is really standard, same as the hardware scheme. The PCB bus was reviewed also by experts but nothing was wrong from the line transmission point of view.. I personally did my own report on the trap.c because the stuff formally means that the operation code instruction that it's on going doesn't correspond with the CF set (really hard ;-)) under this conditions the trap it's unbelievable. Our application is also quite huge 568Kbytes.. You say you can execute a 594388 bytes program without any anomaly uhhmm you stuff sizes 793780 ... 200K greater... Search anything greater than 800K and try to run it.. Have you the chance to run your wild application in other kind of hardware around the MCF5272 ? Good Luck _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
