Patent Description:
Electronics devices such as micro-controllers or other types of integrated circuit often comprise memories, such as Flash memory, RAM (random access memory), and registers, that can store sensitive data. Furthermore, processing units, such as CPUs (Central Processing Units) of such electronic devices may manipulate sensitive data during processing. Sensitive data designates any data that should be kept secret, and thus should not be accessible from outside the device. The sensitive data for example comprises encryption keys, passwords, software codes, boot codes, or the like. Such electronics devices generally comprise mechanisms for protecting the data stored on or otherwise manipulated by the device. For example, data is stored to the memories at the time of manufacture of the device using one or more access ports, and these access ports are then closed to prevent further access to the memories or processing units during the lifetime of the device. Such access ports can also be used to prevent access to peripherals of the electronic device.

However, sometimes it is desirable that memories, processing units and/or peripherals of an electronic device are rendered accessible during the lifetime of the device, for example for debugging purposes. In particular, an analysis of the data stored in the memory and/or in registers of a CPU by a field application engineer can help identify sources of faulty behavior. However, there are technical and security challenges in implementing an interface permitting access ports to be opened in order to access the memory, processing units and/or peripheral devices during the lifetime of the device.

<CIT> discloses a system on a chip comprising multiple processors, each processor including a debug access port, DBG, enabling secure debugging operations to be performed. The processors are connected via their DBGs and a bus to a debugging control unit comprising a debug port for connecting an external debugging tool. Prior to allowing debug operations to be carried out, the debugging control unit authenticates the external debugging tool, e.g., through a challenge-response authentication protocol.

According to one aspect, there is provided an electronic device comprising: a debug port providing a communications interface for debugging purposes; a first processing unit; one or more processing unit access ports coupled to the debug port, a first of the processing unit access ports being coupled between the debug port and the first processing unit, each of the one or more processing unit access ports being configured to be in one of an open state in which it relays communications to and from the debug port and a closed state in which it blocks communications to and from the debug port; an authentication interface circuit configured to authenticate an external device; and a further access port coupled between the debug port and the authentication interface circuit, the further access port being configured to be in an open state in which communications are relayed between the debug port and the authentication interface circuit, the authentication interface circuit comprising registers including a status register capable of being read by the external device via the debug port and the further access port, the status register being configured to store an indication of the open or closed state of each of the processing unit access ports.

According to one embodiment, the registers further include a host register configured to be read by the first processing unit and of being written to by the external device via the debug port and the further access port.

According to one embodiment, the registers further include a device register configured to be read by the external device via the debug port and the further access port and of being written to by the first processing unit.

According to one embodiment, the registers further include an acknowledge register for indicating when at least part of an electronic message is available to be read in the host register and when at least part of an electronic message is available to be read in the device register, the acknowledge register for example being read-only for the first processing unit and for the external device.

According to one embodiment, the authentication interface circuit is configured: to detect when at least part of an electronic message has been written to the host register, and to set, in response, a host acknowledge bit in the acknowledge register; and to detect when the first processing unit reads the host register, and in response, to reset the host acknowledge bit in the acknowledge register.

According to one embodiment, the authentication interface circuit is configured: to detect when at least part of an electronic message has been written to the device register, and to set, in response, a device acknowledge bit in the acknowledge register; and to detect when the external device reads the device register, and in response, to reset the device acknowledge bit in the acknowledge register.

According to one embodiment, the first processing unit is configured: to read from the host register an authentication request from the external device; to authenticate the external device; and to set at least one of the one or more processing unit access ports to an open state, thereby causing the indication of the state of the one or more processing unit access ports to be updated in the status register.

According to one embodiment, the first processing unit is configured to authenticate the external device by: storing an authentication challenge or password request to the device register; reading an authentication certificate or password from the host register; and verifying the certificate or password.

According to one embodiment, the electronic device further comprises a monotonic counter, the first processing unit being further configured to read from the certificate an indication of a count value from which debug functionality is authorized, and the first processing unit is configured to execute a boot sequence comprising the incrementation of the monotonic counter, the debug functionality being authorized once the monotonic counter has reached said count value.

According to one embodiment, the processing unit access ports are each coupled to an associated processing unit.

According to one embodiment, the electronic device further comprises: a peripheral interface; and a peripheral interface access port coupled between the debug port and the peripheral interface, the peripheral interface access port being configured to be in one of an open state in which it relays communications to and from the debug port and a closed state in which it blocks communications to and from the debug port, wherein the status register is configured to store an indication of the open or closed state of the peripheral interface access port.

According to a further aspect, there is provided a method of initiating a debugging of the above electronic device, comprising: reading, by the external device via the debug port and the further access port, the state of each of the processing unit access ports stored by the status register; and initiating, by the external device, the debug of one or more of the processing units that is in the open state.

Another aspect of the present disclosure relates to a non-transitory computer-readable medium storing a program which, when executed by a processor or computing system in an external device, causes the external device to perform the method as defined above.

The non-transitory computer-readable medium may have features and advantages that are analogous to those set out below in relation to the related method and related device.

For the sake of clarity, only the operations and elements that are useful for an understanding of the embodiments described herein have been illustrated and described in detail. For example, debugging techniques for electronic devices using an external debugger are well known in the art and have not been described in detail.

Unless specified otherwise, the expressions "around", "approximately", "substantially" and "in the order of" signify within <NUM> %, and preferably within <NUM> %.

The term "volatile memory" is used herein to designate a memory device in which data stored in the memory is conserved only when the device is powered, meaning that the data is lost upon power-down. In contrast, a "non-volatile memory" conserves its stored data even when the device is powered-down.

<FIG> schematically illustrates an electronic device <NUM> according to an example embodiment of the present disclosure. The electronic device <NUM> is for example an integrated circuit. In some embodiments, the electronic device is a micro-controller. The electronic device <NUM> for example comprises one or more processing units CPU1, CPU2, CPUn, such as central processing units (CPUs). For example, in some embodiments, the electronic device <NUM> comprises at least two processing units. One of the processing units of the electronic device <NUM> is for example designated as a master processing unit. In the example embodiments of the following description, the processing unit CPU1 is designated as the master processing unit, although in alternative embodiments another of the processing units could be the master.

The processing units CPU1 to CPUn are for example coupled to a system bus <NUM>, which is further coupled to one or more memory circuits. The memory circuits may comprise one or more non-volatile memories and/or one or more volatile memories. In the example of <FIG>, the memory circuits include a non-volatile memory <NUM> (FLASH), which is for example a Flash memory, and a volatile memory <NUM> (RAM), which is for example a random access memory. The one or more memory circuits <NUM>, <NUM> may store for example software code including instructions that are executed by the one or more processing units in order implement the functionalities of the electronic device <NUM>.

In some embodiments, the electronic device <NUM> further comprises a monotonic counter <NUM> (MONOTONIC CNTR). The monotonic counter <NUM> may be for example coupled to the bus <NUM>.

Monotonic counters are known in the background art, an example of such a counter being described in the publication "<NPL>, and in particular in part <NUM> of this paper. This paper describes embodiments of counters implemented by hardware and/or by software. The monotonic counter <NUM> is for example implemented by hardware in the form of a digital circuit, such as an Application Specific Integrated Circuit (ASIC). The monotonic counter <NUM> is configured to maintain a count value, accessible at an output <NUM> of the counter. In the example of <FIG>, the monotonic counter <NUM> may be coupled to the non-volatile memory <NUM>.

Following an increment instruction, for example generated by the master processing unit CPU1, the monotonic counter <NUM> is configured to irreversibly increase its count value by one or more units, but following each increment, the operation is not reversible. Indeed, the monotonic counter <NUM> is configured so that its count value may only increase and may never decrease. Moreover, between two increments, the count value is protected against any modification, so that it cannot be erased or changed. Only the increment instruction allows the current value to be replaced by a new value that is higher than the current value.

The monotonic counter <NUM> is configured such that no instruction, other than a resetting of the electronic device <NUM>, will permit the counter to return to a previous count value once the increment instruction is executed. In the case where the count value is stored in a volatile manner, each time the electronic device <NUM> is powered down, the count value is lost and each time the device <NUM> is rebooted, the monotonic counter <NUM> for example generates an initial count value again. In the case where the count value is stored in a non-volatile memory, upon each reboot, a current count value stored in the non-volatile memory is for example over-written by the initial count value.

The electronic device <NUM> further comprises an authentication interface circuit <NUM> (DBG AUTH HW I/F), which is for example a hardware circuit coupled to the bus <NUM>, and configured to permit an authentication of an external device (not illustrated in <FIG>), which may be connected to the electronic device <NUM> for debugging purposes.

The electronic device <NUM> further comprises a debug port <NUM> (DEBUG PORT) providing a communications interface for debugging purposes. For example, the debug port <NUM> is a hardware circuit comprising data buffers and/or other circuitry for facilitating data communications between the electronic device <NUM> and an external device that is coupled to the debug port <NUM>. For example, the debug port <NUM> comprises a wired communications interface configured to provide wired communications between the electronic device <NUM> and the external device, the wired communications interface for example comprising a socket for receiving a plug of a cable linking the device <NUM> to the external device. Alternatively, the debug port <NUM> comprises a wireless communications interface for providing wireless communications between the electronic device <NUM> and the external circuit.

The debug port <NUM> is for example coupled to the authentication interface circuit <NUM> and to each of the processing units CPU1 to CPUn via a dedicated bus <NUM>, different to the system bus <NUM>.

While not illustrated in <FIG>, the electronic device <NUM> may further comprise one or more peripheral device interface circuits for interfacing with peripheral devices of the device <NUM>. For example, such interface circuits are also coupled to the system bus <NUM>, and are also accessible by the debug port <NUM> via the dedicated bus <NUM>.

<FIG> schematically illustrates access ports AP0 to APn of the electronic device <NUM> of <FIG> according to an example embodiment of the present disclosure.

In particular, the debug port <NUM> is coupled to each of the processing units CPU1 to CPUn via, for example, the dedicated bus <NUM> and via corresponding access ports AP1 to APn. These access ports will also be referred to herein as processing unit access ports, and are each capable of being in open and closed states. Furthermore, in the case that the electronic device <NUM> comprises one or more peripheral device interface circuits, the debug port <NUM> is for example coupled to each interface circuit via the dedicated bus <NUM> and via a corresponding peripheral interface access port (not illustrated) similar to the access ports AP1 to APn. In the following, what is described in relation with the processing unit access ports applies, mutatis mutandis, to the peripheral interface access ports.

When in the open state, each access port relays communications to and from the debug port <NUM>. When in the closed state, the debug port blocks communications to and from the debug port <NUM>.

Furthermore, the debug port <NUM> is for example coupled to the authentication interface circuit <NUM>, for example via the dedicated bus <NUM> and via an access port AP0. The access port AP0 is for example configured to be always open during one or more states of the electronic device <NUM>, as will now be defined. For example, the access port AP0 is open when the electronic device <NUM> is in a state according to which it is powered but prior to release of a reset state of the device, and during a booting state in the case that a debug authentication request has been made, as described in more detail below. In this open state, the access port AP0 is configured to relay communications between the debug port <NUM> and the authentication interface circuit <NUM>.

Each of the access ports AP0 to APn is for example a hardware circuit comprising memory buffers and/or other circuitry for relaying communications, when in the open state, between the debug port and the circuit <NUM> or processing units CPU1 to CPUn. In the case of the processing unit access ports AP1 to APn, these are positioned between the debug port <NUM> and the processing units CPU1 to CPUn respectively, and provide the only available communications channel between the debug port <NUM> and the processing units CPU1 to CPUn. Thus, when these access ports AP1 to APn are in the closed state, no communications link is available between the debug port <NUM> and the processing units CPU1 to CPUn, and the processing units CPU1 to CPUn are thus protected from unauthorized access attempts via the debug port <NUM>.

The access ports AP0 to APn are for example controlled to be in the open or closed state by control bits stored in a system control register <NUM>, which is for example programmed by the master processing unit CPU1.

As illustrated in <FIG>, an external device <NUM> (EXTERNAL DEVICE) is for example connected to the debug port <NUM> when a debugging procedure is to be initiated. The external device <NUM> is for example a computer executing a debugger, which is a software program for use in debugging the electronic device <NUM>.

The authentication interface circuit <NUM> for example comprises registers <NUM> (HOST-DEVICE REGS) allowing communications between the external device <NUM> (host) and the master processing unit CPU1, as will now be described in more detail with reference to <FIG>.

<FIG> schematically illustrates the host-device registers <NUM> of the authentication interface circuit <NUM> of <FIG> in more detail according to an example embodiment of the present disclosure.

The registers <NUM> are for example all volatile registers.

The registers <NUM> for example comprise a status register (DBG_AUTH status register [<NUM>:<NUM>]) <NUM>, which is configured to store an indication of the open or closed state of each of the access ports of the device, such as the processing unit access ports AP1 to APn, and the one or more peripheral interface access ports, if present. The status register <NUM> is capable of being read by the external device <NUM> via the debug port <NUM> and via the access port AP0. In some embodiments, the status register <NUM> is read-only. In the example of <FIG>, the status register <NUM> is a <NUM>-bit register, although in alternative embodiments other sizes would be possible. Furthermore, in the example embodiment of <FIG>, the status register <NUM> is capable of indicating the status of up to <NUM> access ports AP0 to AP15, although in alternative embodiments more or fewer access ports could be supported, depending on the size of the status register <NUM>. In the example of <FIG>, the status register <NUM> stores, for each access port, a first bit AP0P to AP15P indicating whether the corresponding access port AP0 to AP15 is present, and a second bit AP0S to AP15S indicating the current status of the corresponding access port AP0 to AP15, in other words whether it is open or closed.

Upon power-up of the electronic device <NUM>, the contents of the status register <NUM> is for example loaded, by a state machine (not illustrated), from secure storage in a non-volatile memory, such as the memory <NUM> of <FIG>. For example, by default, upon power-up, the access ports AP1 to APn are all set to closed, whereas the access port AP0 is set to open. The open or closed status to each of the access ports AP0 to APn is for example controlled directly by stored states of the electronic device <NUM> that are stored in secure storage.

An advantage of the status register is that it provides a scalable solution capable of supporting the addition of further access ports to the system.

In some embodiments, the registers <NUM> further include a host register <NUM> (DBG_AUTH host register [<NUM>:<NUM>]) permitting the external device <NUM>, acting as host, to write to the electronics device <NUM>, for example to the master processing unit CPU1. Thus, the host register <NUM> is for example capable of being written to and read by the external device <NUM>, and of being read by the electronic device <NUM>, for example by master processing unit CPU1. In the example of <FIG>, host register <NUM> is a <NUM>-bit register, although in alternative embodiments other sizes would be possible.

In some embodiments, the registers <NUM> further include a device register <NUM> (DBG_AUTH device register [<NUM>:<NUM>]) permitting the electronics device <NUM>, for example the master processing unit CPU1, to write to the external device <NUM>. Thus, the device register <NUM> is for example capable of being read by the external device <NUM> via the debug port <NUM> and the access port AP0, and of being written to and read by the electronic device <NUM>, for example by master processing unit CPU1. In the example of <FIG>, device register <NUM> is a <NUM>-bit register, although in alternative embodiments other sizes would be possible.

The host and device registers <NUM>, <NUM> are for example configured to play a role of a single-word receiving/transmitting deep FIFO (first-in, first-out) buffer. In particular, a data message that is bigger than the size of either register can for example be transmitted via the registers <NUM>, <NUM> one word at a time, and read one word at a time, until the whole message has been communicated.

In some embodiments, the registers <NUM> further include an acknowledge register <NUM> (DBG_AUTH acknowledge register [<NUM>:<NUM>]) for indicating when at least part of an electronic message is available to be read in the host register <NUM> and when at least part of an electronic message is available to be read in the device register <NUM>.

The acknowledge register <NUM> is for example read-only for the processing unit CPU1 and for the external device <NUM>. In some embodiments, the acknowledge register <NUM> stores a host acknowledge bit HOST ACK and a device acknowledge bit DEV_ACK.

For example, the authentication interface circuit <NUM> is configured to detect when at least part of an electronic message has been written to the host register <NUM>, and to set, in response, the host acknowledge bit HOST_ACK in the acknowledge register <NUM>. The master processing unit is for example configured to poll the host acknowledgement bit HOST_ACK, and to read the host register <NUM> in response to the host acknowledgement bit HOST_ACK being set. The authentication interface circuit <NUM> is for example further configured to detect when the electronic device, for example the master processing unit CPU1, reads the host register <NUM>, and in response, to reset the host acknowledge bit HOST_ACK in the acknowledge register <NUM>.

For example, the authentication interface circuit <NUM> is further configured to detect when at least part of an electronic message has been written to the device register <NUM>, and to set, in response, the device acknowledge bit DEV_ACK in the acknowledge register <NUM>. The external device <NUM> is for example configured to poll the device acknowledgement bit DEV_ACK, and to read the at least one device register <NUM> in response to the device acknowledgement bit DEV_ACK being set. The authentication interface circuit <NUM> is for example further configured to detect when the external device reads the electronic message from the device register <NUM>, and in response, to reset the device acknowledge bit DEV_ACK in the acknowledge register <NUM>.

A technical advantage of the dedicated acknowledge register <NUM> is that it leads to improved communication bandwidth between the external device <NUM> and the master processing unit CPU1 because data messages, or frames, can flow in both directions in parallel. A technical effect of the acknowledgement register being read-only is that this increases security.

Furthermore, a technical advantage of providing both a device register and a host register is that they accelerate the debug authentication process, as it is not necessary for the device or host to wait for a read acknowledgement prior to transmitting in the other direction.

<FIG> is a flow diagram illustrating operations in a method of accessing the electronic device <NUM> for debugging purposes using the external device <NUM> according to an example embodiment of the present disclosure.

In an operation <NUM> (CONNECT DEBUGGER), the external device <NUM> is for example connected to the debug port <NUM> of the electronic device <NUM>, for example via a wired or wireless link.

In an operation <NUM> (DETECT UNDER RESET THAT DEBUG CLOSED), the external device <NUM>, under control of the debugger, is for example configured to detect that the debug function of the electronic device <NUM> is closed, for example by reading the status register <NUM> and determining that one or more of the access ports AP1 to APn via which debugging is to be performed is closed. For example, this operation is performed while the external device <NUM> applies a reset command to the electronic device <NUM>, for example via a reset pin of the electronic device <NUM>.

In an operation <NUM> (WRITE AUTH REQUEST TO HOST REG + RELEASE RESET), the external circuit <NUM>, under control of the debugger, is for example configured to write an authentication request to the host register <NUM>, and then to release the reset of the electronic device <NUM>. In response, the authentication interface circuit <NUM> is for example configured to set the ACK_HOST bit in the acknowledge register <NUM>.

In an operation <NUM> (MASTER CPU BOOTS + READS HOST REG), the master processing unit CPU1 is for example configured to boot, and to read the authentication request in the host register <NUM>, for example after having detected that the ACK_HOST bit in the acknowledge register <NUM> is set. This for example causes the master processing unit to maintain the open state of the access port AP0 during boot. In response, the authentication interface circuit <NUM> is for example configured to reset the ACK_HOST bit in the acknowledge register <NUM>.

In an operation <NUM> (MASTER CPU WRITES AUTH CHALLENGE TO DEVICE REG AND DEVICE REG READ BY DEBUGGER), the master processing unit CPU1 is for example configured to write an authentication challenge to the device register <NUM>. In response, the authentication interface circuit <NUM> is for example configured to set the ACK_DEV bit in the acknowledge register <NUM>. The external device <NUM>, under control of the debugger, is then for example configured to read the authentication challenge in the device register <NUM>, for example after having detected that the ACK_DEV bit in the acknowledge register <NUM> is set. In response, the authentication interface circuit <NUM> is for example configured to reset the ACK_DEV bit in the acknowledge register <NUM>. Of course, if the size of the challenge exceeds the size of the device register <NUM>, it is for example communicated by the master processing unit to the external circuit <NUM> over several write/read cycles until it has been entirely sent.

In an operation <NUM> (DEBUGGER STORES CERTIFICATE TO HOST REG), the external circuit <NUM>, under control of the debugger, is for example configured to generate an authentication certificate based on the challenge, and to store the certificate to the host register <NUM>. In response, the authentication interface circuit <NUM> is for example configured to set the ACK_HOST bit in the acknowledge register <NUM>. The master processing unit CPU1 is then for example configured to read the host register <NUM>, for example after having detected that the ACK_HOST bit in the acknowledge register <NUM> is set. In response, the authentication interface circuit <NUM> is for example configured to reset the ACK_HOST bit in the acknowledge register <NUM>. Of course, if the size of the certificate exceeds the size of the host register <NUM>, it is for example communicated by the external device <NUM> to the master processing unit CPU1 over several write/read cycles until it has been entirely sent.

In an operation <NUM> (MASTER CPU VERIFIES CERTIFICATE + UNLOCKS APs), the master processing unit CPU1 is for example configured to verify the certificate, and if validated, to unlock, and thus set to open status, one or more of the processing unit access ports AP1 to APn based on the credentials indicated by the certificate. In other words, debug is opened for all or selected processing unit access ports AP1 to APN. For example, this is done by writing, by the master processing unit CPU1, to the one or more system control registers <NUM> of <FIG>. For example, each processing device access port has its own dedicated control bits in the system control registers <NUM>.

In some embodiments, the credentials indicated in the certificate also indicate a debug level that is permitted, for example indicating whether all firmware can be debugged, or only non-secure firmware.

Furthermore, in some embodiments, the master processing unit CPU1 is configured to set, based on the credentials indicated by the certificate, a count value of the monotonic counter <NUM> of <FIG> from which debug functionality is authorized. This count value is for example stored as a parameter in the non-volatile memory <NUM>. Then, when the master processing unit CPU1 is next configured to execute a boot sequence involving the incrementation of the monotonic counter <NUM>, the debug functionality is authorized once the monotonic counter has reached the determined count value. For example, the boot sequence comprises two or more stages, each associated with corresponding software code, which is executed in sequence. The software code for each stage is associated with a corresponding count value, meaning that once this count value has been exceeded by the monotonic counter <NUM>, the non-volatile memory <NUM> is configured to no longer permit access to the code. The use of a monotonic counter <NUM> for controlling secure debug during a boot sequence is for example described in more detail in the European patent application <CIT>.

In the case that, in operation <NUM>, the verification by the master processing unit CPU1 of the certificate fails, for example because the certificate is false, the master processing unit is for example configured to maintain the processing unit access ports AP1 to APn in the closed state, and, for example, to inform the external device via the device register <NUM>.

In an operation <NUM> (MASTER CPU SENDS AUTH VALIDITY MESSAGE TO DEBUGGER + WAITS FOR AUTH ACK), the master processing unit CPU1 for example stores to the device register <NUM> an authorization validity message, which is read by the external device <NUM>, under control of the debugger. The master processing unit CPU1 then for example waits for an acknowledgement from the external device <NUM>.

In an operation <NUM> (DEBUGGER CONFIGURE DEBUG PERIPHERALS + MAKES CPU HALT REQ + SENDS AUTH ACK) the external device <NUM>, under control of the debugger, for example configures the debug peripherals via the access ports, and then makes a CPU halt request, for example to the master processing unit and/or to another of the processing units. For example, with the access port AP1 in the open state, the system control registers <NUM> of <FIG> associated with the master processing unit are accessible, such that the debugger can make the CPU halt request via these registers. For example, this halt request will only be permitted by the master processing unit CPU1 if it corresponds to a boot stage corresponding to a count value of the monotonic counter equal to or greater than the authorized count value. The external device <NUM>, under control of the debugger, also for example sends an authentication acknowledgement to the master processing unit CPU1 via the host register <NUM>.

In an operation <NUM> (MASTER CPU OPENS DEBUG), the master processing unit CPU1 is for example configured to fully open the debug of the processing unit access ports covered by the certificate, for example by writing to the system control registers <NUM> of <FIG>, when the appropriate boot execution stage is reached. For example, fully opening the debug means that the debugger of the external device <NUM> is able to access the system control registers of the associated processing unit, such as the registers <NUM> in the case of the master processing unit.

In some embodiments, a method of initiating a debugging of the electronic device <NUM> of <FIG> comprises, after coupling the external device <NUM> to the debug port <NUM>, reading, by the external device <NUM> via the debug port <NUM> and the further access port AP0, the state of each of the processing unit access ports AP0 to APn stored by the status register <NUM>; and initiating, by the external device, the debug of one or more of the processing units that is in the open state.

An advantage of embodiments described herein is that they provide the technical effect of allowing an external device, such as a computer, running a debugger, to communicate in a secure manner with an electronic device in order to identify a debug status of the electronic device, and in some cases to obtain a unique identifier of the electronic device <NUM>, which is for example stored in non-volatile memory such as in the memory <NUM>, and/or to issue credentials for debug re-opening on the electronic device.

Various embodiments and variants have been described. Those skilled in the art will understand that certain features of these embodiments can be combined and other variants will readily occur to those skilled in the art. For example, it will be apparent to those skilled in the art that in some embodiments, only one or some of the registers <NUM>, <NUM>, <NUM> and <NUM> of <FIG> may be present in the authentication interface circuit <NUM>. Furthermore, while embodiments have been described in which authentication is based on a challenge and a response certificate, in alternative embodiments, rather than a challenge, a password request is set by the master processing unit to the external device, and the external device replies with a password rather than a certificate, the password then being verified by the master processing unit.

Claim 1:
An electronic device comprising:
- a debug port (<NUM>) providing a communications interface for debugging purposes;
- a first processing unit (CPU1);
- one or more processing unit access ports (AP1, APn) coupled to the debug port (<NUM>), a first of the processing unit access ports (AP1) being coupled between the debug port (<NUM>) and the first processing unit (CPU1), each of the one or more processing unit access ports (AP1, APn) being configured to be in one of an open state in which it relays communications to and from the debug port (<NUM>) and a closed state in which it blocks communications to and from the debug port (<NUM>);
- an authentication interface circuit (<NUM>) configured to authenticate an external device (<NUM>); and
- a further access port (APO) coupled between the debug port (<NUM>) and the authentication interface circuit (<NUM>), the further access port (APO) being configured to be in an open state in which communications are relayed between the debug port and the authentication interface circuit (<NUM>), the authentication interface circuit (<NUM>) comprising registers (<NUM>) including a status register (<NUM>) capable of being read by the external device (<NUM>) via the debug port (<NUM>) and the further access port (AP0), the status register being configured to store an indication of the open or closed state of each of the processing unit access ports (AP1, APn).