hi
I have been developing custom i.MX53 board based on the QSB.
Now, I will need a memory test program to test the entire DRAM.
Since the entire DRAM test that program, the program can not be placed on the area data DRAM.
I need to write programs that can run on iRAM to output the data from the UART can be controlled by the DRAM.
I'm referring to the source file of u-boot and now OBDS.
However, there is no chance of completion.
Do not you know other information which may be helpful anyone?
Solved! Go to Solution.
Hi,
Sorry, I should have attached the whole project from the beginning. I'm attaching the folder with all the files now. Please note that I have renamed DDR_test.c to main.c so the project is correctly compiled, but it's the same file. As JerryFan pointed, the program is not too stressful, it's just a DDR test with minimum stress, but if you need more stress, you can use this program as base and add the extra instructions according to your needs.
Hope this helps!
Best regards.
Jorge.
The DDR_Test.zip can be a good beginning of your the DDR stress test tool, and you must add some more stressful algorithms. To tell which tool is more stressful, you can run the test with DDR frequency increasing step by step, and record the highest frequency on which the test failed, and the tool which has the lower failure-frequency is more streesfull.
If you can find a algorithms much more stressful than the ones within DDR Stress Tester tool for i.MX53, please let me know.
I had read the DDR_test.c, I am afraid the algorithm for memory testing within this file is not stressful enough for the DDR stability test. OMO, the algorithms within DDR stress tester tool are much stressful, and basically, the DDR stress tester implement the several SSN test with different type, please google "SSN memory" for detail.
Hi,
JTAG stores your test program in iRAM, this is the only way I know to run SW from this location. The only thing you need to do is to set up your scatter file with the iRAM memory address. You'll need the JTAG port of the QSB available and a debugger like the Real View ICE. I'm attaching a simple test code for the DDR, I hope this is useful for you.
Best regards.
Jorge.
Thank you.
It is the source file that contains all the features that I have been looking for!
If based on this source, I think for the memory test program creation is not difficult.
I have one question.
This source file I have been include func.h, where is this file?
I have not been able to find.
Hi,
Sorry, I should have attached the whole project from the beginning. I'm attaching the folder with all the files now. Please note that I have renamed DDR_test.c to main.c so the project is correctly compiled, but it's the same file. As JerryFan pointed, the program is not too stressful, it's just a DDR test with minimum stress, but if you need more stress, you can use this program as base and add the extra instructions according to your needs.
Hope this helps!
Best regards.
Jorge.
As you're planning to write app to test DDR, have you seen DDR Stress Tester tool for i.MX53?
You can download it here (under "Lab and Test Software"):
The program may be tried once.
I gave up the use of the program for the following reasons.
1, I think not test the entire memory from one time per test.
2, Because there was no description of the algorithm for memory testing, I could not be used to assess the quality of their products.
You may use the enclosed example (say, how to configure GPIO on i.MX53 QSB).
Application image may be loaded and run on the QSB using both :
- ATK tool (please look at .jpg(s)) ;
- single UART loader (please look at "mx53_com_load.bat").
Note internal serial (UART / USB) boot mode of the i.MX53 is used here.
Hey Yuri
I downloaded your zip file and tried to run it just to see it download via the serial port and I could never get to "catch" and download via the ROM monitor with the batch file. (I'm on a ARD so it won't actually run.)
Question? Null modem or cross over cable? And what about CTS the manual said the host controls that so I'm guessing you tied it (high/low) on the cable? Finally I did not see an offset for the IVT/BS in the crt.s file like the NOR/NAND (I have both those working but need a fall back boot mode so I want to create a Serial Download image to re-flash NOR/NAND boot images.)
Finally you have a mysterious value in the IVT/BS data (0xF8002000??) what's that value for because the iRAM looks to start at 0xF8006000. So I'm guess that's somewhere in the ROM monitor RAM space.
CRT.S
/* Image Vector Table (IVT) - should be placed before main image */
ivt_header : .byte 0xD1
.byte 0x00
.byte 0x20
.byte 0x40
app_code_jump_vector : .word ResetHandler
.word 0
dcd_ptr : .word 0
boot_data_addr : .word boot_data
self_ptr : .word ivt_header
.word 0
.word 0
boot_data : .word 0xF8002000
image_len : .word 0x10000 /* 64 KB app size */
Thanks Rx
1.
> Null modem or cross over cable?
I am slightly confused, since - my opinion - null modem is just cross cable : TX is tied to RX.
For i.MX53 QSB we should use male-female (pin-to-pin) cable.
2.
> I did not see an offset for the IVT/BS in the crt.s file ...
For (internal) UART loader the header should be the first in stream.
This may be considered as zero offset.
3.
> ... mysterious value in the IVT/BS data (0xF8002000??) what's that value for because the iRAM
> looks to start at 0xF8006000
Correct - it should be 0xF8006000. Earlier I used start address at 0xF8002000.
4.
Please check if internal serial UART / USB boot mode is selected.
Thanks Yuri
1.
Null modem or cross over cable?
>>I am slightly confused, since - my opinion - null modem is just cross
cable : TX is tied to RX.
>>For i.MX53 QSB we should use male-female (pin-to-pin) cable.
Thanks, I don't have a RS232 on the back of my PC so I'm using a USB to
RS232 cabled (9pin) to connect to the board and it works fine for U-Boot
and Linux but does not work for the MX_Serial.exe program so I wanted to
know the pin out on your cable just in case some other pins were cross or
tied high or low.
Also do you have the source for the MX_Serial.exe program?
Thanks
Rx.
Dear Yuri,
I'm in a process of serial downloading of iMX-53 micro via UART port. I study your examples of target code and UART downloader and have some questions.
1. As I understood, the IVT header has to be placed at the head point of program image. But I did'n found the IVT in *.map file of target software, it seems to be removed by linker, because it has no any external references. The program image is downloading from 0xF8006000, which is the interrupt vector table address.
2. From the UART loader source file, I found that You download the program image by several blocks using the 0x00 file type identifier, which differ from identifiers, listed in 7.8.3.5 item. Then You complete the download procedure with writting of zero-length block at RESET address as an 'application' type file and get status as 'completed' command. Is it enough to perform firmware startup from downloded image? It seems to be useful, because allows program downloading at different memory areas (e.g. to place interrupt vectors and routines in iRAM while other program locates in DDR).
If more suitable, we can correspond in russian via e-mail pan@infotek.ru
Please look at my comments below :
1.
> As I understood, the IVT header has to be placed at the head point of program image.
Correct,
UART boot loader expects the IVT data first in boot stream in order to define such parameters
as application image length (image_len), address to load (boot_data_addr), start address
(app_code_jump_vector).
1.1.
> But I did'n found the IVT in *.map file of target software, it seems to be removed by linker,
> because it has no any external references.
Yes, I think it is enough to define global label in IVT to get it in the map. But again, the IVT addresses
for UART bootloader are not defined ; as mentioned, the IVT table should be first in the stream.
In contrast, we have predefined IVT locations for NAND or SD boot. And this is a prerogative of
NAND / SD bootloader to read proper block of data first in order to define IVT parameters.
2.
As for UART loader sources – it is adaptation of i.MX21 loader from redboot package, and, strictly
speaking, I am not fully sure, that all is OK for i.MX53. As usually, the debugging was stopped after
first successful loading. So, fill free to modify and develop it as needed.
Dear Yuri,
now I have the first successfull experience of iMX35 downloading via
UART serial interface.
Generally speaking, its is very close to Your recomendations, below
there are some issues, which I wish to note specially.
1. The DDR was configured with DCD settings, which were performed by
series of MemoryWrite commands. It was more convenient to me to make a
separate assembler file, containing DCD table only (with corrected
endian format, MSB first), which was built in separated *.hex file. At
iMX downloading startup, this file is opening and then read row-by-row
with standard fgets(*file) command. DCD configuration completes at the
standard end of INTEL hex file.
2. To provide program image downloading in different memory areas (e.g.
I have interrupt routines in iRAM to improve the productivity), the
other INTEL hex file is also suitable, The downloading procedure is also
performing row-by-row with WriteFile commands, containing the address,
taken from hex file string (accounting the segment address from special
hex strings), the bytes counter is the number of bytes (not ASCII
chars!) in hex string and file type is unspecified (I used simple 0x00).
When whole file was donloaded, the WriteFile command with program image
start address, zero length and filetype=0xAA (application) was issued
and followed by GetStatus command to start the execution.
3. The IVT was placed right before the program image and was created in
assembler startup file with special section, linked to Start_of_RAM address.
Thank You for assistance,
Andrey.
06.03.2013 5:34, Yuri Muhin написал:
>
Freescale Community <https://community.freescale.com/index.jspa>
<https://community.freescale.com/index.jspa>
>
How do you make a program that runs on the iRAM?
created by Yuri Muhin <https://community.freescale.com/people/Yuri> in
/i.MX Community/ - View the full discussion
<https://community.freescale.com/message/318319#318319>
Thanks Yuri,
For the Software.
I believe my problem is the HW difference between the QSB and the ARD (Auto/DDR3) board. The RM (7.8.2.1) said they have to be wired up (UART1) TX->CSIO_DAT10.alt2 & RX->CSIO_DAT11.alt2 and the ARD board isn't wired that way so the ROM monitor never see the data coming in on UART1. (Other Uarts are not accessible on the ARD with a connector. So those are not an option either.)
If somebody comes up with a different explanation or suggestion I'd like to hear it?
You are right – boot ROM Serial Downloader can work only with
the UART configurations, mentioned in Table 7-43 (UART IOMUX Pin
Configuration) of the i.MX53 Reference Manual.
For the SABRE AI design the next UART1 pins are used :
UART1_TX(PATA_DIOW).
UART1_RX(PATA_DMACK).
This configuration is not supported by boot ROM.
But UART2 may be used, please try it :
UART2_RX(PATA_BUFFER_EN).
UART2_TX(PATA_DMARQ).
Thanks,
On Fri, Dec 14, 2012 at 12:59 AM, Yuri Muhin
Thank you for your source file.
I would like to create a memory test program using this file.
Thank you very much.