PSoC5 Dual Application USB FS Bootloader

Summary

This post provides an example Cypress bootloader project which features dual bootloadable applications and updates through USB communications.

Why an Example
While looking into field upgrades for Cypress microcontrollers, it was found that the MiniProg3, Kitprog boards with snap off programming modules or a Cypress bootloader were commonly used in the example projects. This was no doubt a small portion of what is available but not what was required. Some examples featured a bootloader and a single application although none were published with dual applications.

Looking at the newer range of Cypress devices, there were dual application bootloader examples for the PSoC6 MCU however these examples were not portable back to the PSoC4 or PSoC5 devices.

Using a PSoC5 development board and related Cypress documentation, a project with basic bootloader and bootloader functionality was created.

Development Board
For this post the Cypress PSoC5 CY8CKIT-059 was used for testing dual application functionality. One hardware modification was made for detecting when USB power was applied to the Micro USB connector. The Micro USB connector is shown to the left side of the PSoC5 development board in the image below.

PSoC5 Test Setup

 

Bootloader Setup and Hardware Changes
The Cypress code example, USBFS_Bootloader.cywrk, served as the framework for the dual application project. 

As a first step the example projects reference PSoC device, CY8C3866AXI, was changed to a CY8C5888LTI-LP097 to suit the PSoC5 development board.

Opening the USBFS component the name of the USB descriptor string was changed under the String Descriptor tab to reflect the PSoC5 device.

USBFS String Descriptor Change

 

Under the Advanced tab of the USBFS component, the VBUS option was enabled. This input facilitates detection of USB power through a physical input on the PSoC5. Enabling the VBUS (input) in the USBFS component was not mandatory. The input serves two purposes, firstly the USBFS component can return the state of the USB power using the API - USBFS_VBusPresent(). Secondly the USB power (Micro USB connector) detection allows one possible method of initiating the Cypress bootloader when the device is bus powered.

USBFS VBUS Monitoring

 

With VBUS monitoring enabled in the USBFS component, an input was available on the component.

USBFS VBUS Monitor Input

 

As shown in the capture above, input P15_5 was connected to the component for USB power detection.

On the rear of the development board a wire link was made between the P15_5 pad and the Anode of component D2.

PSoC5 USB Bus to VBUS Input

 

Shown below is a portions of the PSoC5 development board schematic (Micro USB connector). The wire link connected from P15_5 to the Anode of D2 was made to ensure that USB (Micro USB connector) power was detected and not the power provided by the usual KitProg connector.

In the Bootloader component the wait for command was reduced to a time of zero so that the Application 1 or 2 could be called by the bootloader. The dual application and golden image support was also enabled. Golden image support was enabled in the Bootloader component to ensure that a valid Application 1 would always be available. It should be noted that the project will operate with only Application 2 programmed. Changes could be made in the firmware to prevent this operation.

Bootloader Component Configuration

 

A timer for flashing an LED and UART for debugging were also added to the project. These items were not critical for operation.

Bootloadable Setup
The bootloadable firmware (Applications) were essentially the same. These projects consisted of a Bootloadable component and each with a timer for flashing a LED. The difference between the two applications were the different LED flashing rates.

Bootloadable Component Configuration

For the settings in the Bootloadable component, it was stated on page 44 of the Cypress Bootloader and Bootloadable component datasheet that the Manual application image placement information for the dual applications should be the same.

Bootloader and Bootloadable Component Datasheet - Extract Page 44

The bootloadable dependencies (.hex and .elf) for the two applications was referenced to the projects bootloader.

Bootloadable Projects Bootloader Dependency 

 

Bootloader Firmware 
For the Bootloader firmware, a check was added for the USB (Micro USB connector) power using the call USBFS_VBusPresent(). 

If the Micro USB power was detected then the Cypress Bootloader was initiated.
To update Bootloadable Application 2 over USB, a call using Bootloader_SetActiveAppInMetadata(0) was required.

Otherwise without Micro USB power the bootloadable applications were verified using the call Bootloader_ValidateBootloadable(). Switching to a valid Bootloadable application was made with application 2 taking precedence over application 1.

/**
* @file main.c
*
* @version 1.0
*
* @brief Shell example for Cypress Dual Application Bootloadable project                                      
*/

#include <project.h>
#include <stdbool.h>
#include <Bootloader.c>             /* Required to set active app in metadata */

CY_ISR_PROTO(SYS_TMR_HANDLER);
/**
* @brief System timer, flashes LED
*/
CY_ISR(SYS_TMR_HANDLER)
{   
    LED_Write(~LED_Read());
    Timer_2_ReadStatusRegister();
    isr_SysTmr_ClearPending();   
}

/**
* @brief Boot to valid APP2 then APP1 if no VBUS.
* @details VBUS present allow bootloader
*/
int main(void)
{
    CyGlobalIntEnable;
    isr_SysTmr_StartEx(SYS_TMR_HANDLER);
    UART_Start();
    USBFS_Start(0, USBFS_5V_OPERATION);

    if (USBFS_VBusPresent() == true)
    {
       LED_Write(true);
       Bootloader_SetActiveAppInMetadata(0);
       Bootloader_Start();
    }

    if (Bootloader_ValidateBootloadable(1) == CYRET_SUCCESS)
    {
        Bootloader_Exit(Bootloader_EXIT_TO_BTLDB_2); 
    }

    if (Bootloader_ValidateBootloadable(1) == CYRET_BAD_DATA)
    {
        UART_PutString("APP2 Bad");
    }
    if (Bootloader_ValidateBootloadable(0) == CYRET_SUCCESS)
    {
        Bootloader_Exit(Bootloader_EXIT_TO_BTLDB_1); 
    }

    if (Bootloader_ValidateBootloadable(0) == CYRET_BAD_DATA)
    {
        UART_PutString("APP1 Bad");
        Timer_2_Start();
    }    

    for(;;)
    {  
    }
}

Bootloadable Firmware 
For the Bootloadable applications the firmware was made the same. To differentiate between the active applications the flashing LED rate was set for 1s in Application 1 and 2s for Application 2. A compare value in the Timer (System) component was used to configure the flash rate. 

/**
* @file main.c
*
* @version 1.0
*
* @brief Shell example for Cypress Dual Application Bootloadable project                                      
*/

#include <project.h>
#include <stdlib.h>
#include <stdbool.h>

CY_ISR_PROTO(SYS_TMR_HANDLER);
/**
* @brief System timer, flashes LED 2 sec
*/
CY_ISR(SYS_TMR_HANDLER)
{   
     LED_Write(~LED_Read());
    Timer_2_ReadStatusRegister();
    isr_SysTmr_ClearPending();   
}

/**
* @brief Init PSoC
*/
void PSoC_Init() 
{                                                             
    Timer_2_Start();
    isr_SysTmr_StartEx(SYS_TMR_HANDLER);                                                   
}

/**
* @brief Handle main
*/
int main()
{        
    CyGlobalIntEnable;
    PSoC_Init();
    for(;;)
    {                         
    }
}

Bootloadable Firmware Build
Other than selecting Build All Projects from the Build menu in PSoC Creator, no other changes were required. Following a successful build process, several files are generated. For this blog the project was built in Debug with relevant .hex and .cyacd files located in the location \CortexM3\ARM_GCC_541\Debug.

Bootloader Firmware Testing 
To test the Bootloader only the Bootloader application was programmed into the PSoC5 development board. 

Running standalone and without the USB (Micro USB) connected, the serial debug returned the string "APP2 Bad" followed by "APP1 Bad". With no valid application detected the onboard LED was flashed at a fast rate courtesy of system timer.

With the KitProg disconnected and the USB (Micro USB) connected the Bootloader set the onboard LED to ON and started the Cypress Bootloader.

To test programming of the Bootloadable application the Bootloader Host application, from the PSoC Creator Tools menu, was launched. This application provided the interface for updating Application 2; Application 1 was marked as a Golden Application and cannot be updated even if it is not programmed.

Cypress Bootloader Host Application with USB Connection

The Bootloader Host application indicated the Active Application in the top right hand corner of the window. Attempting to program the relevant .cyacd file for Application 1 resulted in an error relating to the active application as shown in the capture below. Application 1 was marked as the active application by the Bootloader using the call Bootloader_SetActiveAppInMetadata(0). 

Modifying the code to switch between the active applications should be possible.

PSoC Application Marked Active Message

  Attempting to program Application 2 with Application 1 results in a checksum error message as shown below.

Programming PSoC Application 1 onto Application 2 Message

  While programing Application 2 with the relevant file, App2_2.cyacd is possible and programming is successful, there is no relevance as this is a dual application project with a golden Application 1.

Bootloader with Bootloadable 1 Firmware Testing 
For the following sets of tests the Bootloader and Bootloadable Application 1 was programmed into the PSoC5 development board.

Running standalone and without the USB (Micro USB) connected, the serial debug returned the string "APP2 Bad". With Application 1 returned as valid the application is started. To validate operation of the application, the onboard LED was flashed at a rate of 1 sec ON then OFF.

As with the initial Bootloader test, the KitProg was disconnected and the USB (Micro USB) connected. The Bootloader set the onboard LED to ON and started the Cypress Bootloader.


Again launching the Bootloader Host from the PSoC Creator Tools menu provided the interface for updating Application 2; Application 1 was marked as the Active Application.

Programing Application 2 with the relevant file, App2_2.cyacd, was completed without error.

PSoC Application 2 Programmed Message

  After cycling the power to the development board, Application 2 was detected as a valid application by the Bootloader and was started. The onboard LED was flashed at a rate of 2 sec ON then OFF.


Project Uses
The proposed implementation in this project may be useful for designs where a minimum operating firmware is required for a product or design. This minimum operating firmware would be considered the Golden application version. A dual application with a Golden application also addresses the issue of application corruption during download, although this event is possible although unlikely.

A further application for a dual application project may be in a commercial product environment. Consider that a commercial product may require end to end device testing which requires a separate firmware implementation to function with a test environment. With modification of the firmware to select applications, a dual application project could allow for execution of either firmware thereby minimising reprogramming.

Some limitations of this project implementation relates to the increased use of memory space and the need to provide specific Bootloadable applications. These applications must occupy the memory locations as defined by the Cypress documentation and project software.

Downloads
The PSoC Creator 4.2 project for the example in this blog was saved as a minimal archive.

USBFS Bootloader with Dual Bootloadable Applications

USB Large capacitance on data lines

Summary

This post details how the fitting of incorrect capacitors on USB lines can result in operational issues.

Hardware

After several years of use some of the surface mount capacitors on my FTDI branded debugger module showed signs of cracking, time to replace them.

FTDI VNC2 Debugger Module

Both capacitors (C8 & C9) associated with the USB D+ and D- lines were removed without any resulting communications issues. Schematic extract below was taken from the VNC2 Debugger datasheet.

FTDI VNC2 Debugger USB Input Section

As the USB line capacitors are there for multiple reasons, replacements were located. FTDI recommend capacitors in their Debugging Application Notes to prevent the reset of FTDI devices from spurious signals.

Wrongly Marked Components

The two USB line capacitors were replaced with what was presumed to be similar devices. Upon plugging the debugger into the computer an error message was displayed stating that the USB device could not be identified.

USB Signals

To diagnose further the oscilloscope was powered and the two USB signals probed.

USB Signals with Large Capacitors

The capture above shows the signals. Excessive rounding of the waveform usually indicates a high capacitance. 

Removing the new capacitors and verifying their capacitance confirmed that the value on the manufacturer packaging was incorrect.

USB Signals with Small Capacitors

With the capacitors removed the debugger began operating normally. Alternative replacement were fitted. The subsequent capture shown above is more indicative of USB signals.

Monitoring Single Pole Switch

Summary

This post illustrates how a single pole switch contact can be monitored using a microcontroller which provides a pulsing output and corresponding monitor input. Similar to a previous post, multipole switch debounce, a PSoC CY8CKIT-049 42xx development board was utilised with an external switch.

Single Pole Switch Pulsed Output / Input

 

Manufacturers of safety equipment such as Pilz, Leuze and Honeywell use more comprehensive redundancy and self-checking techniques which use a variant of the pulsing output. Additional reading relating to the pulsing implemented by safety equipment manufacturers is available in technical documentation such as that from NHP, Allen-Bradley or even National Instruments to name a few.

The technique implemented in this post is an example for  the hobbyist. For more advanced safety implementation, a dedicated safety PLC or External Device Monitoring (EDM) solution should be considered.

Monitoring
Monitored inputs are commonly found in safety critical components or systems however these are rarely used in hobbyist designs. The hardware used by a hobbyist, as with any device, is prone to mechanical failure or wiring issues. Assuredly providing basic signal monitoring can assist in fault diagnosis. For this blog, shorts between cables carrying signals and power rails can be detected using pulsed signals. Furthermore false activation in such a failure is significantly lessened.

Pulsing Described
In this example pulsing refers to a fixed frequency, series of pulses with a predefined duty cycle. For ease in generating those pulses in an electronic circuit, the shape of the pulse usually represents rapid changes between two potentials as shown below.

Pulsing Signal Example

 

Output Implementation
Regardless of the processor type, implementing a pulsing output is usually a novel task using a timer. For the PSoC processor a PWM component was utilised to generate the pulsing output.

PSoC PWM Component

 

The PWM component was configured to produce a 50% duty cycle output. Shown below is the waveform produced at the output pin (P2_6).

PSoC PWM Component Output

 

Input Implementation
For debouncing and verifying the input pulse, a number of active components were used in the design although there are other solutions which may achieve a similar result.

Debounce and Pulse Detection

 

The input pin (P2_4), which would usually be driven from the pulsed output, is passed through a glitch filter for the purposes of removing any unwanted noise or signal bounce. The filtered signal is then output to two components, an edge detector and a timer.

Using the edge detector a rising edge pulse generates a short pulse to drive the set pin of a SR flip flop. The flip flop output then remains true until the reset input is activated.

The timer is configured so a rising edge starts the timer counting and a falling edge reloads the timer count value. With the timer count value being greater than the input pulse width, the one shot timer is constantly reset when connected to a pulsing signal. When the pulsing signal is removed the timer expires and reset the flip flop.

Timer Configuration

 

If the input signal is not pulsing the SR flip flop may be triggered from a bouncing signal but is subsequently reset. The reset of the flip flop is a result of the timer expiring, caused by the timer not being reloaded on a falling edge.

Input Signal (Pulsing)
Shown in the image below are the typical signals when the pulsing output is first connected to the input.

The yellow trace (CH1) displays the input pin with the 50us high, 50us low signal.

Shown in the pink trace (CH4) is the output of the glitch filter. As the input signal is without any bounce the input pulse passes through glitch filter with the delay defined in the component which in this design was 40us.

When a valid rising edge has been detected after the glitch filter the edge detector generated a short 10us pulse, as shown in the green trace (CH2).

The blue trace (CH3) is the output of the timer compare which is not active due to the pulsing signal being active.

Waveforms for Pulsing Input Signal

Input Signal (Non-Pulsing)
Shown in the image below are the typical signals when a non-pulsing signal is first connected to the input.

The yellow trace (CH1) shows when a voltage was applied to the input.

Some 50us later the glitch filter provides its output as shown in the pink trace (CH4).

A valid rising edge is detected from the glitch filter as shown in the green trace (CH2).

After the rising edge from the glitch filter starts the timer there is no subsequent falling edge to reload the timer. As a result the timer expires, as shown in the blue trace (CH3) causing the flip flop to reset.

Waveforms for Non-Pulsing Input Signal

 

Final Thoughts
The example provided in this blog is by no means ideal, however it is an example of what can be achieved with a smattering of logic components and a timer.

False triggering resulting in a latched output is possible in this example using a non-pulsed signal. Other solutions may benefit from less or no false triggering although the reaction time may be slower. As always, the importance of each factor is part of the design consideration.

On the matter of device resources, the example implementation for the Cypress PSoC requires around 20% of the UDB resources making for heavy device utilisation. Certainly a component such as the glitch filter could be implemented outside the PSoC with passives and a Schmitt trigger.

Downloads
The PSoC Creator 4.2 project for the example in this blog was saved as a minimal archive.

Single Pole Switch Monitoring PSoC Creator 4.2 Project

Multipole switch debouncing PSoC

Summary

This post looks at a solution using PSoC components to debounce a multipole switch. For testing, an industrial roller lever switch from German switch manufacturer Bernstein was used with a Cypress CY8CKIT-049 development board.

Bernstein Switch

Single pole vs Multipole 
Single pole switches and buttons are commonly used in applications which are non-critical, require no redundancy or have no specific safety requirement. Consider examples such as the reset button on the Cypress CY8CKIT-049 development board or the light switch in a house.

The multipole switch usually contains multiple contact options for various industrial applications. The contact options are Normally Open 'NO' and Normally Closed 'NC' with various brake and make, effectively open and close, options. Consider an example such as the changeover switch for an electric railway signal box or the end stop switch on a gantry crane.

Signal Bouncing
Multipole switches may use the same mechanical actuation design as their single pole counterparts which gives rise to similar signal characteristics. One difference however is that the contacts in a multipole switch may not actuate at the same time.

Bernstein Switch PSoC Test Setup

The test setup in the image above shows the connections between the CY8CKIT-049 development board and the Bernstein switch. Both contacts use a 5V DC supply.

Multipole Switch with Bounce

Shown in the capture above are the NO and NC contacts of the Bernstein switch when actuated. No bounce is shown for the NC signal (Yellow channel 1) as it switches OFF and the NO signal (Green channel 2) shows signal bounce for less than 5msec as it switches ON.

To remove the unwanted bounce in this design without using external filtering or other components, the two switch signals were debounced in the PSoC using digital 'components' built from Cypress termed Universal Digital Blocks (UDB).

Simple Multipole Glitch Filter (PSoC)

In the example above the Glitch Filter component was used to debounce the two input signals from the switch. The outputs of these filters was combined to drive the on-board LED. For illustrative purposes the filters were not been combined into a single component with a bus.

The filter component was configured for 20ms for both filter components.

Glitch Filter Configuration

Running the example project in the PSoC development kit produces a clean debounced waveform as shown in the capture below. Note the 20ms delay between input and output waveforms.

Multipole Switch Debounce Turn ON

The connections for channel 1 and 2 to the switch remain the same as the previous capture. The additional connections for Blue channel 3 show the filtered NO signal and the Pink channel 4 shows the NC signal.

Shown below is the turn OFF waveforms.

Multipole Switch Debounce Turn OFF

Fault Blocking
The dual pole switch in this example uses contacts, which in resting condition, are in the opposite state. The addition of another gate and an enable control to the output LED connections provides some fault detection. That is, the two inputs must be in opposite states for the LED to be active.

Simple Multipole Glitch Filter with Fault Detection (PSoC)

Final Thoughts
Debouncing multipole switches with a PSoC can be achieved using only a digital solution (UDB). The filter components used in the solution require no code however some 25% of the available resources are utilised. Where practical, multiple switches with multipole contacts could be debounced using a suitable multiplexer.

Downloads
The PSoC Creator 4.2 project below with the glitch filters was saved as a minimal archive.

Multipole Checker PSoC Creator 4.2 Project

ARP -SCAN for MAC Address Lookup

Summary

This post highlights how the arp (Win) or arp-scan (Linux) commands can be used in conjunction with online MAC address lookup tools, to assist in hardware identification of Ethernet devices.

Predicament
For a software development project a boxed cluster of Single Board Computers (SBC) was provided. The SBC cluster contained systems configured with static and dynamic IP addressing. No issue I mused, each SBC could be powered individually, the SBC that needed to be upgraded could then be identified. The real issue then presented itself, the cluster was boxed hardware and could not be opened and individual boards could not be powered or unpowered. One of the solutions that came to mind was the sometimes overlooked ARP command.

ARP Command (Windows)
Using ARP in the Windows command line may not be the most operator friendly solution, especially if a GUI based application is more your flavour. There are plenty of Windows applications such as the well-known Angry IP Scanner, Nmap or Free IP Scanner which will do a similar task. Some of these applications detail the OEM or hardware manufacturer in the scan results.

For testing with ARP, the SBC box was powered and networked directly to a development computer.

The arp -a command was issued from the Windows command line.

ARP Results

A doctored copy of the results from the arp are shown above. A few dynamic devices were listed. 

The first six characters of the MAC address were used to identify the vendors.


ARP Scan Command (Linux)
The arp-scan command used in Linux terminal produces similar results, usually including the hardware vendor.

ARP Scan Results

MAC Lookup
For this SBC project the AskApache website was utilised for identification of the hardware vendor using the MAC addresses. A Google search will throw up numerous sites with similar search functionality, such as MAC Vendor Lookup.

On the AskApache site, the MAC address starting with b8 yielded the target SBC.

AskApache MAC Address Lookup

Results from the website show the target SBC was a Raspberry Pi.

AskApache MAC Address Lookup Result

Using the command line serves as handy reminder to the tools available in most operating systems.

Diode charging supercap solar battery

Summary

This post investigates the ideal diode my Maxim Integrated, part MAX40203, as a possible replacement for low forward voltage diodes.

Example Diode SuperCapacitor Charger

Forward Voltage
When deciding on a suitable diode for a circuit, such as the basic diode supercapacitor charger shown above, a Schottky is a usual choice. The lower forward voltage of the Schottky diode is more beneficial to ensure that the load operating voltage is closer to the supply voltage. There is also the benefit of lower losses as a result of the lower forward voltage.

Some examples of different Schottky diodes include the Toshiba CUS10S30 with a voltage drop of 230mV at 100mA, the Panasonic DB2S30800L has a drop of 420mV at 100mA or the Nexperia PMEG10020 with a drop of 500mV at 100mA.

Ideal Diode
Released in the middle of 2018 the MAX40203 is targeted as a replacement for the Schottky diode and it does not disappoint in regards to forward voltage.

MAX40203 - Courtesy Maxim Integrated

Diode Testing (Reverse leakage)
To begin the tests, reverse leakage was measured. The MAX40203 was bench tested against two general Schottky diodes, the Nexperia PMEG10020 and an ST STPS2L40U. To perform tests with the Schottky diodes, the devices were connected in reverse bias with a 100k resistor. The MAX40203 leakage test was performed with 100k resistors to measure leakage through Anode and GND as shown in the device datasheet.

MAX40203 Leakage - Courtesy Maxim Integrated

Voltage measurements were made across the resistor as the supply voltage was increased in one volt increments. Since the maximum operating voltage of the Maxim part is 5.5VDC the test voltage was limited to 5V.

Reverse leakage Schottky vs MAX40203

Graphing the above table of results was certainly not necessary although illustrates the leakage difference between devices. Note the reverse leakage on the PMEG diode is magnitudes lower than the Maxim part. At 5V DC the PMEG diode leakage was 30nA compared to the 207nA for the Maxim part.

Graphed reverse leakage Schottky vs MAX40203

Maxim Part Enable
The MAX40203 datasheet does state that the Enable pin should be pulled high however it also states that there is an internal weak pullup.

Reverse leakage tests were performed with only the Maxim device and the leakage through the Anode was measured. Once again the power supply voltage was increase in a range of 1C to 5V DC.

MAX40203 Reverse Leakage Test Setup

These tests were to replicate a circuit, such as the example above, using a solar panel.

MAX40203 Enable On/Off Reverse Leakage Measurements

Some difference in measurements was noted when the Enable input was connected to the supply. 

Diode Testing (Forward Voltage)
The MAX40203 was subsequently tested with the diodes from the previous test in forward bias. Resistive loads were changed with a fixed supply voltage of 5V DC to achieve test currents from 1mA to 1A.

Forward Voltage Schottky vs MAX40203

Graphing the above data illustrates the usual curves for diode forward voltage with the almost linear voltage drop against forward current across the MAX40203 internal FET.

Graphed forward voltage Schottky vs MAX40203

MAX40203 Load Testing
Measurements were taken to verify the forward voltage of the Maxim part against the device datasheet to a current of 1A. These were similar to the specifications for a room temperature of 25°C and not recorded.

For the final set of tests the MAX40203 was powered up and down with varying resistive loads with a fixed supply voltage of 5V DC. A repurposed board served as the carrier for the test device.

MAX40203 Test Setup

Tests were performed with various wirewound resistors and initially the power supply current limited to 1A. Final tests were conducted with a current limit at 2A.

MAX40203 Load Test Results

The first three tests shown in the results above were relatively normal. For the last test with a 0.1Ω resistor the power supply current limit was increased to 2A. After power was supplied to the device, it warmed considerably then the current reduced to around 180mA so power to the device was removed. The internal protection was suspected to be active. After cooling the device did not output the supply voltage of 5V, instead it was around 4V DC. Furthermore the quiescent current was 32mA which had also increased.

MAX40203 Short Testing
A new MAX40203 was placed on a new test board as the device from the prior test was suspect. In the last test the output of the device was shorted to 0V to test the short circuit protection.

After applying power the supply showed that the device was passing and holding 1A. The current limit on the supply was then increased to 2A, still ok, then 3A; after 3A the current dropped to several hundred milliamps. The device was allowed to cool but never returned to normal operation.

Comments
Testing showed that the low forward voltage drop of the MAX40203 makes it ideal for specific charging applications. For a charging current of 100mA the test Schottky's 481mV was over ten times larger than the Maxim devices 35mV.

Conversely the reverse leakage of the Schottky 30nA was significantly lower than the 316nA for the Maxim device.

Testing of the Maxim device short circuit protection was incomplete and would warrant additional further review.

Altium Unable to cast COM object type

Summary

This blog describes how Altium users can resolve the "Unable to cast COM object type" which can be caused as a result of installing / uninstalling Office (32 bit) software together with Office (64 bit).

Altium Dialog Message

The "Unable to cast COM object type" message can be displayed when there is a requirement for Altium to use Excel libraries, such as generating a Bill of Materials (BOM).

Altium Dialog Message

The message identifies a registry entry which is located at HKCR\TypeLib.

Causes

One Microsoft blog explains that the message may be displayed within Office applications when a mixture of Office 32/64 bit applications are installed on the same machine. The Microsoft blog suggests removing the HKCR key 

00020813-0000-0000-C000-000000000046 although applying this change with Altium did not resolve the issue.

Registry 00020813-0000-0000-C000-000000000046 Entry

Office Repair

To remedy the issue in Altium, an Office Repair was required. With the Altium application closed, may not be necessary, the Apps and Features application was opened from the 'Start' menu and the relevant Office installation selected.

Windows 10 Apps and Features

The Modify button was selected followed by the Quick Repair.

Office Quick Repair

Quick Repair Started

In a few minutes the repair finished.

Quick Repair Finished

After the repair Altium was launched and a BOM generated without any issues.

Other Altium Messages

While replicating the "Unable to cast COM object type" Altium message for this blog, the process of installing 32 bit Office software did interfere with another Microsoft redistributable. This resulted in Altium displaying a dialog detailing the missing redistributable. Fortunately the Altium dialog provided a link to the Microsoft website where an installation of the redistributable resolved the issue.