Milkymist One Power On Off Sequence

From Qi-Hardware
Revision as of 07:45, 23 February 2011 by Adamwang (Talk | contribs)
Jump to: navigation, search

Contents

Normal RC2 Power On Off Sequence

Known un-booted conditions

Fig. 2, With Sch. 1. How "fast" power cycling it is!


When unbooted condition is happened, the LED D2,D3 lights slightly. You probably can boot next power plug-in or never boot at all forever.

  • Rarely happens: even power adapter plugs-in.
  • Often appears: power on then off, and power on again with tiny duration said like below 100ms.

The schematics of three experiments

Configuration Sequence

Fig. 3, FPGA Cofiguration Sequence


Usefull pin of FPGA Configuration

  • PROGRAM_B : It's a dedicated input pin for Active-Low asynchronous full-chip reset. When asserted Low for 500 ns or longer, forces the FPGA to restart its configuration process by clearing configuration memory and resetting the DONE and INIT_B pins after PROGRAM_B returns High.
  • During Configuration: Must be High to allow configuration to start.
  • After Configuration: Drive PROGRAM_B Low and release to reprogram FPGA. Hold ROGRAM_B to force the FPGA I/O pins into High-Z, allowing direct programming access to SPI flash PROM pins.

Power-On Sequence Precautions for FPGA[5].

One of the following system design approaches can ensure that the SPI flash is ready to receive commands before the FPGA starts its configuration procedure:

1. Control the sequence of the power supplies such that the SPI flash is certain to be powered and ready
 for asynchronous reads before the FPGA begins its configuration procedure.
2. Hold the FPGA PROGRAM_B pin Low from power-up to delay the start of the FPGA configuration procedure
 and release the PROGRAM_B pin to High after the SPI flash is fully powered and is able to receive 
 commands.
3. Hold the FPGA INIT_B pin Low from power-up to delay the start of the FPGA configuration procedure and 
 release the INIT_B pin to High after the SPI flash becomes ready to receive commands.

Since this statement describes about SPI flash, but its explaination is still usefull to other derivatives. It especially expresses why our boot bug could be also happened on BPI NOR flash.

JS28F256J3F105[6] NOR FLASH Reset Specifications

It's power supply sequencing is not required if VPEN is connected to VCC or VCCQ. In this Milkymist One's design, the VPEN is thus connected to VCC and VCCQ. It's thus 3V3 net. But Power supply transitions should only occur when RP# is low. This protects the device from accidental programming or erasure during power transitions. Unfortunately the RC2's design doesn't take this consideration. From Normal RC2 Power On Off Sequence, we can see RP# almost goes high which shows it synchronized to VCCQ! But data sheet says at least 300us for VCC power valid to RP# high level. Check following waveform scoped which indeed violates recommendation.

Asserting RP# during a system reset is important with automated program/erase devices because systems typically expect to read from flash memory when coming out of reset. If a CPU reset occurs without a flash memory reset, proper CPU initialization may not occur. This is because the flash memory may be providing status information, instead of array data as expected. Connect RP# to the same active low reset signal used for CPU initialization. Also, because the device is disabled when RP# is asserted, it ignores its control inputs during power-up/down. Invalid bus conditions are masked, providing a level of memory protection. See Reset Operation Waveforms in JS28F256J3F105.

1, tVCCPH: Min. 300us, VCC Power valid to RP# de-assertion (high)
2, tPLPH: Min. 100ns, RP# pulse width low

Results

  • With Sch. 3:

1. After fast power cycling about 9 or 10 times, got msg log below, with D2 lights well, D3 is OFF.

2. forgot to capture waveform on this, power off then on; reflashing image again 3. After reflash, power-on then press mid-switch, D2 lights but screen shows nothing (in black) anyway 4. power off and wait for about 1 hr(just for lunch) 5. then power-on again, from now on; m1 easily enters unbooted more even just when power on. So tried to get and screen shows, D2 light well, D3 is OFF:

libHPDMC SDRAM initialization runtime
(c) Copyright 2010 Sebastien Bourdeauducq, released under GNU LGPL version 3.
Version 1.0RC1

Initialization sequence completed.
Autocalibration OK, testing memory...
Memory test failed, entering manual mode.

u: inc. DQ delay  // d: dec. DQ delay
t: test (small)   // T: test (large)
c: calibrate IODELAY2s
r: reset IODELAY2s
p: display pattern
b: boot
019

6. then board is always unbooted, so waveforms measured as below:

7. still under checking why?

Reference

  1. Original Milkymist One RC2 schematic
  2. A4806E3R-30N low voltage detector with 20us delay
  3. A4809E3R-263DN low voltage detector with 200ms delay
  4. Reset IC with 20us delay
  5. Xilinx UG380 Spartan-6 FPGA Configuration User Guide
  6. Numonyx JS28F256J3F105

Links

Operating Voltages of Milkymist One's Key Parts

Milkymist One RC2 Collective Waveforms Captured While Power On Off

Spartan-6 - Why is INIT_B low after power-on?

Xilinx UG394 Spartan-6 FPGA Power Management User Guide

Configuring Xilinx FPGAs with SPI Serial Flash

Spartan-6 FPGA Data Sheet: DC and Switching Characteristics

Personal tools
Namespaces
Variants
Actions
Navigation
interactive
Toolbox
Print/export