RT1050 - Recreate DCD SDRAM config C code?

[dmarks_ls]

So this is a three-pronged question...

1. How does one generate the C-format DCD header components such as "evkbimxrt1050_sdram_ini_dcd.c"?
2. Where can I find the MCU Config Tools file (.MEX) which generated the clock settings found in "evkbimxrt1050_sdram_ini_dcd.c"?
3. Is there an RT1050 SDRAM config tool specifically for generating SDRAM settings which then get plugged into the DCD data?

Part 1... In nearly every example project for the RT1050 EVKB, there is a subdirectory named "xip".  And in that directory there are three sets of source/header files, "evkbimxrt1050_sdram_ini_dcd", "evkbimxrt1050_flexspi_nor_config", and "fsl_flexspi_nor_boot".  Each of these files contains XIP boot header information, specifically for initializing SDRAM, describing the FlexSPI/HyperFlash device capabilities, and describing the boot image, respectively.

How was "evkbimxrt1050_sdram_ini_dcd.c" and the other source files generated?  At least, I'm assuming they were all generated, not written by hand; at a minimum, the SDRAM init settings surely had to be machine-generated.  I've found documents like this one, but that only describes doing post-processing on S19 and binary images and such, not generating source code like that in the "xip" directory.  These files don't appear to be generated by the MCU Config Tools.  Which utility created them?

Part 2... I'm creating my own RT1050 project, and I'm approaching the daunting task of setting all of the clock generation options.  I'd like to set up my MEX file to have the same clock settings that went into the XIP SDRAM settings.  But it seems like all of the clock_config settings in the SDK examples are set to defaults as well.  I added some code to my project to extract what the clocks are once the system has been initialized (I have SKIP_SYSCLK_INIT defined so that my code doesn't overwrite what the boot ROM set up).  Here's my output:

 600000000 Hz kCLOCK_CpuClk           
 600000000 Hz kCLOCK_AhbClk           
 163862064 Hz kCLOCK_SemcClk          
 150000000 Hz kCLOCK_IpgClk           
  75000000 Hz kCLOCK_PerClk           
  24000000 Hz kCLOCK_OscClk           
     32768 Hz kCLOCK_RtcClk           
1200000000 Hz kCLOCK_ArmPllClk        
 480000000 Hz kCLOCK_Usb1PllClk       
 261818172 Hz kCLOCK_Usb1PllPfd0Clk   
 246857130 Hz kCLOCK_Usb1PllPfd1Clk   
 332307684 Hz kCLOCK_Usb1PllPfd2Clk   
 576000000 Hz kCLOCK_Usb1PllPfd3Clk   
  24000000 Hz kCLOCK_Usb2PllClk       
 528000000 Hz kCLOCK_SysPllClk        
         0 Hz kCLOCK_SysPllPfd0Clk    
         0 Hz kCLOCK_SysPllPfd1Clk    
 327724128 Hz kCLOCK_SysPllPfd2Clk    
         0 Hz kCLOCK_SysPllPfd3Clk    
  24000000 Hz kCLOCK_EnetPll0Clk      
  24000000 Hz kCLOCK_EnetPll1Clk      
  24000000 Hz kCLOCK_AudioPllClk      
  24000000 Hz kCLOCK_VideoPllClk ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

So it looks like the XIP DCD settings set up the system PLL (PLL2) PFD2 output to 327 MHz, making the SEMC clock 163 MHZ (closest to 166 MHz, presumably), and also set the USB1 PLL (PLL3) PFD0 output to 261 MHz for FlexSPI operation.  Everything else is at defaults.  Are PLL2_PFD2 and PLL3_PFD0 the only clock settings that matter when setting up FlexSPI and SDRAM?

Part 3... Is there some special utility NXP used to generate all of the SDRAM timing data that's presumably encoded in the DCD data?  If one just plugs in the numbers from the SDRAM datasheet, the SDRAM should just work, right?

I realize this is a lot, but I'm really trying to get to the bottom of what was used to generate the DCD data used in all of the examples, so I can make sure my custom project is set up correctly.  Thanks.

[dmarks_ls]

For those interested, I've created a DCD configuration that replicates the original DCD "blob" from SDK 2.5.x.  Here's the XML which you can insert into your MCU Config Tools v6 MEX file using a text editor (replaces the whole <dcdx> block), and here's the source file that results from that configuration.  Groups have been named and comments added.

[dmarks_ls]

And with the release of MCUX 11.0.0, I see that my wish was granted... there's now a proper DCD editor in the MCU Config Tools.  So now I can transcribe my newly annotated SDRAM init script into the tool.

[dmarks_ls · Accepted solution]

All,

I've created a DCD CFG file that successfully reproduces the contents of evkbimxrt1050_sdram_ini_dcd.c as found in RT1050 SDK projects.  I started with the "Micron" DCD CFG file provided above, edited out the 14 SDRAM config writes that are later overwritten, changed the PLL2_PFD2 divider to get 166 MHz, and set BMCR1[WBR] to 6.  If I take the SDK C file, collapse all the newlines to get rows of 16 bytes, change "0x" to "0X", and compare it to the C source code generated by the dcdgen.exe utility (see NXP comment above for download), it's a perfect match.  (I realize now that the trailing 0x00 is correct when the DCD binary is a standalone blob; the 0x00 tells the ROM interpreter "no more data".  It does need to be trimmed off when compiling the C code into an SDK project).

I hope that this DCD CFG file is useful to others who want to understand what registers are being set up by the DCD code in the SDK, and perhaps want to modify the DCD CFG for their own projects.  I know that I will be modifying my copy to configure the other PLL2_PFD2 dividers, as well as the PLL3 (USB1 PLL) dividers.  Let me know if there are any bugs in the comments I've added to the CFG file, thanks.

[jeremyzhou]

Hi David Rodgers,

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1) How does one generate the C-format DCD header components such as "evkbimxrt1050_sdram_ini_dcd.c"?
-- The dcdgen.exe is a tool to convert the .cfg file to a binary file and/or a c-style array file, please check the attachment.

2) Where can I find the MCU Config Tools file (.MEX) which generated the clock settings found in "evkbimxrt1050_sdram_ini_dcd.c"?
-- It seems to generate it by the developer himself.

3) Is there an RT1050 SDRAM config tool specifically for generating SDRAM settings which then get plugged into the DCD data?
-- As I know, there's no similar tool as you describe, now developer needs to create customize dcd.cfg base on the sample dcd.cfg, note: The dadgen.exe tool needs a .cfg file as input that contains all commands to be converted into DCD data block. The bin file will be used as DCD data file when generating a boot image.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[dmarks_ls]

Hi Jeremy,

Thanks for the reply.  The utility is helpful, thanks, as well as the example DCD config files.  The config file "dcd_sdram_166MHz.cfg" is quite different from both the SDK C code and the Micron/ISSI DCD CFG files, so I'll ignore that one.  The Micron and ISSI CFG files are actually identical, so I'll just call it the "Micron CFG".

I compiled the Micron CFG into a C file, then did some text editor massaging on both the Micron C file and the SDK C file, and ran a comparison.  They're close, but still not identical:

Here's the differences I can pick out, based on what I can figure out based on the datasheet documentation of the DCD format:

1. (offset 0x0001) The Micron data is 0x0070 bytes longer overall (DCD header tag 0xD2).
2. (offset 0x0005) The Micron data has 0x0070 bytes more of write data (write data command 0xCC).
3. (offset 0x004C) The SDK code has PLL2_PFD2 divisor set to 29 (0x1D) for 166 MHz operation; the Micron CFG sets the bus speed to 133 MHz using divisor 35 (0x23).
4. The Micron CFG contains 14 more register writes to SEMC than the SDK example; looking at the Micron CFG, it appears that several of them are duplicates, i.e. the later writes overwrite the previous ones.
5. The SDK C code sets SEMC_BMCR1 (402F_000C) to 0x06030524, while the Micron CFG sets SEMC_BMCR1 to 0x00030524.  That field (bits 31-24) in BMCR1 is WBR (Weight of Bank Rotation).

Everything else appears to be the same.  Minor nitpicks: the DCDGEN utility appends a trailing 0x00 which appears to be incorrect and should probably be deleted, and does not write a comma at the end of each line or a semicolon after the closing brace (those were added by me).

Given that the SDK C code actually works, I'm inclined to believe that the BMCR1[WBR] value of 6 is correct.  So I'm going to take the Micron file, add a lot more comments to it, and make it identical to the code that's in the SDK.  I'll post that DCD CFG file here when I'm done.  I'm then going to alter the file for my own purposes so I can customize the PFDn dividers for PLL2 and PLL3, since I can't do that directly in MCU Config Tools (I have SKIP_SYSCLK_INIT defined since I'm booting from flash).

I would VERY much like to see this functionality (composing/editing a DCD file, automatic generation of DCD C code, SDRAM configuration management) incorporated into the MCU Config Tools at some point.  It's kinda janky that I have to reverse-engineer the hex code from the SDK to figure out the original DCD CFG file.  This process should be a lot smoother; it shouldn't need standalone engineering tools posted in a forum to pull it all together.  Thanks again.