i.MX 8M Mini DDR tool hangs after programming board

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX 8M Mini DDR tool hangs after programming board

Jump to solution
1,168 Views
adevries
Contributor V

Hello,

I have a custom designed board using an 8M Mini processor on it. In the process of developing with this board, I ran the mscale DDR evaluation tool successfully on it before loading any software on it. After loading some software on it and burning the fuse bank at address 0x470, I wanted to run the DDR tool again, so I set the BOOT_MODE[1:0] pins = 01 (for serial download mode) and found that I was now unable to run the DDR tool. This is output log from the tool:

"Downloading file 'bin\lpddr4_train1d_string.bin' ..Done

Downloading file 'bin\lpddr4_train2d_string.bin' ..Done

Downloading file 'bin\lpddr4_pmu_train_1d_imem.bin' ..Done

Downloading file 'bin\lpddr4_pmu_train_1d_dmem.bin' ..Done

Downloading file 'bin\lpddr4_pmu_train_2d_imem.bin' ..Done

Downloading file 'bin\lpddr4_pmu_train_2d_dmem.bin' ..Done

Downloading IVT header...Done
Downloading file 'bin\m845s_ddr_stress_test.bin' ...Done

Download is complete
Waiting for the target board boot..."

The tool just hangs after this. Note: I can go back to BOOT_MODE = 00 and the board boots just fine. Has anyone run into a similar issue? Can anyone explain what's going on here or how I can investigate this issue more? Any help would be appreciated.

Thanks

Labels (1)
0 Kudos
1 Solution
1,083 Views
adevries
Contributor V

I was able to solve my issue. I was accidentally putting the processor in boundary scan mode (by pulling BOOT_MODE0, BOOT_MODE1, and TEST_MODE high) instead of serial download mode. After fixing the hardware mistake, the board functions as intended. This issue was difficult to diagnose because when the processor is in boundary scan mode, it appears as the same SE BLANK device as when it's in serial download mode.

View solution in original post

0 Kudos
2 Replies
1,084 Views
adevries
Contributor V

I was able to solve my issue. I was accidentally putting the processor in boundary scan mode (by pulling BOOT_MODE0, BOOT_MODE1, and TEST_MODE high) instead of serial download mode. After fixing the hardware mistake, the board functions as intended. This issue was difficult to diagnose because when the processor is in boundary scan mode, it appears as the same SE BLANK device as when it's in serial download mode.

0 Kudos
1,083 Views
adevries
Contributor V

I've continued to work on this issue, and haven't made much progress unfortunately. I'm wondering if the SPL file is somehow preventing the board from rebooting, or enumerating properly. If anyone has any experience with this lower-level boot process, I would value your input.

Thanks

0 Kudos