A new 512 DDR from ALLIANCE MEMORY is available now that should fit the IMX23 OLINUXINO series and costs just 1.50 EUR .vs vs 4-5 EUR for the Hynix or Micron MT46V32M16P-6T:F used in the Freescale hardware designs.
The best part is it is available in large stocks worldwide (ex: Digikey, Arrow and Mouser) for @USD $2.12! in 10 pcs!
Alliance DDR1 AS4C32M16D1-5TCN . The data sheet is here
http://www.alliancememory.com/datasheets/pdf/ddr1/512M-AS4C32M16D1.pdf
The Micron DDR1 (used by Freescale) is here
http://www.micron.com/~/media/Documents/Products/Data%20Sheet/DRAM/DDR1/512Mb_DDR.pdf
The HYNIX DDR1 (used by Olixino) is here
https://www.olimex.com/Products/Components/IC/HY5DU121622DTP-D43/
and
http://www.hynix.com/inc/pdfDownload.jsp?path=/datasheet/pdf/dram/HY5DU124(8,16)22D(L)TP(Rev1.0).pdf
The Freescale evaluation used MICRON... so does anyone know where the MICRON to HYNIX modifications defines were changed in the first MINI/MAXI designs? I ask in so I can try to change HYNIX to ALLIANCE.
If anyone wants to compare the data sheets (timing and drive levels) and suggest differences I am sure everyone would be happy to save the BOM costs!
Thanks to all
SR
One more note...
When the ALLIANCE DDR1 is soldered on the MICRO we get this message "Undefined Instruction R_14"
When I add the ALLIANCE MEMORY the messaage Undefined Instruction r14_ occurs
HTLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLFC
PowerPrep start initialize power...
Battery Voltage = 0.65V
No battery or bad battery detected!!!.Disabling battery voltage measurements./r/nLLCMay 11 201215:26:EMI_CTRL 0x1C08404
init_ddr_mt46v32m10Frac 0x92926192
LLLLLLLFCLJe cpu fr
Undefined Instruction
r14_
(b.t.w. R17 is removed)
try lower memory clock
I guess I have 2 questions regarding "lower the clock"
What is the downside of lowering a clock?
How do I do this ... where is this define?
(It's worth a try simply to get "proof-of-life" that this chip can enven physically work at any speed
Thanks!
Hello Srungerson,
Have you had any success in changing the ram memory chip?
Thanks for your feedback.
Regards,
Madjid
Sadly... no
The specs are the same.. I tried slowing down the speed and changing some other parameters ...including timings on power-up of the 2.5 v.. but nothing helped.
As soon as the SDRAMInit is initialized the call goes back to the IMX23 ROM and fails.
Freescale did not have an answer either... but honestly I have not given up.. I'm just waiting from some advise or ideas.
got any?
By the way, we're now using Samsung K4H511638J-LCCC000 memory with imx233 in our design. It's pretty cheap here in Russia, some $2 or so.
It only supports CL=2.5@133Mhz though, so a small patch to u-boot is needed to make this one work reliably.
srungerson, have you had any progress on your memory-swap attempt ?
We are also considering to order samples now and to see if we can get it working (though we are reworking our current EMI design as it was not stable on high clocks)..
Hi, has any of you succeeded in swapping the hynix memory ? I'm looking for an industrial grade ddr memory to replace the one in the current design.
We're planning to try some of the boards with Alliance chips in next iteration (maybe in 2 - 4 weeks?). So hopefully I can at least give some experience on that later.
Sorry for flooding this topic. Except the 1.8V, what would be the difference if it was to solder a mDDR chip?
I think you would have to change the code that sets up the registers that define memory operation (in u-boot spl_mem_init.c or in bootlets init-mx23.c)..
I'm not sure there is anything else you would have to worry about..
By the way, looking at the Freescales bootlets code, there is definition for Microns mt46h32m16lf mddr chip already:
void init_mddr_mt46h32m16lf_96Mhz(int ce)
and
void init_mddr_mt46h32m16lf_133Mhz(int ce)
Hi Jlumme,
Thanks for the information. I'm looking for an industrial compatible ram chip and still in production/available for order.
If you guys have a clue i'll appreciate the help! ;)
Hi
Here is some late news after a year (I started this thread). I am glad to see it's still active.
As you'd guess we stopped the 'Alliance DDR' experiment with as a failure and waste of time and continued to ship the IMX233 with MICRON MT46V32M16P-5B:F specified in their User Guides and deployed on their Demo EVK board. Note this part was rev "F")
Rev F: is now in EOL(no longer produced). Today we simply tried to use the new Micro part MT46V32M16P-5B:J (REV J)
Guess What !! We have the SAME boot problem as the Alliance now !!! No Boot with Micron too. Error is "Undefined Instruction" after SD init.
So at this point we have NO currently produced Micron Memory that works.
Here is the DS http://www.micron.com/-/media/documents/products/data%20sheet/dram/ddr1/512mb_ddr.pdf
Pages 14-17 seem to show just power differences.
If anyone knows a few fixes to try please let me know (we tried 96mhz, no change) .
Thanks!
SR
Well, from olimex team. The imx233-nano, said to be industrial on the website and on the store, is not. The sdram used is 0-70.
They ask for an extra € to make it industrial ( not mentioned anywhere btw, and which discouraged me from using this board for my industrial application, i need a stable product with clear informations. Not a "you must add €".
So they say that they have a industrial variant ( which i did not ordered and tested), maybe they can tell you which SDRAM product they use for this variant. Seems like they use micron one, i don't even know if they tested it themselves.
Regards.
The Industrial Variant of Micron is :
Long life industrial temp part: MT46V32M16P-5B XIT:J
Commercial temp part: MT46V32M16P-5B:J
Both are stocked in the USA. However, as I mentioned above, any rev:J does not work, only :F version works
J now gives Undefined Instruction r14_ on DDR Intit...
Best , SR
(Still hoping someone can tell me what to change to get it to boot!) If needed I can pay for someones time
SR
Try setting EN_LOWPOWER_MODE bit in DRAM control register 05.
(this enables the otherwise undefined DRAM Extended Mode register to be written)
For me this allowed the Alliance chip to boot without error.
Quote from: RSA on July 31, 2014, 05:47:20 PM
Try setting EN_LOWPOWER_MODE bit in DRAM control register 05. ...For me this allowed the Alliance chip to boot without error.
Wow! After making this change, I can verify this at least gets the system up and running. Because of stability issues, I had to cut the clock down to get Linux to boot. I'm going to start investigating changing timing parameters, but I was wondering if you had to make any other changes, RSA?
Jay,
Are you also testing the Alliance DDR chip or the Micron Revision J DDR?
Thanks
SR
Jay,
I also see stability issues with linux which I think are related to timing but I didn't check any further. I decided to check the Micron part first to see if that one works with the current timing settings (awaiting delivery of the parts).
SR,
I've just mounted the Micron part MT46V32M16P-5B:J
This part works straight out of the box, no changes to the DRAM registers required !
To me this seems to be a straight replacement for the Hynix part.
srungerson,
I'm talking about the Alliance part.
Once I cut the clock in half, I stress-tested it all weekend and it's still running fine. I tried running at an intermediate frequency (somewhere between 266 and 133) and it doesn't seem to like that very much. I'm going to try to play around with some of the imx233 DRAM controller registers, but there's 41 of them (!!!), so it might take a while to figure out possible fixes for the Alliance part -- other than running my board at half-speed.
RSA -- great to hear about the Micro part -- but where the heck do you source it? I can't find it on any of the distributors I go through for small-volume stuff (DigiKey, Newark, Mouser). It's also very expensive compared to the Alliance part; that's why I'm so interested in getting that part working.
Jay,
I got the Micron part at nl.farnell.com (at low volume it is expensive indeed).
For me the Alliance part has too many pitfalls such as the needed timing changes in the registers and it uses 2x more power compared to Micron or Hynix part.
Micron rev J: is much less power than Rev F in standby (30-50%!)
RSA... I have one question..
Can you post or link to the the DDR registers you are using.
It seems to me there may be different versions and this may be why there are different results. I know Olimex made changes from Freescale, so I am not sure if we are all using the same registers setting.
Thanks
SR
I'm not sure what you mean when you talk about changes "Olimex made" -- but in U-Boot, the current value of the register is 0. Change it to 1. That's all that needs to be changed to get things working -- though, as we've mentioned, we had to cut the clock in half to get it to run stable. I'm going to look into timing parameters once I have some free time.
I have a compiled Olimex image that was shipped in an MicroSD card with my IMX233 Micro. This works 100% of the time with REV J:
However I have downloaded source that only works with F: and does not boot with Rev J: .
This is available here: www.ghlsystems.com:3000/redmine/projects/l280/repository/revisions/11/entry/src/boot/uboot/bootloader/imx-bootlets-src-10.12.01/boot_prep/init-mx23.c (http://www.ghlsystems.com:3000/redmine/projects/l280/repository/revisions/11/entry/src/boot/uboot/bootloader/imx-bootlets-src-10.12.01/boot_prep/init-mx23.c)
The GITHUB/FREESCAKE source does not output the same DEBUG RS-232 output as my Olimex Factory SDCard
Olimex code includes a debug line from the source highlighted in RED below... This line is NOT included in the Github/Freescale code, so we know there are two builds.
May 11 201215:26:EMI_CTRL 0x1C08404init_ddr_mt46v32m10Frac 0x92926192
LJUncompressing Linux... done, booting the kernel.
Linux version 2.6.35.3_OLinuXinoR4 ... (hehopmajieh@hehopmajieh-office) (gcc version 4.7.1 20120421 (prerelease) (GCC) ) #11 PREEMPT Mon May 21 10:27:52 EEST 2012
In summary... I'd really like to see what we are all using for DDR register constants.. or if ANYONE has an init-mx23.c with the debug output text "init_ddr_mt46v32m10"" . If this debug phrase is in the source code, then I would LOVE to see it! My guess is the DDR init routine or registers are different than the Freescale code.
Thanks for reading this long post
I'm not using any Olimex sources, I'm using the freescale imx-bootlets-src-10.05.02 with barebox as bootloader.
Anyway, the relevant register settings in init-mx23.c:
void init_ddr_mt46v32m16_133Mhz(int ce)
{
HW_DRAM_CTL00_WR(0x01010001);
HW_DRAM_CTL01_WR(0x00010100);
HW_DRAM_CTL02_WR(0x01000101);
HW_DRAM_CTL03_WR(0x00000001);
HW_DRAM_CTL04_WR(0x00000101);
HW_DRAM_CTL05_WR(0x00000000); //EN_LOWPOWER_MODE for setting EMRS with alliance memory set bit 0 to 1
HW_DRAM_CTL06_WR(0x00010000);
HW_DRAM_CTL07_WR(0x01000001);
HW_DRAM_CTL09_WR(0x00000001);
HW_DRAM_CTL10_WR(0x07000200);
HW_DRAM_CTL11_WR(0x00070202);
HW_DRAM_CTL12_WR(0x02020000);
HW_DRAM_CTL13_WR(0x04040a01);
HW_DRAM_CTL14_WR(0x00000200|ce);
HW_DRAM_CTL15_WR(0x02040000);
HW_DRAM_CTL16_WR(0x02000000);
HW_DRAM_CTL17_WR(0x19000f08);
HW_DRAM_CTL18_WR(0x0d0d0000);
HW_DRAM_CTL19_WR(0x02021313);
HW_DRAM_CTL20_WR(0x02061521);
HW_DRAM_CTL21_WR(0x0000000a);
HW_DRAM_CTL22_WR(0x00080008);
HW_DRAM_CTL23_WR(0x00200020);
HW_DRAM_CTL24_WR(0x00200020);
HW_DRAM_CTL25_WR(0x00200020);
HW_DRAM_CTL26_WR(0x000003f7);
HW_DRAM_CTL29_WR(0x00000020);
HW_DRAM_CTL30_WR(0x00000020);
HW_DRAM_CTL31_WR(0x00c80000);
HW_DRAM_CTL32_WR(0x000a23cd);
HW_DRAM_CTL33_WR(0x000000c8);
HW_DRAM_CTL34_WR(0x00006665);
HW_DRAM_CTL36_WR(0x00000101);
HW_DRAM_CTL37_WR(0x00040001);
HW_DRAM_CTL38_WR(0x00000000);
HW_DRAM_CTL39_WR(0x00000000);
HW_DRAM_CTL40_WR(0x00010000);
HW_DRAM_CTL08_WR(0x01000000);
}
Sorry for raising this topic back from the dead, but I didn't want to start a new one since the topic is exactly about the Alliance AS4C32M16D1 chip.
We made a production run with this chip (actually we made boards also with ISSI IS43R16320D, but it has some other issues currently), and after lowering the clock speed to 96mhz (and lowering CAS value to 3), I can boot u-boot every time, but the chip is recognized as 16MB part instead of 64MB.
u-boot seems stable, but if I try to load linux to memory, after I try to boot it, bootm complains that it doesn't recognize the image (I wonder if loading was corrupted, or data is plain lost).
If I flash the same image to a board with original memory used by Olimex (Hynix), it's recognized appropriately - so I think ADDR_PINS and COLUMN_SIZE should be correct as these chips share same count for address and row pins.
I noticed that if I tinker with other values (caslat_lin, caslat_lin_gate, cas), I can get this chip "recognized" as 8MB chip as well (strange, I know), but at that time uboot is not stable, and usually results into reset at some point if I try executing some commands.
The earlier suggestion by some people of setting lowpower_en bit in control register 5 does not help this board to wake up.
Has anyone seen this type of situation where memory chip is not recognized appropriately ? Could this even be a real 16MB chip that was sold as 64MB (though the markings are correct on the chip) ?
This is probably way too late a reply, but if anyone is looking for a solution, changing CAS Latency from 2.0 to CL=2.5 will make the Alliance memory work.
Hi jaycarlson,
Yes, I also got it to work with cas2.5 and with speed of 96MHz.
Or, well, I have 5 boards and 2 boot fine now. Strangely, I am still having memory recognition problems with some of those chips (they are recognized as size of 0 or 16MB).. Did you ever encounter this type of problem ?
Just as a note for others possibly considering similar RAM chips. We are successfully now using both memories in our product.
The problems with RAM not being recognized well turned out to be soldering issues ::)
Well... this is to the thread that will never die.
We made 3000 of the IMX23's since the thread started and now we have 20 that passed returned to us as field failures. In debug we see they now show DDR init errors... just like a bad memory... Since they passes once we looked further and see the boot is OK if the part is well warmer than room temp...
So now it's back to the dwg. board :(
We have tried to see if we can fine tune the MT46V32M16P-5B we are using. So far nothing has helped.
Questions:
CASLAT bit now = 2 (per Micron data sheet) ... could CASLAT_LIN or CASLAT_LIN_GATE (now 0x0404 or 2 cycles) be changed in any way to "fine tune".. We tried 0x0505.. and 0x0303 hoping a miracle would occur and this would dismiss any heat or other layout issues. So far ... it seems clear we cannot tinker with these bit mapped values.
So the big question.. IF we see a> theses few boards work when heated and b> 1000's of others work at all temps , is there ANY registers left to fine tune... or do just write the IMX and Memory combo on these boards as failed and discard them.. and ignore this scary discovery.
From a production perspective, fixing them is ALWAYS preferred so we do not get 100's more back someday due to giving up on this "clue" of a few heat related boards.
Any thoughts on other registers to fool with these boards or adjusting the ones above would be welcome!
thanks
-SR
I don't know anything about DDR timing, etc., but with such a low failure rate & temperature related, maybe you should consider other things such as marginal regulator voltages or decoupling (noise) on the supply lines?
What do the signals look like when failing cf working?
I hope you have good tools and talent...
John
Though I'm not HW engineer, and temperature related failures seem HW design issues, from SW side you could try lowering the actual clock of the DDR.
You would need to play with emi divider and frac divider for this purpose - In uboot this is done in mxs_adjust_memory_clock of spl_mem_init.c. I'm sure very similar code is somewhere in bootlets as well.