MX233 getting "HTLLC" continuously during boot using bootlets and uboot. Some ROM bootloader questions.

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

MX233 getting "HTLLC" continuously during boot using bootlets and uboot. Some ROM bootloader questions.

3,305 Views
hak8or
Contributor II

So I finally was able to blow the OTP fuses to have it boot from an MBR based SD card which was good, but then every time I try to boot using either u-boot images or even bootlets from freescale, Bootlets compiled using this. I get in my serial console "HTLLC" repeating which from what I understand is the ROM doing the following.

  • H - Header found
  • T - Tag found
  • L - Load
  • L - Load
  • C - Call

This is what my efforts have looked like:

▒▒▒▒▒▒▒▒ϱ▒[▒@

             ▒ ▒▒▒▒޼▒J▒@%

Data Abort

r14_HTLLCHTLLCLCHTLLCHTLLCLC

Undefined Instruction

r14_unHTLLCHTLLCHTLLCHTLLCHTLLCHTLLCHTLLCHTLLCHTLLCHTLLCLC

Undefined Instruction

r14_unHTLLCHTLLCHTLLCHTLLCHTLLC

Un▒HTLLCHTLLCLC

Undefined Instruction

r14_unHTLLCHTLLCHTLLCHTLLCLC

Undefined Instruction

r14_unHTLLCHTLLCHTLLCHTLLCHTLLCHTLLCHTLLCHTLLCHTLLCHTLLCHTLLCHTLLCHTLLCHTLLC

So after googling and reading here, that seems to indicate that there is likely something wrong with memory or power draw issues. To make sure it's not power draw issues, I am not using the MX233's PMU and instead an external regulated power supply to supply the various required voltages (2.5, 3.3, etc). I will not use an external power supply for the power rails as suggested by Igor.

I am using a AS4C32M16D1-5TCN DRAM ic including length tuned traces with a length of ~750 mil, so I am doubtful it's due to signal integrity issues. Based on discussion here, it seems that there has been varying success.

My questions are these (I am using freescale bootlets since they seem recommended here when trying to work out issues):

  • What is the first function the ROM calls? Is it _start() in init-max23.c? Basically, what's the C in HTLLC calling?
  • Are these first L's loading into external memory, or the internal SRAM?
  • How can I change the speed of the default DRAM assumed in the bootlet?
  • I see functions like init_mddr_mt46h32m16lf_96Mhz() but if I stick a printf's at the start of each similar function at the beginning I don't see anything different on my terminal. So I assume these aren't used to setup DRAM.
  • Am I SOL for going with the Alliance DRAM? I am not seeing any DRAM's used in the omnilex nor the freescale reference design available on digikey or mouser, so it seems this is true sadly.

Note, this is an extension somewhat of my previous post here.

Edit:

Seems my 2.5v rail is not powering up, even when nothing is connected to it, huh.

VDRAM_Rail_not_powering_up.png

Labels (1)
Tags (2)
12 Replies

2,032 Views
EgleTeam
Contributor V

Hello,

Can you share some more details about your PCB design?. Layers, power planes, bypass/bulk capacitors, oscillator and load capacitors, impedance control, DC/DC inductor, and so on...

Best regards,

Manuel.

0 Kudos

2,032 Views
hak8or
Contributor II

Sure!

Might as well just throw the design files up here since this is not a commercial design and instead just a student project. Some of the notes saying my understanding of PSwitch and whatnot are wrong since this was designed a month or so ago. The air wires visible in the PCB views have been solved using external wires I soldered. I was reading this about the 4.2 rail so I will get going and soon solder on some decoupling capacitors to it.

MX_233_Linux.PDF - Google Drive

0 Kudos

2,032 Views
EgleTeam
Contributor V

Some advices:

1. Use thicker nets for the inductor.

2. Use 45º net routing not 90º (length matching).

3. R11 and R12 MUST be 1% or less.

4. If you solder the PCB by hand, use solder paste + hot air (much better than solder iron + tin wire).

5. MOST important: 2 layer board is not a reliable solution for a processor + DDR. 2 layer PCBs work well for some analog circuits and low speed digital circuits (i.e: microcontrollers) but this is not the case

Best regards,

Manuel.

2,032 Views
hak8or
Contributor II

Actually, I hit a snag of sorts and am somewhat confused.

Does the ROM load code into internal SRAM and then execute from there, or does it somehow do some magic where it executes some DRAM config code and *then* load code into the DRAM?

The memory voltage regulator is linear and feeds off of the 3.3v vddio rail. Shouldn't it rise to 2.5v by default along with the rest of the linear regulators, even if the ROM doesn't load any code? Or does the code that the ROM load have to manually enable the vddmem regulator?

0 Kudos

2,032 Views
igorpadykov
NXP Employee
NXP Employee

Hi hak8or

you are right, there is "some magic" in i.MX23/MX28 boot process.

in general boot process is described in sect.12.11 SD/MMC Boot Mode

MCIMX28RM  (the same is for i.MX233), IMX23RM Chapter 35 Boot Modes,

sect.1.1 Boot Stream attached i.MX23_Linux_BSP_UserGuide.pdf,

AN4199  rev.1  9_2010.pdf. Some regulators (such as vddmem) are

not enabled by default, they should be enabled by software, one can find default

values in Chapter 32 Power Supply i.MX23 RM.

Some initialization code is performed by iROM (check attached uboot.db, link.lds,

init-mx23.c from Freescale BSP bootlets sources ) from internal iRAM, then after DDR

initialization uboot/linux code is loaded to DDR.

Ii your case (seems) processor continuosly resets due to some brownout,

before entering to DDR initialization. You can attach jtag debugger and test memory with

debugger and try to run bootlets with jtag. If your board design is based on

olinuxino board, then one needs to use images for olinuxino board.

If board is based on Freescale iMX23 Reference Schematics   then

one can use Freescale BSP L2.6.31_10.05.00_SDK_SOURCE : Linux 2.6.31 Source Code Files.

Best regards

igor

2,032 Views
hak8or
Contributor II

Thank you so much for the info and whatnot!

My confusion earlier arose from not knowing if the ROM code does solely what was described in the PDF's for the boot mode description used for SD booting, or if it also was doing something else. You suggesting it is possibly resetting due to brownout is a major help because the entire time I was thinking that I wasn't getting past the first C in "HTLLC" because my DRAM was wreaking havoc.

Sadly I don't have any sort of JTAG debugger as of yet. Should have gotten the Segger J-Link and then your S-JTAG -> JTAG adapter as I was considering earlier, would have been a major help since I could then see for myself what is going on.

I took what I assumed to be the minimum critical components from both the Omilex and your reference design and used mine. The only differences are usage of different DRAM (the ones used in both designs aren't available on digikey or mouser sadly) and the 4.2v rail not having any decoupling capacitors by mistake. I will be fixing the 4.2v rail issue tonight hopefully and that might help things out while I am waiting for my 4 layer board to arrive. I linked to my design documentation here.

Again, thanks a bunch! Cleared things up a good bit and now I have a much better idea of what to look for.

0 Kudos

2,032 Views
igorpadykov
NXP Employee
NXP Employee

Hi hak8or

seems all signals VDD4P2,DCDC_BATTERY,BATT are

NC on schematic MX_233_Linux.PDF - Google Drive

I am afraid this may not work. Suggest to check carefully latest

(it is different from attached here) AN4199

Using the i.MX28 Power Management Unit and Battery Charger

for supported configurations.

Best regards

igor

0 Kudos

2,032 Views
hak8or
Contributor II

I was under the impression that DCDC_BATTERY and BATT can be left NC because I am not interested in using a battery? This page shows a user not having them connected and even saying that when they were connected he was having issues.

Regarding VDD4P2, I just now threw a 4.7 uF ceramic capacitor on there and things are surprisingly much worse, with no SD card even inserted I am getting just R14 *something* abort, be it prefetch abort or data abort, not even anything similar to HTLLC. Pulling up both DCDC_BATT and BATT to the 4.2v rail using 1k resistors as shown in the i.MX28 PMU sheet you linked doesn't make things any better for me. I will now just assume that I finally thermally damaged the chip after poking around in it with my soldering iron too much and will consider this board a lost cause. Now to just wait for my other board to arrive.

Regardless, thanks again for all your help!

0 Kudos

2,031 Views
mlopez
Contributor III

Hi,

I had problems in all of  my boards with DCDC_BATT and BATT left unconnected.

By placing a 1K pull-up resistor to 4.2V and a 33uF capacitor to ground to both pins connected together, all the boards starts OK.


There is also another issue with DDR voltage. Some of the new, faster memories, need 2.6V to work correctly (for example Micron with -5B speed grade). U-boot, for example, only configures 2.5V and it does not work ok with that memories. You should check your memory/boot for this.


Regards

0 Kudos

2,031 Views
igorpadykov
NXP Employee
NXP Employee

you should use DC-DC in any way for correct operation.

It can work from DCDC_BATTERY or VDD4P2, please read AN4199.

0 Kudos

2,031 Views
hak8or
Contributor II

Thanks a ton for the tips!

I hadn't realized that I didn't use 1% resistors for the DRAM vref pin, whoops. I will also add a second capacitor across the other resistor of the voltage divider.

I most certainly did use solder paste and hot air, I can't imagine doing a board like this using a spool of solder! :smileysilly:

I was under the impression that 90 degree bends used for length matching are fine if the signals involved are at or below the 133 Mhz DDR area, though it seems that's not the case.

I originally used a 4 layer board for the AT91SAM9N12 and DDR2 memory but I figured that for the MX233 I wouldn't be in dire need of a four layer board.

Thanks for all the advice! I will make another board and while waiting for it to show up I will continue to see if I can get this one working.

0 Kudos

2,031 Views
EgleTeam
Contributor V

Have a look to this doc (mx28x and mx233 are pretty similar):

http://cache.freescale.com/files/32bit/doc/app_note/AN4215.pdf?fr=gdc

Good luck!

Manuel.