DM8168 power-up instability

Hello,

So do you mean that you confirmed that it is following the correct power up sequence?

Can you please provide any output logs you see on the UART output?

Regards,
Marc

Thanks for your reply!  I have checked the power up sequence !And it does meet the requirement! But there is not any message output on the UART when turn on the switch of power for DM8168 !and then i checked the DDR3 clock,it is also not output,I checked the Pin of SD card power enable(U4)at the same time,this pin is also keep in low level  !  But sometimes the chip could boot up correctly,the DDR3 clock and the Pin of U4 are all right!and the message is printed on the UART just like the EVM board!  So i am confused with this condition!

The follow is power sequence in time and the PowerOn reset 

3.3V 0ms (beginning）

1.0V_AVS 4ms

1.0V_CON    6ms

1.8V 26ms

1.5V 34ms

0.9V 48ms

PowerOnReset 400ms （end)

and another question is :If the power does not meet the sequence requirements,DM8168 chip's internal logic would be damaged?

Yes.

Hi ,there is another question:the implementation of SmartReflex AVS is necessary or just recommended? does it can affect the chip boot up? Thanks! 

It will not affect chip bootup, but AVS is required for correct chip operation.

Regards,
Marc

HI~~~Lin, have you solved the problem?I made a board as the TI DM8168 EVM sch(version G). I meet the same situation as you, the power sequence goes fine, but there is no output when power up. Do you have some suggestion? Does anybody have some idea?

We meet the similar problem here. There are some boards can't finish the boot process. The power sequence is in line with the datasheet. The tracing register 0x4031D040h shows a value of 0x6. It means the ROM boot code can't reach the 2nd stage boot process. And if we connect to the A8 core using CCS and use assembly step to debug, it would loop in below 3 instructions： 

00021abe:   1570F8D0 LDRNEB          PC, [R0, #--2256]!

00021ac2:   3F40F411 SWICC           #4256785

00021ac6:   4809D1FA STMMIED         R9, {R1, R3, R4, R5, R6, R7, R8, R12, R14, PC}

 Anyone can shed some light here? We are stuck in for a long time.

   Please check the AVS output from very beginning of power up, it shall be set higher (about 1.2V) instead of 0.9V for normal boo-up and then can be lowered down later according to application needs by using the PMBus commands through registers of VOUT_TRIM, VOUT_MARGIN_HIGH and VOUT_MARGIN_LOW.

  Thanks!

  Phil

I'm having the same problem just like the few others did. It's a customized board (not EVM) with DM8168. The processor boots from SD. On 3 out of 5 boards, it seems to bootup consistently; while on the other two it doesn't boot at all, although the power sequence looks almost identical to all 5 boards. The picture below shows the sequence:

Does the sequence look wrong to anyone?

If anyone has resolved the problem, would you mind telling me how you made it?

Thanks!

Nikko

If we use fixed AVS voltage to 1.0V.

What is the potential problem?

Hi Phil,

Can you explain a little bit why the AVS needs to be set higher than 1.0V at the beginning of power up? If the rail needs to stay at about 1.2V, how long is the period before the rail is lowered back to 1.0V?

Thanks,

Nikko

In datasheet

6.2 Recommended Operating Conditions     points out CVDD is  0.8V~1.05V, that is why it is recommended to set AVS-1V initial value higher than 1V.   Just to ensure the chip can work from the start.

You can add prints in AVS driver to check when it adjust the voltage.

BR,
Eason

Thank you Eason for your reply. Now my question is, do I have to keep AVS-1V software controllable? I've tried to tune the output voltage from 1.0V to 1.05V, but still the proc will not bootup. 

Thanks,

Nikko

Hi Nikko,

You may also need to check if clocks/DDR is good.

You can try to use UART bootmode to check if the Netra ROM boot is OK, then use BSL project from http://support.spectrumdigital.com/boards/evm816x/revg/   to check if DDR is stable ...

BR,

Eason

We are stuck at the exactly same place. The trace vector is also 0x06, and the boot rom is stuck at the same place. Some of our boards work, and some don't. If any of you have solved the problem, please post what you did to fix it. This will really benefit the community! Thanks.

Hi Tiebing,

It turns out our booting issue is caused by DDR register settings. This seems to be a common issue encountered by many others. Tuning the DDR register values is referred to as software leveling (http://processors.wiki.ti.com/index.php/DM816x_C6A816x_AM389x_DDR3_Init). The tuning is mostly based on two sets of information: 1) the particular SDRAM device on your board; and 2) the circuit board physical layout. For the first part you need to download DM816x_C6A816x_AM389x_EMIF4_Register_Settings.zip and follow the instructions to revise the register values accordingly. The revised values then should be plugged into the U-Boot code. The second part involves extracting the seed values from your board layout and running an app (the .out program) from CCS

With the first part figured out, I've been able to boot all the boards consistently. However, I'm still stuck with this part maybe because of the emulator. I do believe though, both are necessary to get the DDR running reliably. 

Hope this helps.

Nikko

Nikko, thanks for sharing.

The problem I am having seems to different than yours. Out of the 40 boards we made, 32 of them can boot fine. 8 of them do not boot at all. When looking at the trace vector at 0x4301d040, the value is 06h, which indicates that the board did not pass the public reset vector, and did not enter the main booting routine in the Boot ROM code. At that stage, DDR should not be involved yet. This seems to point to power or clock. Our team has tried various things about the power sequence within the TI AM3894 datasheet, and it does not seem to help. That's why we are interested to know how the rest of the community is dealing with this problem (or maybe this is unique to our board).

We have even replaced the AM3894 IC on 5 of the bad boards, and after that, 4 of them were able to boot fine. SMT has been double checked and everything seems fine. So it points to that some ICs are more tolerant than others with signals.