ARM, RISC-V контроллеры

Второй ответ NXP - тщательный уход от темы. Напоминаю, идентичный код работает на старките от starterkit и не работает на своей плате. Отличие в корпусе контроллера 256 BGA/144 LQFP. Наша плата визуально разведена лучше.  According to your description your software works fine on a KEIL board (there are examples in C:\KEIL\ARM\Boards\Keil\MCB4300) and on a board from a company in Moskow called starterkit. The KEIL board has a 32-bit SDRAM, the board from starterkit has a 16-bit SDRAM (your board is also with 16-bit SDRAM). As your software seems to work on the starterkit board the difference is most likely in hardware (your board and the 144-pin instead of 256-pin LPC4300). I attached a piece of code which should initialize an MT48LC16M16 16-bit SDRAM correctly. However, here are also some additional hints: - Take care that LPC_SCU->EMCDELAYCLK = 0x7777 - Take care that the address mapping is correct (register DYNAMICCONFIGx, see code example) - Take care that the Mode Register is correctly written (see code example) Also have a look at the LPC3200 app.note below, which in most parts is also valid for the LPC4300: http://www.lpcware …sdram-memories-lpc32xx Мое второе письмо: Dear NXP Technical Support Team, Thank you for the answer! Let me first precize the situaltion with SDRAM. Generally SDRAM works: test program writes to SDRAM and next reads from SDRAM and compares data with expected values. It looks OK, but problem starts if to interrupt test writing or test reading and to write few bytes into other area of SDRAM. Such write operation must not influence on the test result (because it is two different areas) but it does in a way that data in two bytes which were accessed before interruption last, are wrong and test finds it. In reality we've met troubles when debugged FreeRTOS port and strange behavior of RTOS has forced to make exploration with test SDRAM. >>The problem doesn’t sound like a timing issue. I think so too because sequental writing/reading works. >>It seems to be related to the software configuration. I can't agree, because the project used for 144-pin device was uploaded to 256-pin device without change of EMC configuration and worked there OK. >>Did you test on more than one 144-pin board? We tested three samples of PCBs of one type: identical behavior. >>Which board do you use with the 256-pin device? We used two types: 1) From Keil, but it is not very interesting because 32 bit SDRAM used there http://www.keil.com/mcb4300/ 2) From StarterKit (Moscow) http://www.starter …ame=shop&op=view&id=78 . Here same structure SDRAM used as we use, and we have removed Samsung SDRAM from this PCB and soldered our one from Micron. Test works with interrupts. >> This is reallye hard to understand without seeing it. Which info do you need to see? I can prepare PCB layout, software configuration, I think we can send even real PCB, if it will help to make a step forward. >> Could be your design is somewhere at the edge of the spec. Which parameters could be close to limit? We reduced SDRAM frequency in two times: problem remains. >>If it's a timing issue (related to CLK signal) there are some recommendations that might improve the situation: Maybe, but why you haven't offer change a cofiguration of CLK delay register instead soldering of capacitor? >>Use CLK2 pin and pinmux the signal CLK23 to it Tested: without change >>Add a small capacitor to the CLK signal to delay it a little bit Tested: 10 pF, 27 pF: without change, 100 pF: memory does not work at all >> Please let us know if this does not resolve your inquiry. Kindy ask you to help us to solve problem. By the way, why 144-pin device is indicated on the NXP site as "Qualification" when other models are Production?