Power up problems in MPC875

ramgopaldivakar · ‎03-13-2018

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.

ramgopaldivakar · ‎03-14-2018

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

alexander_yakov · ‎03-14-2018

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

ramgopaldivakar · ‎03-14-2018

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

alexander_yakov · ‎03-14-2018

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.

ramgopaldivakar · ‎04-05-2018

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.

alexander_yakov · ‎04-07-2018

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.

ramgopaldivakar · ‎04-09-2018

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)

ramgopaldivakar · ‎03-14-2018

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

alexander_yakov · ‎03-14-2018

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!
-----------------------------------------------------------------------------------------------------------------------