Problem bringing up a custom design based on the Sabre SDP i.MX6Q

[timdiebert]

I've got a new hardware design that uses the processor and memory PCB layout from the Sabre SDP iMX6Q dev-kit.  Many of the remaining SDP core features are used as well, but with a different layout.  These include the power/PMIC, SD cards, USB and boot selection.

A minor hardware change was the addition of an additional eMMC chip connected to SD3.  The major change is the use of the EIM to connect with a FPGA, however in our testing to date, the FPGA has been powered off.

So far we've:

   Verified that all of the power supplies are up, and that POR_B is deserted 2mS after the last power supply is up.

   Verified that the clocks are present on the crystals.

   Verified that the boot configuration lines are at the same levels as those on the dev-kit.  (We have the same boot switch that's on the dev-kit)

   With the boot switches set to boot SD2 we observed that data/cmd//clk signals are being delivered to our SD card, but the sequence is not as long as the sequence from the SDP board.

     We changed the boot switches to an invalid configuration and tried to use the USB Mfg Tool to download u-boot, however the PC that the USB is connected to reports 'an unknown device' when the cable is connected.

At this point I've re-read the processor RM and DS, along with everything I can find related to the hardware design, configuration booting...

Since the bulk of the design is the SDP, I'm out of guesses as to where the problem might be, but it seems to be pretty fundamental.

Tim

[igorpadykov]

Hi Tim

it is recommended to start with SDK (one can run it with jtag)

i.MX 6Series Platform SDK : Bare-metal SDK

Also recommended to check fuses (SDK has example), if thay are

healthy and board is not in secure boot.

Best regards

chip

-----------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------

[timdiebert]

chip,

Thanks for the reply.

I’ve already built the SDK and installed it on a 2GB SD card, but it doesn’t load with our hardware. (It works just fine when we use the ‘dev-kit’.) We’ve been looking at the SD card interface hardware with a logic analyzer, and we can see what we assume to be the ROM reading the contents of the SD card, but we never see anything on UART 1’s TX pin, so I’m assuming that the boot ROM operation failed. We have not decoded the SD card CMD/Data output to see the command stream, but that’s on the list.

The suggestion about checking if the thing is in ‘secure boot’ mode is a good one that I didn’t think about. (I assume that a new processor chip from Freescale will not have any fuses blown.)

I've started getting our JTAG debugger to talk to our board, but I still have a lot to learn about it and how it interacts with the system. I plan to use the SDK binary to start with.

Thanks again,

Tim

[igorpadykov]

Hi Tim

you are right  "that a new processor chip from Freescale will not have any fuses blown",

but actually during bring-up and incorrect power-up sequence fuses can be inadvertently blown.

With jtag and SDK (it has fuse read example) one can check them (and probably compare with

i.MX6 Sabre reference board).

Best regards

chip

[timdiebert]

chip,

We’re making progress.

We verified that the fuses are in the default state.

We confirmed that the boot sequence to the SD card is the same for both our board and the dev-kit.

We finally got the JTAG debugger working and we’re testing using the SDK_unit_test_ALL. In running the test we find that we don’t have any output on UART-1, even though the program has reached ALL_test.

So now we get to figure out why our UART-1 doesn’t work and the dev-kit one does. We’ve looked at the signals from the processor UART-1 pins off to our connector and it shows no activity, and that they aren’t tied to ground or power.

Any idea about the kind of hardware design difference or error that would cause the UART not to work. The UART hardware we have is the same as on the dev-kit, so it’s got to be something related, but….

Any ideas are welcome.

Thanks again!

Tim

[igorpadykov]

Hi Tim

you can write to UART registers with jtag and check if  pads are toggling.

One needs to verify that IOMUX settings for these pads are configured

for UART (in SDK one can find such settings, not forget to choose correct i.MX6 chip).

I attached simple project based on SDK, one can try it.

Also one needs to check clocks: 24MHz crystal, 32.768 KHz crystal.

Best regards

chip

[timdiebert]

Chip,

We found our problem. The board reference design files, (Allegro) didn’t match the fabricated dev-kit boards. The board design files show a jumper between the DDR clocks coming out of the processor and the memories. The dev-kit has etch between the pads of the jumper where the design doesn’t. When we installed the jumpers on our board, everything started working as expected.

In the end, it was the board reference design files not matching what actually got built and sold as the ‘reference design board.’

Thanks for all your help with this.

Tim

[timdiebert]

Chip,

Once again, thanks.

We verified that we have both clocks.

We tried to run the binary you suppled, but we noticed that somehow our memory wasn’t set up even though we ran the DDR setup script. I think this is operator error, but we need to investigate this first. If it’s not, we’ll investigate using one of the DDR ram calibration tools.

Do you have Makefiles that use the GNU ‘sorcery’ tool-kit, rather than the Keil-MDK-ARM version to build it? (I can create them without a problem, but I thought I’d ask before doing the work.)

Once we solve our memory mystery, I’ll look at the UART registers.

In addition to the UART problem, the USB serial down-loader has a strange behavior. When we plug the board into a USB port on a PC running Windows 7, it reports the device as ‘unknown’ rather than the HID device it should be. If we plug the device into a Linux box and run ‘lsusb’ it reports the device with the expected mfg and device codes. It also reports the board as a ‘recovery device’ which is what I would expect. I assume that ‘lsusb’ is just doing the enumerate, but nothing that’s device specific. We found a download program for Linux which we’ll try later.

All of this is very frustrating because our hardware design for the core functions like USB and UART is the same as the dev-kit.

Thanks again,

Tim