WO2016160086A1

WO2016160086A1 - Apparatus and method for controlling the initialization and updating of a device

Info

Publication number: WO2016160086A1
Application number: PCT/US2015/068232
Authority: WO
Inventors: Ashish Patel; Steven RHOADS
Original assignee: Thomson Licensing
Priority date: 2015-03-30
Filing date: 2015-12-31
Publication date: 2016-10-06

Abstract

A method and apparatus for controlling the initialization and updating of a device are described. The apparatus includes a memory that is partitioned into portions and a controller executing the method. The method includes establishing (420) a first operational condition in a device using a first control process stored in a first portion of memory, establishing (430) a second operational condition using a second control process stored in the first portion of memory, the second operational condition including initiating an activity associated with a third operational condition using a third control process, determining (440) if an error has occurred during the initiating, setting (455) an error flag in the first portion if it is determined that an error has occurred, re-establishing (460) operation in the first operational condition in the device, determining (465) if the error flag at the memory location in the first portion of memory is set, and suspending (470) operation of the device while in the first operational condition.

Description

APPARATUS AND METHOD FOR CONTROLLING THE INITIALIZATION AND

UPDATING OF A DEVICE

REFERENCE TO RELATED PROVISIONAL APPLICATION

This application claims priority from United States Provisional Application No. 62/139959, entitled "Apparatus and Method for Controlling the Initialization and Updating of a Device" filed on March 30, 2015, the contents of which are hereby incorporated by reference in its entirety.

TECHNICAL FIELD

The present disclosure generally relates to operations associated with a signal processing device. More particularly, the present disclosure relates to an apparatus and method for controlling the initialization and updating of a device, such as a set top box or gateway.

BACKGROUND This section is intended to introduce the reader to various aspects of art, which may be related to the present embodiments that are described below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. Accordingly, it should be understood that these statements are to be read in this light.

Modern signal processing devices usually include operating code that is stored in a memory. The operating code is used to control the processing functions and operations for the device. Signal processing devices include, but are not limited to, set top boxes, gateways, televisions, and phones.

The memory used for storing the operating code is often partitioned to facilitate initialization or startup as well as normal operation. The memory also often includes two copies of some or all of the operating code. The two copies permit one copy to be updated even while the other copy is being used for operation in the signal processing device.

As signal processing devices have become more complex, the memory space needed for the operating code has increased. Furthermore, the memory space is often divided or apportioned into different sections of memory and may utilize different types of memory for certain storage purposes or conditions within the signal processing device. For instance, one type of memory that is highly reliable for storage over long periods of time may be desirable for storing some or all of the operating code. In some cases, this type of memory is also more expensive and/or more difficult to use than other types of memory. Other portions of code may be maintained in less reliable (and less expensive) types of memory while still other types of memory may be used for transitory storage (e.g. , storing data or media content).

In order to manage cost and design optimization of a signal processing device, efficient use of memory may be put at a premium. Furthermore, as noted above, sometimes portions of the operating code will need to be updated. In some instances, both copies need to be updated at the same time. Maintaining two copies of all of the operating code is not efficient, particularly with any portion of memory that may also be expensive. The expensive portion of the memory may be used to store the critical initialization portion of the operating code. The signal processing devices may update to portions of the operating code through an external download mechanism, but may restrict updates of the critical initialization portion. However, two copies of the operating code, including the critical initialization portion, are still required to be stored and maintained in the memory to permit updates to this portion as well. As a result, the expensive memory code typically stores some duplicate functions of the operating code in order to permit initialization and updating of memory intensive functions such as graphics display screen data.

The requirement to store duplicate copies of operating code creates inherent inefficiencies and cost penalties in signal processing devices. The problem is amplified when storing memory intensive graphics screens or planes that have a use only with respect to error condition and updates to the devices, particularly related to initialization and start-up of the devices. However, the graphics screens or planes as visual notifications are often necessary or desirable to indicate errors based on the point in the initialization or start-up that the errors have occurred. For example, errors occurring at a later initialization point, such as during download of the driver interface, may require the use of graphics screens. Further, storing duplicate portions of theses graphics screens and/or other parts of the operating code in the reliable and expensive portion of the code increases the space or size requirement for this type of memory. The duplication is not efficient and raises cost for the signal processing device. As a result, there is a need for an improved start up, initialization, and update control mechanism that better utilizes the memory in the device.

SUMMARY

According to an embodiment of the present disclosure, a method is described. The method includes establishing a first operational condition in a device, the first operational condition controlled using a first control process stored in a first portion of memory, establishing a second operational condition in the device, the second operational condition controlled using a second control process stored in the first portion of memory, the second operational condition including initiating an activity associated with a third operational condition in the device, the third operational condition using a third control process, determining if an error has occurred during the initiating of the activity associated with the third operational condition, setting an error flag at a memory location in the first portion of memory if it is determined that an error has occurred during the initiating of the activity associated with the third operational condition, re-establishing operation in the first operational condition in the device, determining if the error flag at the memory location in the first portion of memory is set, and suspending operation of the device while in the first operational condition. According to an embodiment of the present disclosure, an apparatus is described. The apparatus includes a memory including a first portion that stores software instructions for a first control process and a second control process, and a controller, coupled to the memory, the controller executing control instructions to establish a first operational condition, the first operational condition controlled using the first control process and establish a second operational condition, the second operational condition controlled using the second control process, the second operational condition including initiating an activity associated with the third operational condition, the third operational condition using a third control process, the controller further determining if an error has occurred during the initiating of the activity associated with the third operational condition, setting an error flag at a memory location in the first portion of memory if it is determined that an error has occurred during the initiating of the activity associated with the third operational condition, and re-establishing operation in the first operational condition in the apparatus, wherein, upon re-establishing operation in the first operational condition in the apparatus, the controller further determining if the error flag at the memory location in the first portion of memory is set and suspending operation of the apparatus while in the first operational condition. The above presents a simplified summary of the subject matter in order to provide a basic understanding of some aspects of subject matter embodiments. This summary is not an extensive overview of the subject matter. It is not intended to identify key/critical elements of the embodiments or to delineate the scope of the subject matter. Its sole purpose is to present some concepts of the subject matter in a simplified form as a prelude to the more detailed description that is presented later.

BRIEF DESCRIPTION OF THE DRAWINGS These, and other aspects, features and advantages of the present disclosure will be described or become apparent from the following detailed description of the preferred embodiments, which is to be read in connection with the accompanying drawings. FIG. 1 is a block diagram of an exemplary communication networking system in accordance with the present disclosure;

FIG. 2 is a block diagram of an exemplary signal receiving system in accordance with the present disclosure; FIG. 3 is a block diagram of an exemplary network device in accordance with the present disclosure; FIG. 4 is a flow chart illustrating a process for controlling initialization with an update in a device in accordance with an embodiment of the present disclosure; and

FIG. 5 is a flow chart illustrating another process for controlling initialization with an update in a device in accordance with an embodiment of the present disclosure.

It should be understood that the drawing(s) are for purposes of illustrating the concepts of the disclosure and is not necessarily the only possible configuration for illustrating the disclosure.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

It should be understood that the elements shown in the figures may be implemented in various forms of hardware, software or combinations thereof. Preferably, these elements are implemented in a combination of hardware and software on one or more appropriately programmed general-purpose devices, which may include a processor, memory and input/output interfaces. Herein, the phrase "coupled" is defined to mean directly connected to or indirectly connected with through one or more intermediate components. Such intermediate components may include both hardware and software based components.

The present description illustrates the principles of the present disclosure. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the disclosure and are included within its scope.

All examples and conditional language recited herein are intended for educational purposes to aid the reader in understanding the principles of the disclosure and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the disclosure, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.

Thus, for example, it will be appreciated by those skilled in the art that the block diagrams presented herein represent conceptual views of illustrative circuitry embodying the principles of the disclosure. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which may be substantially represented in computer readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown. The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, and various types of memory, include read only memory (ROM), random access memory (RAM), and flash memory, along with nonvolatile storage.

Other hardware, conventional and/or custom, may also be included. Similarly, any switches shown in the figures are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selectable by the implementer as more specifically understood from the context.

In the claims hereof, any element expressed as a means for performing a specified function is intended to encompass any way of performing that function including, for example, a) a combination of circuit elements that performs that function or b) software in any form, including, therefore, firmware, microcode or the like, combined with appropriate circuitry for executing that software to perform the function. The disclosure as defined by such claims resides in the fact that the functionalities provided by the various recited means are combined and brought together in the manner which the claims call for. It is thus regarded that any means that can provide those functionalities are equivalent to those shown herein.

The present disclosure addresses problems associated with memory usage for operating code in a device. A portion of a memory is usually partitioned for the initialization or start up of the device. This portion of memory typically uses a reliable type of memory that is also expensive. In some cases, code is included in this portion of the memory based on specific requirements for the architecture of the control software, operating code, and applications used by the device. In order to address shortcomings in the memory partitioning, some portions of the operating code typically associated with initialization may be moved to another partition of memory that used a less expensive type of memory. However, moving these portions of operating code to the less expensive type of memory may also hinder identification and notification of error condition during software updates, such as creating an unrecoverable failure condition in the device.

In order to address these and other issues and to allow for improvement in memory usage, an initialization mechanism that includes handling errors for software updates during download are described. The initialization mechanism described herein reduces or eliminates the need for higher level driver configurations and graphics based on screen display images as part of the initialization code. When an update to some portion of the software in the device is needed, the mechanism includes establishing a first operational condition, such as a bootloader, in the device. A second operational condition, such as an operating system kernel, is established in the device after the first operational condition is established and/or completed. The software for the first operational condition and the second operational condition is stored in a first type of memory that is highly reliable but also more expensive, such as negative "or" gate (NOR) flash memory. During the second operational condition, based on the indication or determination that a software update for a third operational condition is available for download and use, the software is transferred from a temporary memory location to a second type of memory that is less expensive, such as negative "and" gate (NAND) flash memory. The third operational condition may include applications, driver interface code for various circuits in the device, and user interface data, such as graphics display screens. Further, due to operational restrictions, only the second operational condition (e.g., the operating system kernel) may be able to communicate with the second type of memory.

During software download for the third operational condition or during another initialization activity for the third operational condition, if an error occurs, an error flag is set at a memory location in the first type of memory. The error may include an invalid checksum, and invalid range for value, or any other error that is commonly associated with downloading software to a memory or initializing use of the software in the memory. In some cases, the error may be associated with an initial operational check through a system self-diagnostics process. Once the error flag is set, a reset mechanism for the device, often referred to as a soft reset or device initiated reset, is initiated and the device returns to the first operational condition (e.g., bootloader). At this point the error flag that is located in the first type of memory is checked while the device is operating in the first operational condition. If the error flag is set, the device provides a visual indication that an error has occurred and the first operational condition is suspended or terminated. Further, the error flag is also reset. In order to reset or re-initialize the device, a hard reset or restart of the device by a user is required, such as pressing a reset button or power cycling the device. In one embodiment, the error flag is checked on every re-initialization or restart of the device (e.g., reset button press or power-on of the device). In this embodiment, the resetting of the error flag when the first operational condition is suspended allows the device to move from the first operational condition to the second operational conditional and to the downloading of software. In other embodiments, the setting and resetting of the error flag may be controlled only by the second operational condition.

In one embodiment, the determination that a software update is available may be established at power up or initialization of the device based on a setting in memory or a particular condition or configuration for the device. In other embodiments, the determination that a software update is available is made while operating in the second operational condition. If no error occurs during download, the third operational condition that has completed being downloaded is established and used in the device. In one embodiment, the third operational condition is a normal operating condition. Other embodiments may further establish an additional operational condition as the normal operating condition.

In this manner, the embodiments described herein allow an error indication or notification to be provided to a user utilizing the lowest or simplest operational condition in the control software for the device, such as the bootloader software. The embodiments eliminate the need to include and maintain higher level driver control software and any accompanying error indication information, such as graphics screens for display, associated with the higher level device specific driver control software in the portion of the memory typically using a higher performance, more expensive type of memory. As a result, the error indication or notification to the user that an error has occurred while downloading software updates to the device is performed without using device specific driver interface code.

While the present embodiments are described primarily in relation to operation of a set top box, one skilled in art would be able to recognize that aspects of the present embodiments may be applicable to other devices that include operating systems and applications for using the device that further include a plurality of memory types that may be managed for efficient utilization and that may be capable of receiving and using software updates, either in a factory setting or in the field while being used. Exemplary devices include, but are not limited to, televisions, cellular phones, smartphones, computers, game consoles, and appliances. In the embodiments described herein, certain elements shown in the figures are well known and will not be described in further detail. It should also be noted that the present embodiments may be implemented using conventional programming techniques, which, as such, will not be described herein.

Turning now to the drawings and referring initially to FIG. 1 , a block diagram of an embodiment of a system 100 for providing home entertainment media content in a home, or end user, network according to principles of the present disclosure is shown. The media content, originating from a content provider, is provided through an external network to a Multimedia over Cable Alliance (MoCA) interface 105. The media content may be provided using any one of the standard transmission protocols and standards for content delivery (e.g., Advanced Television Systems Committee (ATSC) A/53, digital video broadcast (DVB)-Cable (DVB-C), DVB-Satellite (DVB-S), or DVB-Terrestrial (DVB-T)). The MoCA interface 105 is connected to external network receiving device 1 10, external network receiving device 1 15, and a MoCA network device 120. Both external network receiving devices 1 10 and 1 15 also connect to local network interface 130. Local network interface 130 connects to local network device 135. Local network device 135 connects to a first display device 140. A media content playback device 150 connects to MoCA network device 120. MoCA network device 120 connects to a second display device 155. The components shown in system 100 comprise a home network configured to provide media content to multiple locations within the home using one or both home communication networks, namely a MoCA network and a local network. It is important to note that other possible home network configurations are possible, including a configuration using only a single network (e.g., either a MoCA network or a local network).

A signal containing media content (e.g., audio, video, and/or data) from the external network is provided over a physical media, such as co-axial cable. The external network interfaces to MoCA interface 105. MoCA interface 105 provides a routing mechanism for the signal from the external network to devices in the home or user network (e.g., external network receiving device 1 10 and/or external network receiving device 1 15) in conjunction with signals that operate in the MoCA network with the home or user network. MoCa interface 105 may include active or passive circuit elements that may split or separate the input signal into different or similar output signals and to split or separate signals associated with the external network from signals associated with the MoCA network. MoCa interface 105 may also use amplifiers, frequency filters, and electromagnetic circuits to split or separate the signal. In one embodiment, the external network provides a signal on a co-axial cable between the frequency range of 20 Megahertz (MHz) and 800 MHz. The MoCA network operates using signals in the frequency range from 950 MHz to 1 ,250 MHz. In an alternative embodiment, the external network provides a signal between the frequency range of 950 MHz and 2, 150 MHz with the MoCA network operating in the frequency range of 425 MHz to 625 MHz. MoCA interface 105 provides a signal splitting for signals from the external network and a separate signal splitting for signals on the MoCA network while preventing signals from the MoCA network from being output to the external network.

The external network receiving device 1 10 and external network receiving device 1 15 may each operate and function in a similar manner. The external network receiving devices 1 10 and 1 15 communicate with signals to and from the external network through the MoCA interface 105. The external network receiving devices 1 10 and 1 15 may receive different types of media content (e.g., different channels) from either the external network or from other devices in the home network through either MoCA interface 105 or local network interface 130. The external network receiving devices 1 10 and 1 15 tune, demodulate, decode, and process the received content. The external network receiving devices 1 10 and 1 15 also provide the processed content for display and use by a user in the home. External network receiving devices 1 10 and 1 15 may further provide a separation of the media content based on instructions provided with the content or over the external network. External network receiving devices 120 and 130 may also process and separate media content based on instructions received via user commands. The external network receiving devices 1 10 and 1 15 may also provide storage, such as a hard drive or optical disk drive, for recording and/or storing the media content as well as providing the content for playback to other devices in a home network (e.g., MoCA network device 120 and/or local network device 135). The external network receiving devices 1 10 and 1 15 may be one of a settop box, home media server, computer media station, home network gateway, multimedia player, modem, router, home network appliance, or the like.

The external network receiving devices 1 10 and 1 15 provide interfaces for communicating signals on the MoCA network through MoCA interface 105 to and from other MoCA network devices (e.g., the external network receiving devices 1 10 and 1 15 and MoCA network device 120). The external network receiving devices 1 10 and 1 15 also provide interfaces to a local home network through local network interface 130 to local network device 135. In one embodiment, the local network is an Ethernet network. In other embodiments, the local network may be a wireless network. Wireless communication using a wireless network may include physical interfaces to accommodate one or more wireless formats including Wi-Fi, Institute of Electrical and Electronics Engineers (IEEE) standard 802.1 1 or other similar wireless communications protocols.

MoCA interface 105 communicates MoCA network signals between the external network receiving devices 1 10 and 1 15 and MoCA network device 120. MoCA network 120 device tunes, demodulates, and decodes MoCA signals for display and use by a user. MoCA network device 120 may also transmit or communicate signals on the MoCA network for delivery to other devices (e.g., the external network receiving devices 1 10 and 1 15). These signals may provide control or identification information for media content to be delivered to the MoCA network device 120. The MoCA network device 120 is often referred to as a thin client MoCA device and may be, but is not limited to, a settop box, setback box, computer device, tablet, display device, television, wireless phone, personal digital assistant (PDA), gaming platform, remote control, multi-media player, or home networking appliance that includes a MoCA interface. MoCA network device 120 may also include a storage device, such as a hard drive or optical disk drive, for recording and playing back audio and video content.

Local network interface 130 provides the routing and signal communication and management functions between devices communicating across the local network. In one embodiment, local network interface 130 operates as a signal router for communicating using internet protocol routing protocols as part of an Ethernet network. In other embodiments, local network interface operates as a wireless signal router. In yet other embodiments, the function of local network interface 130 is included as part of one or both of the external network receiving devices.

Local network interface 130 provides local network signals between external network receiving device 1 10, external network receiving device 1 15, and local network device 135. Local network device 135 also may tune, demodulate, and/or decode the local network signals for use by a user depending on the communication protocol used. Local network device 135 may also transmit or communicate signals on the local network for delivery to other devices (e.g., the external network receiving devices 1 10 and 1 15). These signals may provide control or identification information for media content to be delivered to the local network device 135. The local network device 135 may also provide media content (audio and video content) that is received over the local network to the display device 140. The local network device 135 is often referred to a thin client device and may be, but is not limited to, a computer device, tablet, display device, television, wireless phone, personal digital assistant (PDA), gaming platform, remote control, multi-media player, or home networking appliance that includes a local network interface. Local network device 135 may further include a storage media for digital media recording.

Media content playback device 150 provides local source playback for one or more formats of media content from an internal or separate media element. Media content playback device may include a compact disc (CD) drive, DVD drive, Blu-Ray drive, a hard disk drive, an electronic memory, or other storage or storage access element. Media content playback device 150 reads the media content from the media element and outputs the media content in one or more audio/video signal formats (e.g., HDMI). The audio/video signals are provided to MoCA network device 120.

The display devices 140 and 155 receive and display audio/video signals from the local network device 135 and MoCA network device 120 respectively. The audio/video signals for display device 155 may either be from media content playback device 150 or from the external network receiving devices 1 10 and 1 15 through MoCA network device 120 and MoCA interface 105. The audio/video signals for display device 140 may be from the external network receiving devices 1 10 and 1 15 through local network device 135 and local interface 130. Either one of both of display devices 140 and 155 may be a conventional two-dimensional (2-D) type display or may alternatively be an advanced three-dimensional (3-D) type display. Either one or both of display devices 140 and 155 may include a plurality of interface options for interfacing to the MoCA network device and local network device. These interfaces include, but are not limited to, universal serial bus (USB), HDMI, and mobile high definition link (MHL).

It is important to note that one or more of external network receiving devices 1 10 and 1 15, MoCA network device 120 and local network device 135 may include display capability. Further, external network receiving devices 1 10 and 1 15 and local network device 135 may include interfaces for connecting a media content playback device, such as media content playback device 150. It should be appreciated that other devices having display or display output capabilities including, but not limited to, computer devices, tablets, gateways, display devices, televisions, wireless phones, PDAs, computers, gaming platforms, remote controls, multi-media players, home networking appliances or the like, may employ the teachings of the present disclosure and are considered within the scope of the present disclosure.

In operation, the system provides the networking and communication capability for connecting and sharing media content between devices in a user's home using either the MoCA network, or the local network, or both networks. In one embodiment, media content for a particular program is tuned by external network receiving device and provided to MoCA network device through MoCA interface 1 10 for viewing on display device. MoCA network device may operate using a frequency range described as high MoCA. As the other devices, such as external device receiving device and, share the network, other signals, such as single wire multiswitch (SWM) communication, Integrated Services Digital Broadcasting-Terrestrial (ISDB-T), and L- band satellite signals, may be present and must operate unimpaired by the operation of MoCA network device. In some embodiments, electrical power for either local network device or MoCA network, or both, may be provided through a second device, such as a display device, instead of being provided directly through a connection to a main electrical power source (e.g., main house AC power). It should be appreciated by one skilled in the art that system 100 in FIG. 1 is described primarily as operating with a local MoCA network and a second local network, such as an Ethernet network. However, other network standards that incorporate either a wired or wireless physical interface may be used. For example, the second local network may be a wireless network using WiFi, Bluetooth, or the institute of electrical and electronics engineers (IEEE) standard 802.1 1 . Other wired networks, such as phone line or power line networks, may be used in place of the MoCA network. Further, systems using only one network (e.g., only a wireless network) or more than two networks may be used either alternatively or simultaneously together.

Turning now to FIG. 2, an exemplary embodiment of a system 200 for receiving signals using aspects of the present disclosure is shown. System 200 primarily receives signals from one or more satellites as well as multiple television broadcast transmission sites. The signals are provided by one or more service providers and represent broadcast audio and video programs and content. System 200 is described as including components that reside both inside and outside a user's premises. It is important to note that one or more components in system 200 may be moved from inside to outside the premises. Further, one or more components may be integrated with a display device, such as a television or display monitor (not shown). In either case, several components and interconnections necessary for complete operation of system 200 are not shown in the interest of conciseness, as the components not shown are well known to those skilled in the art.

An outdoor unit (ODU) 201 receives signals from satellites and from terrestrial transmission towers through an over the air and/or near earth orbit communications link. ODU 201 is connected to set top box 202. Within set top box 202, the input is connected to filter 203. Filter 203 connects to three signal processing paths. A first path includes tuner 205, link circuit 206, and transport decoder 208 connected together serially. A second path includes tuner 210, link circuit 212, and transport decoder 214 connected together serially. A third path includes MoCA circuit 234 which further connects to controller 216. The outputs of transport decoder 208 and transport decoder 214 each connect to controller 216. Controller 216 connects to security interface 218, external communication interface 220, user panel 222, remote control receiver 224, audio/video output 226, power supply 228, memory 230, and ODU control 232. External communication interface 220, remote control receiver 224, audio/video output 226, and power supply 228 provide external interfaces for the set top box 202. ODU control 232 also connects to the filter 203.

Satellite signal streams, each containing a plurality of channels, are received by ODU 201 . ODU 201 includes a dish for capturing and focusing the propagated radio wave from the atmosphere onto one or more antennas contained within a structure known as a low noise block converter (LNB). ODU 201 may be configured to receive the signal streams from satellite transponders located on one or more satellites. In a preferred embodiment, two sets of sixteen channels are received by ODU 201 , and converted, using one or more LNBs to a frequency range of 950 Megahertz (MHz) to 2, 150 MHz, referred to as L-band. ODU 201 also includes a terrestrial antenna for receiving over the air broadcasts. In a preferred embodiment, ODU 201 includes a multiple element antenna array for receiving ISDBT signals in the frequency range from 170 MHz to 800 MHz.

ODU 201 provides a converted signal stream to the set top box 202 through radio frequency (RF) co-axial cable. The converted signal stream is provided to filter 203. In a preferred embodiment, filter 203 operates as a multiplex filter with up to three separate filter sections or interfaces. The frequency response properties of filter 203 may include a separate highpass filter and lowpass filter such that the frequency passbands of each do not overlap. The arrangement, often referred to as a diplexer or diplex filter, allows for a separation, through signal filtering, of the incoming satellite signal and/or MoCA signal from the terrestrial signal and/or MoCA signal. In a preferred embodiment, the low pass filter frequency response pass band ends at a frequency below 900 MHz. The low pass filter portion allows a MoCA signal in a frequency range from 475 MHz to 625 MHz as well as a terrestrial signal in the frequency range from 170 MHz to 800 MHz to pass through to subsequent blocks while attenuating, or not passing through, a satellite signal in a frequency range from 950 MHz to 2,150 MHz. The high pass filter portion operates in an opposite manner passing the MoCA signal, in the frequency range around 1 100 MHz, along with the satellite signal through and attenuating cable or terrestrial broadcast signal. The high pass filter portion may also filter any electrical supply or communication signals provided to the ODU 201 . An additional bandpass filter circuit may be provided to further process MoCA signals and provide the signals as an output to a home MoCA network or for processing in set top box 202. Other embodiments may be possible and some of these embodiments are described in further detail below. Filter 203 may also include surge or transient voltage protection devices.

The output signal from the high pass filter portion of filter 203 is provided to a first signal path containing a tuner 205, a link circuit 206, and a transport decoder 208 connected in a serial fashion. The output signal from the low pass filter portion of the filter 203 is provided to a second signal path. The second signal path also contains a tuner 210, a link circuit 212, and a transport decoder 214 connected in a serial fashion. Each processing path may perform similar processing on the filtered signal streams, the processing being specific to the transmission protocol used. Tuner 205 processes the split signal stream by selecting or tuning one of the channels provided from a satellite service provider in the highpass filtered signal stream to produce one or more baseband signals. Tuner 205 contains circuits (e.g., amplifiers, filters, mixers, and oscillators) for amplifying, filtering and frequency converting the satellite signal stream. Tuner 205 typically is controlled or adjusted by link circuit 206. Alternately, tuner 205 may be controlled by another controller, such as controller 216, which will be described later. The control commands include commands for changing the frequency of an oscillator used with a mixer in tuner 205 to perform the frequency conversion. Tuner 210 processes the lowpass filtered signal stream by selecting or tuning one of the terrestrial or cable broadcast channels in the split signal stream to produce one or more baseband signals. Tuner 210 contains circuits (e.g., amplifiers, filters, mixers, and oscillators) for amplifying, filtering and frequency converting the signal stream. Tuner 210 may controlled or adjusted in a manner similar to that described earlier for tuner 205.

Typically the baseband signals at the output of tuner 205 or tuner 210 may collectively be referred to as the desired received signal and represent one satellite channel selected out of a group of channels that were received as the input signal stream. Although the signal is described as a baseband signal, this signal may actually be positioned at a frequency that is only near to baseband. The one or more baseband signals from the satellite service provider are provided to link circuit 206 through tuner 205. Link circuit 206 typically contains the processing circuits needed to convert the one or more baseband signals into a digital signal for demodulation by the remaining circuitry of link circuit 206. In one embodiment the digital signal may represent a digital version of the one or more baseband signals. In another embodiment the digital signal may represent the vector form of the one or more baseband signals. Link circuit 206 also demodulates and performs error correction on the digital signal from the satellite service provider to produce a transport signal. The transport signal may represent a data stream for one program, often referred to as a single program transport streams (SPTS), or it may represent multiple program streams multiplexed together, referred to as a multiple program transport stream (MPTS).

The one or more baseband signals from the broadcast service provider are provided to link circuit 212 through tuner 210. Link circuit 212 typically contains the processing circuits needed to convert the one or more baseband signals into a digital signal for demodulation by the remaining circuitry of link circuit 212 in a manner similar to link circuit 106 described earlier. Link circuit 212 also demodulates, performs broadcast channel equalization and error correction on the digital signal from the broadcast service provider to produce a transport signal. As described earlier, the transport signal may represent a data stream for one program or it may represent multiple program streams multiplexed together.

The transport signal from link circuit 206 is provided to transport decoder 208. Transport decoder 208 typically separates the transport signal, which is provided as either a SPTS or MPTS, into individual program streams and control signals. Transport decoder 208 also decodes the program streams, and creates audio and video signals from these decoded program streams. In one embodiment, transport decoder 208 is directed by user inputs or through a controller such as controller 216 to decode only the one program stream that has been selected by a user and create only one audio and video signal corresponding to this one decoded program stream. In another embodiment, transport decoder 208 may be directed to decode all of the available program streams and then create one more audio and video signals depending on user request.

The transport signal from link circuit 212 is similarly provided to transport decoder 214. Transport decoder 214 decodes the program streams, and creates audio and video signals from these decoded program streams as directed by user inputs or a controller in a manner similar to that described earlier for transport decoder 208.

The audio and video signals, along with any necessary control signals, from both transport decoder 208 and transport decoder 214 are provided to controller 216. Controller 216 manages the routing and interfacing of the audio, video, and control signals and, further, controls various functions within set top box 202. For example, the audio and video signals from transport decoder 208 may be routed through controller 216 to an audio/video (A/V) output 226. A/V output 226 supplies the audio and video signals from set top box 202 for use by external devices (e.g., televisions, display monitors, and computers). Also, the audio and video signals from transport decoder 214 may be routed through controller 216 to memory block 230 for recording and storage.

Memory block 230 may contain several forms of memory including one or more large capacity integrated electronic memories including, but not limited to RAM, ROM, and flash, or hard storage media, such as a hard disk drive or an interchangeable optical disk storage system (e.g., compact disk drive or digital video disk drive). Memory block 230 may include a memory section for storage of instructions and data used by controller 216 as well as a memory section for audio and video signal storage. Controller 216 may also allow storage of signals in memory block 230 in an alternate form (e.g., an MPTS or SPTS from transport decoder 208 or transport decoder 214).

In one embodiment, memory block 230 may be partitioned for use during different operational conditions in the device and may include three types of electronic memory devices or circuits. The first type of memory device, a flash memory based on NOR gate technology, may be used to store a core set of instructions for initialization or start up, referred to as a first operational condition, in set top box 202. The memory space for the NOR memory is small (e.g. , 8 Megabytes (MB)) and includes code for a bootloader usually located in a space in the memory that is protected, or not writeable. The NOR memory may also include a control code or operating system kernel (e.g., Linux) and some additional device and driver software along with interface code, referred to as a second operational condition for the device. The device and driver software and interface code included as part of the NOR memory may be limited, and may include only specific code needed to be able to initiate the set top box 202. It is important to note that some device and driver software may also include graphics screen information or data for generating a display on a display device. The graphics screen information may often be referred to as splash screens and some of the splash screens may be used to indicate a software update or configuration status for the device as well as to show the presence of updates errors or an update success. It is important to note that the device and driver interface software and associated splash screens may use or occupy as much as 2 MB of memory, particularly when two copies must be stored and maintained in memory.

An additional portion of the operating code, referred to as a third operational condition for the device, may be stored in a flash memory based on NAND gate technology. The additional portion may include additional device and driver code and applications as well as the root file system, user interface instructions and any other information specific to the device. The NAND memory is typically larger than the NOR memory (e.g., 128 MB) and is also less expensive as well as less reliable than the NOR memory. The operating code that includes device specific software and instructions is often referred to as device interface code or middleware. In some embodiments a smaller portion including only a subset of the specific software and instructions, referred to as a mini driver interface code, may be segmented off and included in NOR memory.

During update, the newly received code is temporarily stored (e.g., after being received or downloaded) using a double data rate (DDR) DRAM. The DDR DRAM section may be larger than the NOR or NAND memory sections (e.g., 4 gigabytes (GB)) and may also be used for storing other information and data related to the operation of the device. As discussed earlier, a signal processing device (e.g. , set top box 202) usually stores and maintains two copies of the operating code. The storage and use of two copies allow one copy to be running while the other copy is being updated if an update is needed.

The present disclosure manages the memory use in a memory, such as memory block 230, and in particular the memory use or efficiency across different types of memory as described by permitting a storage configuration that eliminates the inclusion of a portion of driver interface code or the mini driver interface code as part of the NOR memory. In particular, driver interface code that requires use of or inclusion of graphics display information is included in the code that is stored in the NAND memory. To take advantage of moving the device driver interface software code to the NAND memory, a different mechanism for addressing errors that may occur during the downloading of a software update that includes the device driver interface code is required. Details regarding the implementation of the operating code to allow for a reduction in size and optimization of memory and will be further described below.

Controller 216 is also connected to an external communications interface 220. External communication interface 220 may provide signals for establishing billing and use of the service provider content. External communications interface 220 may include a phone modem for providing phone connection to a service provider. External communications interface 220 may also include an interface for connection to an Ethernet network and/or to home wireless communications network. The Ethernet network and/or home wireless network may be used for communication data, audio, and/or video signals and content to and from other devices connected to the Ethernet network and/or home wireless network (e.g., other media devices in a home).

Controller 216 also connects to a security interface 218 for communicating signals that manage and authorize use of the audio/video signals and for preventing unauthorized use. Security interface 218 may include a removable security device, such as a smart card. User control is accomplished through user panel 222, for providing a direct input of user commands to control the set top box and remote control receiver 224, for receiving commands from an external remote control device. Although not shown, controller 216 may also connect to the tuners 205, 210, link circuits 206, 212, and transport decoders 208, 214 to provide initialization and set-up information in addition to passing control information between the blocks. Finally, power supply 228 typically connects to all of the blocks in set top box 202 and supplies the power to those blocks as well as providing power to any of the elements needing power externally, such as the ODU 201 .

Controller 216 also controls ODU control 232. ODU control 232 provides signaling and power supply electrical power back to the ODU 201 through filter 203. ODU control 232 provides these signals and power onto the co-axial cable(s) running between ODU 201 and set top box 202. In one embodiment, the ODU control 232 receives input control signals from controller 216 and provides different DC voltage levels to specific portions of the ODU 201 to provide a certain signal stream containing a set of programs or content to filter 203 and further to tuner 205 and tuner 210. In another embodiment, the ODU control 232 receives inputs from controller 216 and also from link circuit 206 and link circuit 212 and provides DC voltage levels and a separate tuning control signal to ODU 201 using low frequency carrier based frequency shift keying modulation. Controller 216 also may send control commands to disable ODU control 232 from providing either direct current (DC) voltages or control signals to ODU 201 .

MoCA circuit 234 amplifies and provides processing associated with one or both of reception and transmission of the MoCA signals. As described above the MoCA network permits communications of audio and video signals in a home network and may operate bi-directionally. MoCA circuit 234 includes a low noise amplifier for improving reception performance of a MoCA signal received by set top box 202 from another network connected device (e.g., MoCA network device 120 described in FIG. 1 ). The received and amplified signal is tuned, demodulated, and decoded. The decoded signal may be provided to a number of other circuits, including audio and video outputs as well as a mass storage device (e.g., hard disk drive, optical drive, and the like), not shown. Additionally, MoCA circuit 234 generates and formats a MoCA transmit signal using audio and video content available or stored set top box 202, including content received from the input (e.g., satellite signal) and content from a mass storage device in memory block 230. MoCA circuit 234 also includes a power amplifier for controlling the transmitted signal level of the MoCA signal sent by set top box 202 to another network connected device (e.g., MoCA network device 120 described in FIG. 1 ). Adjustment of the receive signal amplification as well as the transmit signal amplification in MoCA circuit 234 may be controlled by controller 216.

In operation, set top box 202, when powered on initially, or if completely reset, begins start up or initialization. The start up is controlled by bootloader software as part of a first operational condition located in a first portion of memory unit 230, such as the NOR memory described above. The bootloader, among other functions, may include a check for software code or image availability as part of an update to the software in the device. The check may involve checking a location in the memory for an indicator or flag. The check may also involve checking for the presence of an external memory device (e.g., a memory connected through an external interface) or may involve accessing a website. The use of an external memory device is preferred if concerns exist that the memory and/or currently used operational code cannot be confirmed as valid.

If an image is not found or available, the bootloader progresses through a start-up process using the control code and software found in the present portion (e.g., NOR) and a second portion of memory unit 230, such as the NAND memory described above. In one embodiment, device start-up includes running and establishing an operating system (e.g., a linux kernel) as part of a second operational condition, and running and establishing a device driver interface, or common device interface as well as application layer and user interface and control software as part of a third operational condition.

If an updated image is available, the image may first be downloaded (e.g., from an external device or website), into a third portion of memory unit 230, such as DDR DRAM memory described above. The bootloader performs an integrity of the image and may either create, or set, a boot check flag.

Further, once the integrity of the image is complete, the bootloader transfers a kernel image or operating system portion (e.g., Linux kernel), if available, from the downloaded software image in the third portion of the memory into the first portion of memory (e.g., NOR memory). The bootloader then transfers the control to the kernel. The kernel is able to execute the transfer between the third portion (e.g., RAM) and the second portion (e.g., NAND) for the remaining portion of the image (e.g., the device driver interface and any other operating code). If an error occurs during this transfer, then an error condition (e.g., a flag) is provided to the memory location described earlier as part of the boot check.

A soft reset is initiated by the controller 1 16, which returns or transfers control to the bootloader portion of the code or control instructions. The soft reset may involve electronically resetting the controller 1 16 and memory unit 230 and typically does not include powering off all or any of the elements in the device (e.g., set top box 202). As a result of the reset, the bootloader begins an initialization again. The boot check indicator is checked. Since an error had previously occurred during update, the boot check includes going through or evaluating error flags or settings, including errors associated with downloading or in establishing operation of any of the operating code (e.g., the device driver interface or middleware). The boot loader may also implement some indication that an error has occurred and provide the indication (e.g., through a visual display or user interface control) to a user. Further operation of the device is suspended until the user either turns off and back on power to the device or performs a full device reset (e.g., through a reset button provided through user panel 222. The indication of the error associated with the update is cleared from the boot check portion of the memory so that, following the hard reset or power off/on cycling, the device may return to a normal operation and/or download the image and attempt update again.

It should be appreciated by one skilled in the art that the blocks described inside set top box 202 have important interrelations, and some blocks may be combined and/or rearranged and still provide the same basic overall functionality. For example, transport decoder 208 and transport decoder 214 may be combined and further integrated along with some or all of the functions of controller 216 into a System on a Chip (SoC) that operates as the main controller for set top box 202. Further, control of various functions may be distributed or allocated based on specific design applications and requirements. As an example, link circuit 206 may provide control signals to ODU control 232 and no connection may exist between link circuit 212 and ODU control 232. Further, it should be appreciated although ODU 201 includes both a dish and

LNB for use with satellite signals and a terrestrial antenna, other embodiments may use separate structures. In some embodiments, the satellite dish and LNB and included in one structure and the terrestrial antenna is part of a second structure. The outputs of both satellite dish/LNB structure and terrestrial antenna are combined using a signal combining circuit and provided to set top box 202.

Although set top box 202 is described above as receiving a single converted signal stream, set top box 202 may also be configured to receive two or more separate converted signal streams supplied by ODU 201 in some modes of operation. Operation in these modes may include additional components including switches and/or further tuning and signal receiving components, not shown. Further, set top box 202 may be designed to operate only on a home network using the Ethernet or home wireless network interfaces described above. In this case, the elements associated with operation in a MoCA network may be removed from set top box 202.

Some of the elements described in system 200 may be used in a home or user network and operate in a manner similar to elements described in FIG. 1 . For example, ODU 201 may provide external signals to the home or user network as described in FIG. 1 . Further, set top box 202 may operate as a gateway or media server device for the home or user network and may operate in a manner similar to either external network receiving device 1 10 or external network receiving device 1 15. Filter 203 in set top box 202 may operate in a manner similar to MoCA network interface 105.

Turning now to FIG. 3, a block diagram of an exemplary network device 300 using aspects of the present disclosure is shown. Network device 300 operates in a manner similar to MoCA network device 120 described in FIG. 1 . Network device 300 primarily operates on a home or user network. It is important to note that one or more components may be integrated with a display device, such as a television or display monitor (not shown). In either case, several components and interconnections necessary for complete operation of network device 300 are not shown in the interest of conciseness, as the components not shown are well known to those skilled in the art.

A signal from an internal or home network (e.g., MoCA network), is interfaced to network device 300 at filter 303. Filter 303 connects to MoCA front end 333. MoCA front end connects to MoCA circuit 334. MoCA circuit 334 further connects to controller 316. Controller 316 connects to security interface 318, external communication interface 320, user panel 322, remote control receiver 224, audio/video interface 326, power supply 328, and memory 330. External communication interface 320, remote control receiver 324, audio/video output 326, and power supply 328 provide external interfaces for the set top box 302. Except as described below, the elements in network device 300 operate and function in a manner similar to those similarly numbered elements described for set-top 202 described in FIG. 2 and will not be described further here.

The MoCA home network signal, containing audio, video, and/or data program content is received through a cable (e.g., a coaxial cable) from a central distribution unit (e.g., set-top box 202 described in FIG. 2 or external network receiving devices 1 10 or 1 15 described in FIG. 1 ) is passed through filter 303. Filter 303 passes the MoCA signal through while attenuating other signals present on the cable. Filter 303 also filters any undesired signals transmitted from MoCA front end 333. In one embodiment, filter 303 includes a first diplexing portion that highpass filters the MoCA signal while filtering out the other signals in a frequency range below the MoCA signal. The first diplexing portion also simultaneously provides a proper terminating impedance on the network in the frequency range for the signals in the frequency range below the MoCA signal. Filter 303 also includes a second diplexing portion that lowpass filters the MoCA signal while filtering out the other signals in a frequency range above the MoCA signal. The second diplexing portion also simultaneously provides a proper terminating impedance on the network in the frequency range for the signals in the frequency range above the MoCA signal. MoCA front end 333 includes tuners and amplifiers used for receiving the MoCA signal as well as transmitting a MoCA signal from network device 300 to the home network. The tuned input signal from RF front end 333 is provided to MoCA transceiver 334. MoCA transceiver 3334 demodulates the tuned input signal and provides audio, video, and/or data program content signals to controller 316.

Controller 316 converts the signal received from the MoCA network through MoCA transceiver 334, in a serial Ethernet or reduced gigabit media independent interface format, and may provide the converted signal to other elements in network device 300. Similarly, controller 316 may receive and convert inputs from one or more of the elements in network device 300 and provide the signal to MoCA transceiver 334 for transmission to other devices on the MoCA home network.

As described earlier in FIG. 2, the memory block 330 may be partitioned for use during different operational conditions in the device and may include several types of electronic memory devices or circuits. In one embodiment, memory block 330 may include three different types of memory. The first type is NOR flash memory used to store a core set of instructions for initialization or start up encompassing a first operating condition for network device 300, such as a bootloader, and a second operation condition, such as a kernel operating system. The second type is NAND flash memory used to additional device specific software instructions and applications used in a third operating condition, such as a normal operating condition for network device 300. The third type is DDR DRAM used for storing other information and data related to the operation of the device and for storing updated software code for the NOR and NAND memories that has been downloaded. As discussed in FIG. 2, the NOR memory is smaller than the NAND memory which is smaller than the DDR DRAM. Two copies of the operating code are still maintained.

Also, as described earlier in FIG. 2, managing memory use in network client or thin client devices, such as network client device 300 is important. Additionally, network client or thin client devices are typically simpler and lower cost than set top boxes (e.g., set top 202 described in FIG. 2 or external network receiving devices 1 10 and 1 15 described in FIG. 1 ). Therefore it is even more important to efficiently manage memory usage in a device such as network device 300.

As in set top box 200 described in FIG. 2, network device implements an initialization and updating mechanism that permit a software code storage configuration that eliminates the inclusion of a portion of driver interface code or the mini driver interface code as part of the NOR memory. When network device 300 powered on initially, or if completely reset, a first software control condition or process begins. The first software control condition or process may be referred to as a bootloader. If a software update is available, the first software process may initiate a download of the software update into DDR DRAM. If no update is found, the first software process initiates and transfers control to a second software control condition or process. The second software control condition or process may be referred to as an operating system kernel. The second software control condition or process initiates a third software control condition or process that includes device specific driver control software, graphics images and other information for applications, and user interface instructions. The first and second control conditions or processes are stored in NOR memory whiles the third control condition or process is stored in NAND memory. If an updated image is available, then after the new software has been downloaded into DDR DRAM and an integrity check is complete, a transfer of the portion of the software image associated with the third control condition or process is initiated by the second control condition or process. If an error occurs during this transfer, then an error condition (e.g., a flag) is provided the memory location accessible by the first control condition or process (e.g., NOR memory).

Control of the initialization and update is returned to the first control condition or process, which initiates a soft reset of network device 300. As a result of the soft reset, the bootloader begins an initialization again. The boot check memory location is checked. Since an error had previously occurred during update, the boot check location now includes an indication of the error and the bootloader implements code to provide some error indication to a user. Further operation of network device 300 is suspended until the user either turns off and back on the power to the device or performs a full device hard reset (e.g., through a reset button provided through user panel 322. The indication of the error associated with the update is cleared from the boot check portion of the memory so that, following the hard reset or power off/on cycling, network device 300 may return to a normal operation and/or download the image and attempt update again.

Turning to FIG. 4, a flow chart of an exemplary process 400 for initializing and updating a device is shown. Process 400 may be used in conjunction with network device 300 described in FIG. 3. Process 400 may be also used in conjunction with a set top box device, such as set top box 202 described above. Process 400 may equally apply to one or more of the devices described in FIG. 1 (e.g., external network receiving devices 1 10 and 1 15, MoCA network device 120, and/or local network device 135). The process further may be used in other devices including, but not limited to, gateways, modems, and televisions. Process 500 is described with respect to an embodiment using an arrangement for a memory unit (e.g., memory block 330 described in FIG. 3) in conjunction with a controller or processor device (e.g., controller 316). The embodiment uses a first type of memory that stores software code in conjunction with a first and second operating condition in a device. The also uses a second type of memory that stores software code in conjunction with a third operating condition and a third type of memory that is used for downloading software updates, particularly updates to the software code for the third operating condition. Other embodiments using different arrangements or memory types may also benefit from the initialization and update process described herein. At step 410, the device (e.g., network device 300) is initialized. The initialization may include powering up the device or performing a user initiated device reset, such as pressing a reset button on the device. At step 420, a first operational condition for the device is entered and established. The first operational condition includes executing a first set of software instructions. The first set of software instructions may be referred to as a bootloader. At step 430, a second operational condition is entered and established. The second operational condition may be referred to as a kernel operating system. The second operational condition may be entered as part of completing the instructions for the first operational condition or may run simultaneously. However, in most instances, the control of the device (e.g., network device 300) is performed by the second operational condition. The software instructions for the first operational condition, at step 520, and the second operational condition, at step 530, are stored in a first portion of memory in a memory circuit (e.g., memory block 330). The first portion of memory is highly reliable but also more expensive than other types of memory. In one embodiment, the first portion of memory is a NOR flash memory and is no larger than 8 MB in size.

During the second operational condition, at step 530, an initialization activity associated with a third operational condition is started. For example, if a software update associated with the control and operation of the device is available for a third operational condition, the second operational condition downloads or transfers the software update to a second portion of memory from a third portion of memory in the memory circuit (e.g., memory block 330). The second portion of memory is also used for storing operating instruction but is less expensive than the first portion of memory. Also, the amount of memory needed to store the third operational condition is much larger than the amount of memory needed to store the first and second operational conditions. In one embodiment, the second portion of memory is a NAND flash memory and is no larger than 32 MB in size. The third portion of memory is larger than either the first or second portion of memory and is typically used to temporary storage of information, including software downloads. The third type of memory often does not include memory persistence and must be periodically refreshed in order to maintain the values in storage. In one embodiment, the third portion of memory is DDR DRAM and is at least 4 GB in size. In another example, the initialization activity associated with the third operational condition, at step 430, may include starting or establishing operational control in the third operational condition. It is important to note that the first set of instructions for the first operational condition are typically limited in functionality and can only interface with simple elements or circuits on the device through the processor (e.g., controller 316) and can only read and write memory locations in the first portion of memory. The instructions for the second operational condition are not as limited but may still only interface without specific instructions to elements or circuits on the device through the processor but can read and write to other portions of the memory in addition to the first portion, including the second and third portions of the memory. Further, it is important to note that the software for the first and second operational condition may not be updated often while the software for the third operational condition may be updated more frequently. In one embodiment, the software for the first operational condition is stored in a write protected section of the first portion of memory to prevent any intentional or accidental overwriting.

At step 440, while initiating an activity associated with the third operational condition during the second operational condition at step 430(e.g., downloading control instruction from the third portion of the memory), a determination is made as to whether an error during the initiating activity has occurred. If, at step 440, it is determined that no error has occurred, then, at step 450, the third operational condition software is initialized (e.g., updated) in the second portion of memory and the third operational condition is entered and established. In some embodiments, the third operational mode represents the operational mode for user interaction with the device. The third operational condition may include all conventional user interface information and controls, graphic display outputs and user functionality associated with the device. If, at step 440, it is determined that an error during download has occurred, then, at step 455, an error flag is set in memory. The error flag is located in a section of the first portion of the memory in order to allow the error flag value to be read while operating in the first operational condition. At step 460, a re-initialization of the device is performed by instructing the processor in the device to reset. At step 465, control of the device is returned to the first operational condition. The first operational condition reads the error flag value to determine that an error has occurred during download of a software update for the device. Last, at step 480, while operating in the first operational condition, an indication of a download error is provided based on determining the value of the error flag. The indication may be provided to the user visually through a simple text based splash screen using only the bootloader software code. The indication utilizes indicator lights on the device to provide update status or the error indication instead of, or in addition to, a display screen based indication.

By utilizing an initialization and update mechanism that returns control of the device to the first operational condition when an error occurs during download of software updates, the first portion of memory may only include only essential initialization control software. Any device specific driver software needed to render and output graphics screens associated with status and conditions of the device, including error conditions, are stored in the second portion of the memory as part of the third operational condition. As a result, the use of the first memory is better managed resulting in improved efficiency and lower cost for the device. Further, the device specific driver software and graphics screens are part of the download and are more easily updated without risk of creating a failure mechanism for the device from which operational recovery may be difficult.

Turning to FIG. 5, a flow chart of another exemplary process 500 for initializing and updating a device is shown. Process 500 may be used in conjunction with network device 300 described in FIG. 3. Process 500 may be also used in conjunction with a set top box device, such as set top box 202 described above. Process 500 may equally apply to one or more of the devices described in FIG. 1 (e.g., external network receiving devices 1 10 and 1 15, MoCA network device 120, and/or local network device 135). The process further may be used in other devices including, but not limited to, gateways, modems, and televisions. Process 500 is describes an embodiment with respect to a specific arrangement for a memory unit (e.g., memory block 330 described in FIG. 3) in conjunction with a controller or processor device (e.g., controller 316). The specific arrangement uses a NOR flash type memory block, and a NAND flash type memory block, and a DDR RAM memory block. Other embodiments using different memory types or different arrangements may also use and benefit from the initialization and update process described herein.

At step 510, a software bootloader is started in the device. The software bootloader is software code stored in the NOR flash memory of a memory circuit (e.g., memory block 330 described in FIG. 3) and is executed by a processor (e.g., controller 316). It is important to note that the bootloader software is typically not update and is in a protected (e.g., non-writeable) portion of the NOR memory. The bootloader may be started, at step 510, as a result of an initial power up of the device or as a result of some other device reset.

Also, at step 510, when the bootloader software starts, (e.g., part of initial power on for the device) the bootloader software performs a check to determine if there is a trivial file transfer protocol (TFTP) connection with a specific type of image available for download. If an image is available, the bootloader software downloads the image and loads the image to the DDR RAM memory portion of the memory circuit. The image may include, among other things, a new set of driver interface and control software (e.g., the device driver interface). The bootloader software may perform an integrity check on the image and may also provide information or notifications to the user, as needed. The display information may be a simple text based display output or an indication using one or more indicator lights on the device. In some embodiments, the notification may be combined with another step of process 500 or may be eliminated to further save memory space. In order to address the update activity as well as any error condition that may occur during transfer and update to the software, at step 520, a memory location is set aside in the NOR memory. In one embodiment, the location is identified as "boot- check" and is used to indicate that there is an image to be updated. One entry in the location is identified as "splash-x" and is used to identify an error that occurs in downloading software code into the NAND memory during software update. Also, at step 520, if the bootloader has initiated a software download or the device has not undergone a soft reset (e.g., a device initiated reset condition), then the initial value for splash-x is set to zero or false to indicate no error. If the bootloader has not initiated a software reset or the device has undergone a soft reset, then the bootloader determines the value of splash-x in the memory location. It is important to note that in some embodiments, the value of splash-x may only be changed as a result of a download error to NAND memory. In other embodiments, the value of splash-x may also be changed by a download error during the download initiated by the bootloader at step 510.

If, at step 520, the determination for the value of splash-x indicates no error is present, then at step 530, the bootloader continues with normal operation including, in some instances, downloading a software image update. When the image download is complete, the image stored in RAM is ready to be transferred into the NOR and NAND memory portion to replace either one or both copies of the control code used in the device. At step 540, the portion of the image, referred to as the bss/kernel-initrd portion, is transferred from the RAM memory to the NOR memory. The bss/kernel-initrd portion of the operating code is based on the linux operating system (OS) and includes code for interfacing to the NAND memory as well basic operational instructions for the device. It is important to note that in some embodiments, that only an operating system kernel (e.g., a linux OS) and not the bootloader software code can interface to the NAND memory. As a result, the bss/kernel-initrd code includes at least some of the Linux OS and is stored in the NOR flash memory.

The bootloader initiates and runs the bss/kernel-initrd portion of the operating code. In one embodiment, no additional device specific driver software is transferred into the NOR memory, saving memory space in the NOR memory.

At step 550, a determination is made as to whether additional software should be updated. The additional software may include the remaining portion of the software image downloaded at step 510 to be transferred into NAND flash memory. The remaining portion may include control instructions for the middleware software associated with normal operation of the device. The determination may made using information in the memory location used at step 520 (e.g., boot-check). If it is determined that additional software should be updated, then at step 560, the bss/kernel-initrd code performs various steps needed to transfer the remaining portion of the image to NAND flash memory from RAM memory. If, at step 550, no image is available (e.g., based on the value of boot-check) then, at step 555, the boot or start up process continues with bss/kernel-initrd running the various processes in the existing software image stored in NAND. The device, at step 555, begins normal user operation using the middleware software control instructions.

If, at step 570, during the time the new software image is being downloaded into NAND, an error occurs, the software download is stopped. In some cases, stopping the download will result in one of the two copies of the operating code no longer being usable. However, in some instances, such as in a factory setup operation or when there is a determination that a severe problem exists with both copies of the operating code, both copies of the software code will require updating. In such a situation, the device may become, or remain, inoperable and notification to the user is necessary. In order to address such situations, at step 570, an indication of a software download error is written into the memory location described at step 520. In one embodiment, the bss/kernel-initrd code sets the splash-x location in boot-check to a value of one or true to indicate that an error has occurred. It is important to note that in some embodiments, the soft reset is performed, at step 580, regardless of whether a download error has occurred. At step 580, the running software code (e.g., bss/kernel-initrd) performs a soft reset of the device. A soft reset may involve resetting the processor in the device (e.g., controller 316 described in FIG. 3) without powering down the remaining portion of the device. A start up condition or initialization for the device begins again and process 500 returns to step 510 to start the bootloader software code again. At step 520, the bootloader software checks the memory location (e.g., splash-x in boot- check) for an error condition. If, at step 520, it is determined that an error has occurred during download, then at step 585, the bootloader provides an indication of the error to the user. At step 590, the device operation is stopped or suspended as a result of the error indication and the user is required to perform a hard reset of the device (e.g., a power off/on cycle or pressing of a reset button that resets the entire device). The suspension of device operation, at step 590, involves placing the device in a suspended condition of operation, not allowing any further operations to occur, and may include providing a visual indication, either through a display output or a user panel or interface output. Additionally, at step 590, the memory location in the NOR memory used for the download information (e.g., boot-check) in order to allow the bootloader to restart the entire process described in process 500 again after the hard reset. In one embodiment, the indication of an error, at step 585, is provided to the user visually through a simple text based splash screen using only the bootloader software code. This splash screen may be a fixed image for display or a simple font set with rendering code in order to minimize memory usage. Similar splash screens may also be included to show other status updates. It is important to note that the splash screens are part of the bootloader operation and not a part of operating the more extensive device specific driver interface code.

In another embodiment, the indication of an error, at step 585, as well as other status during process 500 does not involve a video display to further save memory space, and instead, utilizes indicator lights on the device to provide update status or the error indication. For example, one indicator light may be powered on to indicate the update is occurring. This light may stay on and a second indicator light may flash to indicate the error. As another example, a single indicator light may flash at a first uneven rate (e.g., two brief flashes followed by a long off time) to indicate an update. The same indicator light may flash a slow even duty cycle if an error has occurred.

Although process 500 has been primarily described in relationship to a software or control instruction downloading or updating activity, one or more of the elements of process 500 may be adapted to an initialization activity for the middleware software, similar to that described above in process 400. In one embodiment, as the process continues, at step 555, to establish operation using the middleware software, a determination may be made as to whether an error has occurred in the middleware software. As discussed above, the NAND portion of memory used for storing the middleware is less reliable than the NOR portion. As a result, errors may occur in the NAND portion of the memory over time. If an error is found in the middleware during the initialization of establishing operation of the middleware software, process 500 may continue to step 570 to write an indication of an error into splash-x. The indication may be different from the indication associated with a download error. Process 500 then continues to step 580 as described earlier. It is important to note that a separate error indication may be produced and stored in the memory depending on whether only one copy of the middleware contains an error or both copies contain an error. In this manner, an initialization process that improves the use of memory in the device may be used even when there is no image available for download and the device is performing a normal initialization.

The embodiments described herein allow an error indication or notification to be provided to a user utilizing the lowest or simplest operational condition in the control software for the device, such as the bootloader software. The initialization mechanism establishes a first operational condition, sometimes referred to as a bootloader. The mechanism further establishes a second operational condition, sometimes referred to as a kernel operating system, either coincident with or after completion of the first operational condition. The first and second operational condition use a first type of memory, such as NOR memory, for storing the software control instructions. In one embodiment, the memory size of the first type of memory is smaller than the memory size of the second type of memory.

The second operational condition further initiates an activity associated with a third operational condition, sometimes referred to as middleware. In one embodiment, the activity is downloading the software instructions for the third operational condition from a third type of memory, such as DDR RAM, to a second type of memory, such as NAND memory. If no error is determined, then the device operation proceeds to the third operational condition. In one embodiment, if an error is determined, an indication of the error, such as setting an error flag, is stored in the first portion of memory. The first operational condition is re-established for the device by, for instance, performing a soft reset on the device. While in the first operational condition the memory location associated with the error condition is checked. If an error condition is identified in the memory location, then operation of the device is suspended. The embodiments eliminate the need to include and maintain higher level driver control software and any accompanying error indication information, such as graphics screens for display, associated with the higher level device specific driver control software in the portion of the memory typically using a higher performance, more expensive type of memory, such as NOR memory. In one embodiment, a notification, such as visual indication through the user panel or a on a display, is provided to the user. As a result, the error indication or notification to the user that an error has occurred during initialization, such as while downloading software updates to the device, is performed without using device specific driver interface code.

In one embodiment, the first operational condition is re-established for all software download activity whether or not an error has occurred. As a result, the memory location associated with the error condition is checked and, if no error condition exists, then the device initialization continues to the second operational condition and to the third operational condition.

In one embodiment, the first operational condition also includes an initial startup operational condition for the device. The device can be re-started after suspension of operation by performing an initial start-up condition for the device based on a user input. The re-starting further resetting any indications of errors during a previous initialization. The re-start of the device may include powering on and off the device or pressing a reset button on the device. Although embodiments which incorporate the teachings of the present disclosure have been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that still incorporate these teachings. Having described preferred embodiments of a method and apparatus for controlling the initialization and updating of a device (which are intended to be illustrative and not limiting), it is noted that modifications and variations can be made by persons skilled in the art in light of the above teachings. It is therefore to be understood that changes may be made in the particular embodiments of the disclosure disclosed which are within the scope of the disclosure.

Claims

CLAIMS:

1 ) A method (400) comprising:

establishing (420) a first operational condition in a device, the first operational condition controlled using a first control process stored in a first portion of memory; establishing (430) a second operational condition in the device, the second operational condition controlled using a second control process stored in the first portion of memory, the second operational condition including initiating an activity associated with a third operational condition in the device, the third operational condition using a third control process;

determining (440) if an error has occurred during the initiating of the activity associated with the third operational condition;

setting (455) an error flag at a memory location in the first portion of memory if it is determined that an error has occurred during the initiating of the activity associated with the third operational condition;

re-establishing (460) operation in the first operational condition in the device; determining (465) if the error flag at the memory location in the first portion of memory is set; and

suspending (470) operation of the device while in the first operational condition.

2) The method (400) of claim 1 , wherein the second operational condition is established after completing the first operational condition. 3) The method (400) of claim 1 , wherein the initiating the activity associated with the third operational condition is downloading control instructions for the third control process from a third portion of memory to a second portion of memory.

4) The method (400) of claim 1 , wherein the third control process is stored in a second portion of memory.

5) The method (400) of claim 1 , wherein, the suspending (470) includes providing a visual indication of the error occurring during the initiating of the activity associated with the third operational condition in the device. 6) The method (400) of claim 5, wherein information for the visual indication of the error is stored in the first portion of the memory. 7) The method (400) of claim 1 , wherein the first operational condition includes an initial start-up operational condition for the device, the re-starting further resetting the error flag, the method further comprising performing an initial start-up condition for the device after suspending operation of the device in the first operational condition based on a user input.

8) The method (400) of claim 7, wherein the re-starting is performed by at least of removing and returning power to the device and performing a hard reset on the device initiated by a user. 9) The method (400) of claim 1 , wherein re-establishing (460) operation in the first operational condition is performed using a soft reset initiated by the device.

10) The method (400) of claim 9, wherein performing the soft reset resets a processor used for running the first operational condition in the device.

1 1 ) The method (400) of claim 1 , wherein the first control process is a bootloader, the second control process is a kernel operating system, and the third operational condition is middleware. 12) The method (400) of claim 1 , wherein a storage size of the first portion of memory is smaller than a storage size of the second portion of the memory.

13) The method (400) of claim 1 , wherein the first portion of the memory is NOR type memory.

14) The method (400) of claim 1 , wherein the second portion of the memory is NAND type memory. 15) The method (400) of claim 1 , further comprising establishing (450) the third operational condition in the device if it is determined that no error has occurred during the initiating of the activity associated with the third operational condition. 16) An apparatus (300) comprising:

a memory (330) including a first portion that stores software instructions for a first control process and a second control process; and

a controller (316), coupled to the memory (330), the controller (316) executing control instructions to establish a first operational condition, the first operational condition controlled using the first control process and establish a second operational condition, the second operational condition controlled using the second control process, the second operational condition including initiating an activity associated with the third operational condition, the third operational condition using a third control process, the controller (316) further determining if an error has occurred during the initiating of the activity associated with the third operational condition, setting an error flag at a memory location in the first portion of memory (330) if it is determined that an error has occurred during the initiating of the activity associated with the third operational condition, and re-establishing operation in the first operational condition in the apparatus,

wherein, upon re-establishing operation in the first operational condition in the apparatus (300), the controller (316) further determining if the error flag at the memory location in the first portion of memory (330) is set and suspending operation of the apparatus while in the first operational condition. 17) The apparatus (300) of claim 16, wherein the second operational condition is established after completing the first operational condition.

18) The apparatus (300) of claim 16, wherein the memory (330) further includes a second portion and a third portion and wherein the initiating the activity associated with the third operational condition is downloading control instructions for the third control process from the third portion of memory to the second portion of memory (330). 19) The apparatus (300) of claim 16, wherein the memory (330) includes a second portion that stores software instructions for the third control process that is used to control the third operational condition. 20) The apparatus (300) of claim 19, wherein a storage size of the first portion of the memory (330) is smaller than a storage size of the second portion of the memory (330).

21 ) The apparatus (300) of claim 19, wherein the first portion of the memory (330) is NOR type memory.

22) The apparatus (300) of claim 19, wherein the second portion of the memory (330) is NAND type memory. 23) The apparatus (300) of claim 16, further comprising an interface (322, 326) coupled to the controller (316) and wherein the suspending operation of the apparatus includes providing a visual indication of the error occurring during the initiating of the activity associated with the third operational condition through the interface (322, 326).

24) The apparatus (300) of claim 23, wherein information for the visual indication of the error is stored in the first portion of the memory (330).

25) The apparatus (300) of claim 16, wherein the first operational condition includes an initial start-up operational condition for the apparatus, the initial start-up operational condition further resetting the error flag, and wherein the controller (316) initiates an initial start-up operational condition for the apparatus after suspending operation of the apparatus in the first operational condition as a result of a user input. 26) The apparatus (300) of claim 25, wherein the re-starting is performed by at least of removing and returning power to the apparatus (300) and performing a hard reset on the device initiated by a user. 27) The apparatus (300) of claim 16, wherein the controller (316) re-establishes operation in the first operational condition by performing a soft reset.

28) The apparatus (300) of claim 27, wherein the soft reset resets the controller (316) to the first operational condition.

29) The apparatus (300) of claim 16, wherein the first control process is a bootloader, the second control process is a kernel operating system, and the third control process is middleware.

30) The apparatus (300) of claim 16, wherein the controller (316) further establishes the third operational condition if it is determined that no error has occurred during the initiating of the activity associated with the third operational condition.