topic Re: Power up problems in MPC875 in PowerQUICC Processors

Power up problems in MPC875

ramgopaldivakar — Tue, 13 Mar 2018 23:01:12 GMT

I have worked on several MPC875 designs over many years and never faced the problem I am facing. If we power cycle rapidly and not wait for 10 seconds between power cycles then our code crashes after passing through boot stage and somewhere much later. Is it okay if 3.3V ramps slowly in 2 msec and then enable the 1.8V? Or is there specific sequence? The datasheet just says 1.8V must come after 3.3V.

If we wait 10 seconds and power again there are no problems. In a bad case, resetting the processor with hreset doesn't work and code continues to crash. A power off, 10 seconds pause, and power on is needed.

Re: Power up problems in MPC875

alexander_yakov — Wed, 14 Mar 2018 14:16:46 GMT

Please capture scope screenshot of both power supplies and PORESET during this "rapid" restart and submit it here for clarity.

Have a great day,
Alexander
TIC

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

Re: Power up problems in MPC875

ramgopaldivakar — Wed, 14 Mar 2018 15:07:13 GMT

Hello,

thanks for your response. I am drawing power from POE and the 5V created in that circuit feeds into two DC-DC to create 3.3V and 1.8V. They are Linear Tech parts. I have the ability to delay them. Please look at the attachment on pages 2, 3, and 4. Page 1 is taken on a working design. I am trying to make it like page 1 but not done it yet since the power supplies are different between these two projects. The power reset is pulled up to 3.3V. When the voltages stabilize, the FPGA configures and the power reset PORESETn is asserted from the FPGA. The waveforms shown here don't change as observed between working and non-working.

Any ideas to try will be greatly appreciated,

thanks a lot,

Divakar

Re: Power up problems in MPC875

ramgopaldivakar — Wed, 14 Mar 2018 15:13:33 GMT

I am also trying to make 1.8 come up with 3.3 per errata below:

Re: Power up problems in MPC875

alexander_yakov — Wed, 14 Mar 2018 15:53:45 GMT

I do not see anything "rapid" in your scope screenshots. Please clarify the difference between "rapid" and non-"rapid" cases.

Re: Power up problems in MPC875

ramgopaldivakar — Wed, 14 Mar 2018 15:59:26 GMT

I was showing you the voltage rise on a power start. The code crashes even if I wait 5 seconds between power cycles. I need 10 seconds between power cycles for the code to work successfully. If I take a capture of 10 seconds then you won't see what is going on in milliseconds. Hope I am making sense.

Thanks

Re: Power up problems in MPC875

alexander_yakov — Thu, 15 Mar 2018 01:40:44 GMT

Please check if _ALL_ power supplies reach 0V before returning back. 5 sec should be enough to discharge all capacitors, but this depends on consumption, so - please verify this explicitly.

If this will not be helpful, than please debug your code till the instruction which exactly fails. Please determine which particular instruction in your code causes failure at rapid ramp-up. Understanding what this instruction exactly doing will be helpful for further debugging.

Re: Power up problems in MPC875

ramgopaldivakar — Thu, 05 Apr 2018 23:04:47 GMT

Thank you.

The rails do discharge quickly. The code fails much later after 20 seconds when it is trying to configure a SIP stack. This fails only if power is cycled quickly. If we wait for 10 seconds between power ups there is no reset and from then on any amount of HRESET via a push button never fails and the board functions fine. If the board fails on power up or gets stuck, resetting with HRESET will never work. Only way to get back to a working state is to remove power, wait for 10 seconds, and then power.

Could it be anything to do with the way we intialize the SDRAM? Via UPM.

Re: Power up problems in MPC875

alexander_yakov — Sat, 07 Apr 2018 13:38:48 GMT

As per my understanding, "SIP stack" is user software, and this software is configured significantly later than SDRAM initialization. So, I do not think SDRAM is related. However please run SDRAM tests to check this.

By the way, if this "SIP stack" software works with some external hardware, than please add a code to explicitly reset this hardware before re-initialization.

Re: Power up problems in MPC875

ramgopaldivakar — Mon, 09 Apr 2018 12:45:14 GMT

Thanks Yes.

as I said if there was a code problem, it would crash significantly later than SDRAM Init. To reiterate, the software runs fine on an initial power-up. Or, if we power down, wait for 10 seconds, and power on. It will fail on power off and immediate power on.

I suspect the SDRAM init using UPM B. I am attaching what we do. If you have any comments or have UPM B Init code, please send me:

### Sub-Command Locations

UPM_CMD_LOADMODE .equ 0x10

UPM_CMD_NOP_LONG .equ 0x2c

UPM_CMD_NOP_SINGLE .equ 0x2e

UPM_CMD_REFRESH .equ 0x30

UPM_CMD_INIT .equ 0x37

INT_UPMB_Table:

# /* single read. (offset 0x00 in upm RAM) */

.long 0x0f07fc04, 0x0ffffc04, 0x00bdfc04, 0x0ff77c00

.long 0x1ffffc05, 0xef3abc34, 0x1f357c35, 0x0ffffc04

# /* burst read. (offset 0x08 in upm RAM) */

.long 0x0f07fc04, 0x0ffffc04, 0x00bdfc04, 0x00fffc00

.long 0x00fffc00, 0x00fffc00, 0x0ff77c00, 0x1ffffc05

.long 0xef3abc34, 0x0f357c34, 0x1ffffc05, 0x0ffffc04 # UPM_CMD_LOADMODE at 0x10

.long 0x0ffffc04, 0x0ffffc04, 0x0ffffc04, 0x0ffffc04

# /* single write. (offset 0x18 in upm RAM) */

.long 0x0f07fc04, 0x0ffffc00, 0x00bd7c04, 0x0ffffc04

.long 0x0ff77c04, 0x1ffffc05, 0xfffffc04, 0xfffffc04

# /* burst write. (offset 0x20 in upm RAM) */

.long 0x0f07fc04, 0x0ffffc00, 0x00bd7c00, 0x00fffc00

.long 0x00fffc00, 0x00fffc04, 0x0ffffc04, 0x0ff77c04

.long 0x1ffffc05, 0xfffffc04, 0xfffffc04, 0xfffffc04

.long 0x0ffffc84, 0x0ffffc84, 0x1ffffc05, 0xfffffc04 # UPM_CMD_NOP at 0x2C

# /* refresh. (offset 0x30 in upm RAM) */

.long 0x0ff77c04, 0x0ffffc04, 0x0ff5fc84, 0x0ffffc04 # UPM_CMD_REFRESH at 0x30

.long 0x0ffffc04, 0x0ffffc84, 0x1ffffc05, 0x0ff77c04 # UPM_CMD_INIT at 0x37

.long 0x0ffffc04, 0x0ff5fc84, 0x0ffffc04, 0x0ffffc04

# exception is not used, so we are writing init code into the space

# /* exception. (offset 0x3c in upm RAM) */

.long 0x0ffffc04, 0x0ffffc84, 0x0feabc34, 0x1f357c35

addis r5,r0,INT_UPMB_Table@ha # Get beginning address of UPMB table

addi r5,r5,INT_UPMB_Table@l

addi r6,r5,256 # Get end address of UPMB table

lis r7,0x0080 # Load command: write,UPMB,MAD=0

INT_UPMB_Loop:

lwz r3,0(r5) # Get table entry

stw r3,MDR(r4) # Copy to MDR

stw r7,MCR(r4) # Issue command to MCR

addi r5,r5,4 # Point to next entry in table

addi r7,r7,1 # Increment MAD field of MCR command

cmp r5,r6 # Finished?

blt INT_UPMB_Loop # If not, keep looping

lis r3,0x0000

ori r3,r3,0x1111

stw r3,MAMR(r4)

lis r3,0x0492

ori r3,r3,0x4111

stw r3,MBMR(r4)

li r3,0x0200 # MPTPR PTP=32x

sth r3,MPTPR(r4)

# load MAR register with proper format to drive address bus

# 0x22 == burst 4, sequential, etc. ?

lis r3,0x0000

ori r3,r3,(0x0022 << 2)

stw r3,MAR(r4)

# run NOP command 1 times from loc UPM_CMD_NOP_SINGLE -- need at least one NOP

lis r3,0x8080

ori r3,r3,0x4100 + UPM_CMD_NOP_SINGLE

stw r3,MCR(r4)

# run "init" and "load mode register" once from loc UPM_CMD_INIT

lis r3,0x8080

ori r3,r3,0x4200 + UPM_CMD_INIT

stw r3,MCR(r4)

# run NOP command 3 time from loc UPM_CMD_NOP_LONG

lis r3,0x8080

ori r3,r3,0x4100 + UPM_CMD_NOP_LONG

stw r3,MCR(r4)

lis r3,0xfe00 # Burst support; SAM = 1

ori r3,r3,0x0800 # CS2 - SDRAM GPL5 is unused

stw r3,OR2(r4)

lis r3,0x0000 # at 0x00000000 (32 Bits, Parity Dis., UPMB, Valid)

ori r3,r3,0x00C1

stw r3,BR2(r4)