<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>/tmp/n46software.html</title> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body> <h2>BB Player Power On/Off Sequence</h2> November 2002<br> <br> <br> This document describes the processing flow for handling power on and off. Power is controlled by a combination of the power push button and software controlled logic. When the power push button is first pressed in, power is controlled by the push button. To put the player in a state where power is on independent of the power button, the power control bit in the PI_GPIO register must be set to 1. Until this bit is set, power is controlled by the push button. If the power button is released before the bit is set, then power to the player will be turned off. The circuit is described in <a href="../hw/design_notes/power_reset/bb%20system%20pwr%20up-dwn%20ckt%20no%20ff.doc"> bb system pwr up-dwn ckt no ff.doc</a><br> <br> The power bit in the GPIO register is set to 0 to turn off power. The end user requests power to be turned off by pressing the power push button in. Pressing the button will trigger two events, first the INT2 interrupt will be asserted at the CPU and second 1/2 second later NMI/secure kernel transfer will be asserted at the CPU. However, the secure kernel event is not enabled unless the MI_SEC_MODE_BUT_TRAP_EN bit is enabled in the MI_SEC_MODE register and the INT2 interrupt is not enabled unless the MI_INTR_BUT interrupt is enabled in the MI_INTR_EMASK register . The current instantaneous state of the push button is available in the MI_INTR_BUT bit in the MI_EINTR register. The MI_SEC_MODE register includes a bit indicating whether the secure kernel trap is due to a power off request.<br> <br> This leads to a power on/off sequence as follows:<br> <br> Assumptions:<br> <ul> <li>boot rom code does not handle any power on or off processing</li> <li>we can be up and running in the secure kernel in <= 200ms so that the user isn't holding in the push button for an unusually long time period.<br> </li> <li>whatever code handles power on, must be able to do power off as well so we don't get stuck in a power on state</li> <li>button debouncing handled is software</li> <li>no need for user confirmation of power off </li> </ul> Sequence:<br> <ol> <li>Power button is pushed, CPU boot rom code starts, control transfers to secure kernel</li> <li>Secure kernel sets the power bit in the GPIO register, and waits for the button to be released. Release is detected by polling the MI_INTR_BUT bit. Release is complete when the button is detected in the released state for a continuous polling loop of 100ms.</li> <li>After the release sequence the secure kernel enables the power off signaling mechanism using INT2 and the secure trap signaling mechanism. An interrupt vector must be registered for INT2.</li> <li>The secure kernel handler must determine whether the trap occured while another application was running. If an application is running, then control is transferred to more general secure kernel code which then loads the browser application to complete the rest of the power off processing. If another application is not running, or the browser application should have been running, then the secure kernel will see the INT2 interrupt rather than the secure kernel trap and the GPIO power bit is turned off immediately. This handles the case of no module being present or the browser application failing. </li> <li>If another application is running, then the secure kernel's INT2 interrupt vector should not be invoked. Instead the application-specific INT2 vector will be invoked and be used by the application to shutdown audio and video processing. The secure kernel will be entered using the 1/2second delayed NMI and the secure kernel will detect the button request in the MI_SEC_MODE register. The secure kernel will delegate the power off processing to the browser application so that the secure kernel needn't deal with the complexities of application state saving. If the browser can not be successfully started, power is turned off by the secure kernel.</li> </ol> Observations:<br> <br> <ul> <li>If no module is present at power on, the ERROR LED will remain on while there is power and power will immediately be turned off when the power button is released. The power LED will reflect the current state of the push button.</li> <li>Once power has been turned on in software it can always be turned off in software since there should be enough secure kernel code to present to handle it, and an application can not block the power off NMI. The power LED will reflect the state of the power GPIO bit.<br> </li> </ul> <br> <h2>Module Detect/Removal Sequence</h2> This document describes the sequence for detecting memory module insertion and removal. There are two status bits in the PI_ERROR register that reflect the state of the module. The MD_CUR bit reflects the instantaneous presence of the module and the MD_CHG bit indicates whether there has been a transistion in the module presence (either removal or insertion) since the last time the CHG bit was cleared. The CHG bit will also raise a PI error interrupt. The interrupt can be masked with the MI_EINTR_MASK register. <br> <br> Since there is no hardware-debouncing of the module presence signals, software determining the status of the module must use some caution in using the status bits to determine whether a module is present or to determine when a module state change has completed (i.e., module is completely inserted). To detect whether a module is present, software can test the MD_CHG bit to determine if there has been any status change. If none, then sample the MD_CUR bit to determine if the module is present. Ideally, the MD_CHG bit should be monitored over some small time window to ensure that the module is not in the process of being inserted or removed. One way to do this would be to simply set a timer and wait for some time period, e.g., 100msec. Another would be to record time stamps when the MD_CHG bit changes. To wait for the module to be inserted or removed, the software should also establish a time window of ~100 msec and ensure that both that the MD_CHG bit has not been set and that at the end of this window the MD_CUR bit has the desired value. <br> </body> </html>