Should DC/DC firmware be accessible to users?

Introduction

Providing access to firmware code is a sensitive issue in any product. In the automotive industry, for example, drivers of the latest car models expect regular over-the-air (OTA) updates to improve functionality and fix bugs. To enhance security, these updates rely on Trusted Platform Module technology and secure crypto-processors to prevent unintended changes, tampering, or the installation of malicious code.

While system-level updates like this are common, there is a growing interest in enabling firmware changes to lower-level components, such as the DC/DC converters that power processors in server applications. These converters provide essential volts and amps, but increasingly feature digital control and monitoring capabilities. This allows manufacturers to configure a common platform product for multiple applications or for users to customize parameters such as voltage set-point, fault detection limits, and sometimes even loop frequency response. This is all done typically via a PMBus® interface with its elementary security features. However, the core DC/DC functionality is stored in non-volatile memory – firmware which remains inaccessible.

Why would you want to change DC/DC firmware?

As DC/DCs have evolved and become more complex and capable, several scenarios have emerged where updating firmware after the parts have been shipped could be beneficial:

• Some customer needs may go beyond the features covered by PMBus commands – for example, customization of ‘event record data’ or adding unique part identifiers.
• Basic functionality changes – this might occur in custom DC/DC designs where parts are shipped to support prototype systems whose specifications are still evolving.
• Installation of manufacturer upgrades to enhance functionality – for example, improved algorithms for achieving current sharing might require updates.
• Firmware verification – reinstalling default firmware could help verify system integrity.
• Declared new bug fixes – addressing identified issues post-deployment.

A modern DC/DC with PMBus interface and embedded firmware

Allowing firmware access – the challenges

Currently, DC/DC converters are typically not designed to allow access to firmware to ensure security, protect the device from invalid and possible harmful changes, and to safeguard the manufacturer’s intellectual property. In theory, an existing PMBus interface could be used to make firmware changes with the appropriate levels of security. This is addressed in the proposed PMBus 1.5 specification, a version that defines enhanced security measures and encryption-based authentication to target specific devices and limit command write capabilities.

In practice, DC/DCs stocked as components could be designed to allow firmware updates through the PMBus via a custom fixture and PC with a manufacturer-supplied software application. This would be similar to a GUI used for configuration, such as Flex Power Designer. Voltage would need to be applied to the DC/DC input via the fixture to power the internal processor and memory during the update.

Updating firmware for installed DC/DC converters presents significant potential challenges. Any external processor handling the update would typically be powered from the DC/DC output itself, which therefore must not be interrupted during the uploading process. However, with only one memory space, the converter can’t operate during the update, as the first thing that happens during uploading is that memory is erased. With that, there is no code to control the DC/DC conversion process and consequently no output power. A possible solution to this is to load the new DC/DC firmware code into a secondary memory area, then this area is made the main one after verification. Not only would this enable output voltage during the uploading process, but it would also allow reversion to known good code if the upload fails.

In theory, the memory could be split into partitions of different sizes, one only providing a basic ‘recovery’ function in a smaller memory space. However, in practice, converters might be tied together in parallel mode or similar, requiring all code to be there for the parts to start correctly and safely. So, it is most likely that two full-size memory spaces would be required in each DC/DC, with the consequent extra cost and size. Another possibility is to physically partition the memory spaces so that the basic power conversion functionality is not erased during an upload, accepting the limitation that this cannot be updated. Again, implementing this would be a significant hardware overhead.

Since an upload might happen several times during the lifetime of the DC/DC, a practical problem is that the extra memory needs to be ‘Flash’ type which is more expensive than the popular ‘One Time Programmable’ memory. The improved functionality, therefore, comes at the expense of device size, complexity, and manufacturing costs.

Final thoughts

Enabling remote access to firmware in components like DC/DC converters offers many potential advantages, such as allowing updates to keep a system operating efficiently. However, the cost of implementation and the associated security risks must be carefully considered. Additionally, there is new legislation, such as the European Cyber Resilience Act (CRA), to consider that require manufacturers of end-equipment with a ‘digital component’ to allow software updates to address any security vulnerabilities identified...

As the concept of allowing remote access to component firmware evolves, end-equipment and DC/DC manufacturers will need to liaise closely to ensure that improved functionality and security are achieved, without unsustainable extra costs and component size.