Need help with MPC8308

ChrisDarrow · ‎12-31-2015

Hello NXP Tech Support,

I am working with a customer on an issue below. Can you please help provide guidance?

Thanks,

Chris

From: Josh

Sent: Wednesday, December 30, 2015 8:17 PM

To: CHRIS DARROW

Cc: Stephen Harper; 'Andy Chen - NXP'

Subject: RE: MPC8308 boot issues

Hi Chris - Thank you for the update. I will double check that I am referencing the most recent documentation. I will also double check the voltage levels going to the part to insure they are in spec (I have tested the levels before the processor beads but I'll double check the levels at the processor directly). All of the processor power pins are indeed powered up even though we are not using the PCIe interface.

On our end we were able to attach a debugger and are stepping through the low level uboot assembly and INIT code right now. The processor does read the reset config words (we confirmed that in the processor's register space) and we are trying to find the exact point at which the processor hangs on the uboot code. This code is unchanged from other boards and boots just fine on those; so it should be a known good (it is also based on original freescale uboot code). So it's a big mystery right now why it is crashing at some early point in the code before the external clocks are even turned on. I'm hoping to have a concrete code location tomorrow as to where this processor is hanging.

Thank you for the quick response on this item

Josh

From: CHRIS DARROW

Sent: Wednesday, December 30, 2015 7:10 PM

To: 'Josh'

Cc: Stephen Harper; Andy Chen - NXP (andy.chen@nxp.com<mailto:andy.chen@nxp.com>)

Subject: RE: MPC8308 boot issues

Hello Josh,

You have probably already located it all, but the latest documentation for the MPC8308 is located here:

http://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/powerquicc...

I have attached the Design Checklist App Note (AN4028) in case you have not seen it. It was updated Nov 2014, so it is newer than I had on my machine. At the link above, you can also get the latest Reference Manual and datasheet. Again, both were newer than I had on my machine. Not sure if you already downloaded the latest docs or not.

Regarding your items below:

1. Do you use PCIe? If not, then tying SD_REF_CLKP to ground should not affect anything.

2. For PCIE_RXAP/N, I assume you mean RXA for the PCIe (docs do not call it PCIE_RXAP/N - just making sure we are talking about the same thing). Again, if not using PCIe, then tying to ground should not affect anything.

3. Power sequencing -

a. Read section 2.1.4 of the attached datasheet (MPC8308EC - Rev 4 - Dec'14.pdf) to make sure you are following the proper power up sequencing. It appears that the VDD core must come up before anything else. Would agree that the NVDD vs. GVDD vs. LVDD sequence shouldn't matter.

b. Are you sure that nothing ramps up to a value higher than the specs? Read where you need to be careful about that, so not sure if you have validated that part of the power design.

c. All the power pins must be tied to their corresponding voltages irrespective of the fact that a module is used or not in the system. For example, even if PCI Express interface is not used in the system, the PCI Express power pins (SDAVDD, XPADVDD, and XCOREVDD) must be tied to their corresponding voltages.

Please let me know if you have made any more progress.

Thanks,

Chris

From: CHRIS DARROW

Sent: Wednesday, December 30, 2015 4:31 PM

To: 'Josh'

Cc: Stephen Harper; Andy Chen - NXP (andy.chen@nxp.com<mailto:andy.chen@nxp.com>)

Subject: RE: MPC8308 boot issues

Hello Josh,

Thanks for the very thorough write up.

For the PN differences, all the 'C' in the part number indicates is an extended temp range beyond the non-'C' parts.

I am going to search through some documentation and confirm the info below. And I will get back to you shortly.

Thanks,

Chris

From: Josh

Sent: Wednesday, December 30, 2015 11:19 AM

To: CHRIS DARROW

Subject: MPC8308 boot issues

Hello Chris - I am having issues booting a new board design (EGM4A) with a MPC8308 processor and I was hoping you could help. At this point in the debugging it is starting to look more and more like a potential issue or bug with the batch of processors that are installed on these boards. The processor section on this new board is almost identical to two other boards that we have currently running in the lab that also contain an MPC8308. We are running the same software across boards and I have tried replicating the minor schematic / reset differences between working designs and non-working designs and these changes do not resolve the issue. The MPC8308 processors on this new board are from a different lot of production so I am wondering if there is something wrong with this batch. I have mostly ruled out an assembly issue since I can read and write flash and DRAM when using a JTAG based debugger. However, booting directly from NOR does not work. Also, all of the new EGM4A boards that we have built show the same symptoms below. Do you have time to discuss this issue this week?

EGM4A board (not booting):

Programming the flash:

1. I am able to connect a BDI3000 pod to the processor and execute the INIT script (which runs over JTAG). This script properly programs all external clocks on the processor.

2. This pod is also able to fully program the NOR flash and I can read back the NOR and confirm the data matches the written data.

MPC8308 Boot sequence of events:

1. The board is first booted with the BDI3000 pod and the NOR flash memory is programmed. Then power and the pod are removed from the board.

2. External 48V power is applied to the board

3. An onboard sequencing chip brings up the 1V rail first then waits ~2ms

4. The sequencer then brings up the 1.8V rail followed by the 3.3V rail after ~0.5ms

5. The 25Mhz clock to the processor will come up within a few us after the 3.3V is up. This clock is directly driven from an oscillator to the processor.

6. When the 3.3V rail and 1.8V rail are up an onboard CPLD asserts PORRESET & TRST to the processor for ~500ms and then releases them.

7. The processor asserts HRESET once PORRESET is asserted.

8. The CPLD drives the CFG_RESET_SOURCE & BOOT_ECC values while HRESET is asserted.

9. The processor samples CFG_RESET_SOURCE & BOOT_ECC

Confirmed that these are sampled because later on the processor boots from NOR indicating that it understood the boot location

I also tried changing the CFG_RESET_SOURCE values to a boot device that does not contain boot code and the processor doesn't try to read from NOR. So this verifies that these are properly sampled.

10. The processor locks its internal PLL

Indirectly confirmed because the processor de-asserts HRESET, which supposedly only occurs after the PLL locks

11. The processor then begins reading from the start of the attached NOR flash for the reset config words

I have confirmed with an o-scope that the reset config words read by the processor out of the flash match the reset words that are desired and were programmed into the flash. I also verified the flash contents during programming and they matched a known good u-boot file.

I have probed TSEC1 TX_EN and it never goes high. Which indicates that reading the reset config words was successful during boot.

12. The processor then jumps to the address that is the start of the u-boot code in NOR and starts reading from flash.

13. The processor never stops reading from flash and it does not configure its external clocks properly based on the config word registers

The first things that u-boot code executes are additional INIT registers that are necessary to configure the external clocks. Since these clocks do not come up, it indicates that these INIT registers are not properly programmed. So that means the processor is hanging very early.

I have tested the INIT theory by modifying the BDI3000 pod INIT script and commenting out the latter half of the code. Then when I run this INIT script via the pod the processor hangs in the same way it hangs when booting from flash (it doesn't configure external clocks but it doesn't read from flash since it was not told to boot from flash)

On other boards when there is a bug in u-boot located on NOR, I have seen the processor constantly read from flash while trying to boot. So this indicates that the processor is indeed hung at some point in the boot processor when it hits an issue with the boot code.

Schematic differences from known good designs:

1. SD_REF_CLKP/N are tied low on EGM4A

On working designs a 100Mhz clock was applied. But I did remove the 100Mhz clock from working designs and they still booted.

2. PCIE_RXAP/N are tied low on EGM4A

On working designs this input is floating.

3. The 1.8V rail comes up before the 3.3V rail

On working designs the 3.3V rail comes up before the 1.8V rail (according to the datasheet this should not matter)

4. Note: These schematics were all based on the MPC8308 RDB.

MPC8308 processor markings:

1. MPC83080VMAFDA

2. 333/266 MHZ

3. CTQGP1539

4. CHINA

5. 01M17Y DJAUCTB

EGM3R (working MPC8308 design):

MPC8308 processor markings:

o MPC8308CVMAFDA

o 333 / 266 MHZ

o CTQXX1510

o CHINA

o 01M17Y BKAKCTAJ

EGM3F (working MPC8308 design):

MPC8308 processor markings:

o MPC8308CVMAFDA

o 333 / 266 MHZ

o CTQHM1411

o CHINA

o 01M17Y AHAGCTA

Thank you

Josh

Regards,

Chris Darrow

Senior Field Applications Engineer

Arrow Electronics, Inc.

20935 Warner Center Lane, Suite A

Woodland Hills, CA 91367

805-207-1387 cellular

cdarrow@arrow.com<mailto:cdarrow@arrow.com>

parts.arrow.com<http://www.parts.arrow.com/>

alexander_yakov · ‎01-01-2016

Further debugging the init code to understand where the device hangs - should be helpful to understand the root cause of the issue.

If you suspect particular device batch, please try to solder the device from another batch.

If voltage sequencing is changed from previous known good design, than please make sure reset is deasserted after all power supplies become stable in this new power sequencing.