i.MX6Q JTAG Initialization and Image Loading Issues using Sourcery Probe

[MikeJones]

I am having some difficulty getting Sourcery Probe up on the Sabre Smart Devices Board. Mentor has been a great help getting it talking, but I am have problems related to initializing the target, specifically, getting memory tests to run without failure.

The question at the end of these details is: what registers might have to be set besides what is in the DCD to get JTAG to reliably write to memory.

Things that are known to work and demonstrate that this is not a hardware problem:

- primes app runs from SD

- serial download will talk to the manufacturing tools

- linux runs from SD

- Can load image from eclipse, set BP to _start, and can step in code

To get the probe to work, I had to find the dcd.c file in ...smart_device/dcd.c and convert it to register writes in the probes .maj file.

When the probe is connected and the mon app is run, it successfully halts the target, and runs the dcd register initialization. When the register initialization is absent, I can't even download the image, so it is clear that adding the dcd register writes are applied.

The problem is when I run the mon apps memory tests, I have discovered that it fails on every other address. For example:

0x10000000 pass

0x10000004 fail

0x1000000C pass

0x10000010 fail

Passing means it runs in a loop testing w/r, and fail means it fails right away.

I don't have any other initialization of registers other than the DCD ones. So I am not trying to mess with clocks and other things. I am assuming that when the target is powered/reset the ROM code runs and does that, otherwise I could not step through code with a debugger. I wait for some time to ensure the ROM code gets to the point of serial download before trying to connect to the target. I have also verified the WDOG eFuse is not blown using u-boot.

What I am looking for is ideas about what kind of setup problem can cause this kind of memory failure pattern. Is there something critical that the ROM code does that is outside the DCD that I must do to reliably be able to talk to memory though JTAG? Can the JTAG probe interfere with refresh of memory from lack of some proper register value?

[MikeJones]

I have a little more information. I copied the primes app and modified the linker script so that the app only runs in OCRAM. I can run and debug the application with the Sourcery Probe.

Therefore, I think all the problems are initialization problems. So I am looking for ideas related to why using the data from dcd.c will enable the JTAG probe to download data, but memory tests fail, and examining data in the debugger confirms it fails. What else has to be done for the MMDC to work properly?

[Yuri]

Please check if Your JTAG initialization script provides the same DRAM initialization as for Linux (You wrote : "linux runs from SD"). Also note, the DCD in application is processed by boot ROM,  when "primes app runs from SD", but
DCD is not used by JTAG debugger - JTAG init script is intended for it.

Another approach - to run DRAM memory init codes from internal RAM.

[MikeJones]

Yuri,

What I did was take the dcd.c file that the primes app uses, used the #defines to determine the addresses, and created script for the JTAG startup file. I was assuming that if that DCD worked for the primes app when run from SD, it would also work when the JTAG script sets the registers the same way as the DCD and boot ROM set them up.

This is why I wondered if more had to be done than use the values in the DCD. It would seem to me that the DCD had all that was needed, except that I can't make it work. If the boot ROM made some additional register changes, I would need those two.

Mike

[Yuri]

Also You may look at the initialization examples in the Platform SDK

"MX6_PLATFORM_SDK "

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&nodeId=018rH3ZrDRB24A&fpsp=1&tab=Design_Tools_Tab

[MikeJones]

The primes application comes from the MX6_PLATFORM_SDK. The dcd.c file that I used to enhance the Sourcery Probe startup script comes from that app. The remainder of the initialization occurs when the code runs.

For an application to run in DDR, the muxes and MMDC must be setup before the program image is loaded. In this case, the mux and MMDC setup is in the Sourcery Probe script, and comes from the dcd.c file from the SDK.

The memory failure occurs after the mux and MMDC are initialized by the script file. Therefore, I suspect that the ROM boot code has not done all its initialization. The reason would be that without the SD, the ROM enters the serial download mode, and may not complete some initialization.

The memory failure is for every other address. The odd thing is the smart devices board uses one channel of memory. So I am having a hard time imagining what cause failure on every other address. On interleaved memory it would be easier to understand.

I am hoping someone that knows the ROM code will either tell me what else has to be done, or will state the dcd data is enough and offer suggestions on what could have gone wrong.

Here is the data from the probe script that should be the equivalent to the dcd.c file. The dcd.c path in the sdk is SDK/board/mqx6dq/smart_device/dcd.c

ew 0x020E0798 = 0x000C0000

ew 0x020E0758 = 0x00000000

ew 0x020E0588 = 0x00000030

ew 0x020E0594 = 0x00000030

ew 0x020E056c = 0x00000030

ew 0x020E0578 = 0x00000030

ew 0x020E074c = 0x00000030

ew 0x020E057c = 0x00000030

ew 0x020E058c = 0x00000000

ew 0x020E059c = 0x00000030

ew 0x020E05a0 = 0x00000030

ew 0x020E078c = 0x00000030

ew 0x020E0750 = 0x00020000

ew 0x020E05a8 = 0x00000030

ew 0x020E05b0 = 0x00000030

ew 0x020E0524 = 0x00000030

ew 0x020E051c = 0x00000030

ew 0x020E0518 = 0x00000030

ew 0x020E050c = 0x00000030

ew 0x020E05b8 = 0x00000030

ew 0x020E05c0 = 0x00000030

ew 0x020E0774 = 0x00020000

ew 0x020E0784 = 0x00000030

ew 0x020E0788 = 0x00000030

ew 0x020E0794 = 0x00000030

ew 0x020E079c = 0x00000030

ew 0x020E07a0 = 0x00000030

ew 0x020E07a4 = 0x00000030

ew 0x020E07a8 = 0x00000030

ew 0x020E0748 = 0x00000030

ew 0x020E05ac = 0x00000030

ew 0x020E05b4 = 0x00000030

ew 0x020E0528 = 0x00000030

ew 0x020E0520 = 0x00000030

ew 0x020E0514 = 0x00000030

ew 0x020E0510 = 0x00000030

ew 0x020E05bc = 0x00000030

ew 0x020E05c4 = 0x00000030

ew 0x021B0800 = 0xa1390003

ew 0x021B080c = 0x001F001F

ew 0x021B0810 = 0x001F001F

ew 0x021B480c = 0x001F001F

ew 0x021B4810 = 0x001F001F

ew 0x021B083c = 0x43270338

ew 0x021B0840 = 0x03200314

ew 0x021B483c = 0x431A032F

ew 0x021B4840 = 0x03200263

ew 0x021B0848 = 0x4B434748

ew 0x021B4848 = 0x4445404C

ew 0x021B0850 = 0x38444542

ew 0x021B4850 = 0x4935493A

ew 0x021B081c = 0x33333333

ew 0x021B0820 = 0x33333333

ew 0x021B0824 = 0x33333333

ew 0x021B0828 = 0x33333333

ew 0x021B481c = 0x33333333

ew 0x021B4820 = 0x33333333

ew 0x021B4824 = 0x33333333

ew 0x021B4828 = 0x33333333

ew 0x021B08b8 = 0x00000800

ew 0x021B48b8 = 0x00000800

ew 0x021B0004 = 0x00020036

ew 0x021B0008 = 0x09444040

ew 0x021B000c = 0x555A7975

ew 0x021B0010 = 0xFF538F64

ew 0x021B0014 = 0x01FF00DB

ew 0x021B0018 = 0x00001740

ew 0x021B001c = 0x00008000

ew 0x021B002c = 0x000026d2

ew 0x021B0030 = 0x005A1023

ew 0x021B0040 = 0x00000027

ew 0x021B0000 = 0x831A0000

ew 0x021B001c = 0x04088032

ew 0x021B001c = 0x00008033

ew 0x021B001c = 0x00048031

ew 0x021B001c = 0x09408030

ew 0x021B001c = 0x09408038

//   ew 0x021B001c = 0x04008040

ew 0x021B0020 = 0x00005000

ew 0x021B0818 = 0x00011117

ew 0x021B4818 = 0x00011117

ew 0x021B0004 = 0x00025576

ew 0x021B0404 = 0x00011006

ew 0x021B001c = 0x00000000

[Yuri]

I just managed to run memory test on my SDB after "MX6Q_Sabre_SD_DDR3_v1.6.inc" init script using RVDS debugger

with RV ICE. SDB boot options were intended for SD boot, but SD card was not present.

Is it possible to try the same approach on the custom board - configure it for SD boot without SD card inserted ?

Does the problem take place in such case ?    

[MikeJones · Accepted solution]

Looking at the .inc file helped me find a mistake. Thanks.

[MikeJones]

In my case, the board was strapped for SD boot with no SD card. However, it never occurred to me to look at the inc files from another debugger. I will study the inc file for the SD board and compare to the DCD, etc. I can tell from a glance it does more than the DCD.

Thanks, this really gave me some new avenues to explore!