Op Fri, 12 Dec 2014 08:32:20 +0100 schreef Jens Gydesen :
Are you running the CPU and EMC at the same frequency as with the LPC2478? And is the trace length the same between the two boards? It sounds like your EMC clock signal is unstable or skewed. Try a lower frequency first, then go up and tweak the settings (particularly EMCDELAY to compensate skewing at high frequencies).
Yes. For a customer who wanted maximum performance I wrote an SDRAM test function that writes&compares RNG values in display memory at different settings and then prints out the number of verify errors per run. Also we used a heat gun because errors go up with temperature.
None that I can give you, sorry.
--
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
I'm starting designing a new board with LPC1788, an external 16-bits SDRAM, a Quad-SPI Flash (for code and data) and a 4.3" 480x272 display with touch panel.
Until now I worked with all-in-one microcontroller: integrated Flash and RAM, so I haven't any experience with a memory external bus.
Any suggestions how to learn basic and advanced topics about this?
It is a good point with the signal strength, I'l check that.
I have tried 48 MHz up to 96 MHz with the 1788.
My 2478 runs normally at 72MHz, but 48 will also do it
I think that some register in the 1788, different from the 2478, is not initialized correct or forgotten, but I think that I have found the differencies between them.
AFAIK the gotcha with SDRAM on those is the slow speed if you want to execute from it. Perhaps 6 times slower than from flash I think. It is OK for TFT frame buffers.
The new M7 should be a big improvement here with its caches, perhaps NXP will make an M7 version of your device too.
Oh I should have said that it should be fine for your retrofit application, it should be significantly faster than the ARM7. I am looking at doing exactly the same thing on my LPC2478 boards at some point so please let us know what you find!
I know nothing of that specific processor, but I'm assuming that it lets you set up the interface to the RAM in a wide variety of ways, many of which are guaranteed to be wrong.
If you're using the same code, go over the interface timing with a fine- toothed comb to make sure that the new processor isn't interpreting something differently. The last time I did this was the Motorola MPC860 (or something -- it was their Power QWICC). That thing almost had another processor between the core and the memory interface pins -- you basically wrote a script in a descriptor that told it how to talk to the DRAM. It was hugely flexible, but that just meant that you had a bazzilion different ways to screw it up and only a few ways to make it work right.
I'd also look at the signal timings on the board, if I could do it without loading the traces down too much. At best you'll be able to plug into it with a logic analyzer, but even hanging an O-scope lead on the clock and then probing each wire in turn to see what happens should tell you something.
(Of course, it may just tell you that as soon as you start probing it everything goes to hell or suddenly fixes itself -- but that's information, right?)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.