Allegro ART Gerber to Altium PCB

Summary

This post provides an alternate method for importing Allegro Gerber data for use in Altium Designer PCB files. The intention of this method is to utilise specific information such as board shape, component mounting location or a specific feature on the Gerber by using DXF export and imports.

For those seeking a full board import into Altium, there are a few web threads detailing possible solutions, such as Import Gerber files into Altium thread on Stack Exchange.

ART Files
Gerber files generated by the Cadence Allegro PCB software contain an identification header inside the file. Using a text viewer to open files with the .ART extension, yields easy identification. The capture below shows a portion of the information listed in Gerber file named Top.ART. The Gerber file was used from the Cypress CY8CPROTO-063-BLE PSoC 6 BLE Prototyping Kit Hardware pack.

G04 ================== begin FILE IDENTIFICATION RECORD ==================*
G04 Layout Name:  N:/PCB_HOME/60527-01_03-CYSTAMP-063/Artwork/600-60527-01_03.brd*
G04 Film Name:    TOP*
G04 File Format:  Gerber RS274X*
G04 File Origin:  Cadence Allegro 16.6-2015-S108*
G04 Origin Date:  Mon Oct 08 10:45:40 2018*
G04 *
G04 Layer:  DRAWING FORMAT/FAB_FILM*
G04 Layer:  PACKAGE GEOMETRY/PLATING_BAR_TOP*
G04 Layer:  PACKAGE GEOMETRY/SHORT_TOP*
G04 Layer:  ETCH/TOP*
G04 Layer:  PIN/TOP*
G04 Layer:  VIA CLASS/TOP*
G04 Layer:  BOARD GEOMETRY/OUTLINE*
G04 *
G04 Offset:    (0.00 0.00)*
G04 Mirror:    No*
G04 Mode:      Positive*
G04 Rotation:  0*
G04 FullContactRelief:  No*
G04 UndefLineWidth:     5.00*
G04 ================== end FILE IDENTIFICATION RECORD ====================*

Altium Camtastic
The Altium Designer CAMtastic tool is by default capable of opening Allegro Gerber files with the .ART extension. 

Allegro ART files in Cypress CY8PROTO-063 Kit Hardware Pack

To temporarily associate these files to Altium Designer, these can be renamed to .CAM files.

Renamed Allegro ART files to CAM in Cypress CY8PROTO-063 Kit Hardware Pack

Double clicking the CAM files then results in Altium opening the files directly in CAMtastic.

PCB Dimensions
For the example in this blog using the Cypress 063 Gerbers, the detail2.cam file contained important information for verifying the Gerber, namely the size of the PCB.

CY8PROTO-063 Detal2.cam Extract PCB Dimensions

The PCB dimensions or event some known measurement was important because when the required CAM file was exported as DXF using CAMtastic, the correct scaling must be applied during to the DXF file import into Altium PCB.

File Export
With known measurements from the original Gerber the top assembly file, assy_t.cam, was chosen to illustrate the method of exporting.

CY8PROTO-063 Assy_t.cam

With the assy_t.cam file open in CAMtastic, the Export DXF command was initiated.

There are options in the CAMtastic DXF export window. The options allow selection of multiple layers, if used, and object fill types. For this export the fill feature was selected. 

Exporting CAM File in Altium

Lastly the location of the exported file was selected.

Exported CAM File Location

File Import
With a blank PCB file open in Altium, the Import DXF command was initiated.

Importing DXF File Location

After selecting the previously exported DXF file, the Altium Import window displayed the DXF scaling option. For this import the scaling was changed to suit imperial units used in the Cypress Gerber.

Importing DXF File Scaling

Selecting 'inch' under the Scale section ensured correct import scaling. For other file the scaling option may need to be adjusted. The adjustment would depend on the source file measurement units.

If required, the imported DXF file can be placed at a specific location on the PCB file which is useful for existing PCB designs.

Shown below is a capture of the imported DXF file displayed in Altium PCB.

Imported DXF into Altium PCB

Verifying File Import
At least two key measurements were verified on the imported file, one horizontal and the other vertical.

The pin headers used on the Cypress board with a 0.1" pitch provided a simple measurement to verify the horizontal distance was scaled correctly.

Altium Imported DXF Verify Connector Spacing

For the second verification, the PCB dimension was measured and compared against the original measurement provided in detail2.cam, 1052mil.

Altium Imported DXF Verify Board Dimension

Final Thoughts
The method proposed in this blog yields marvelous results, however the import process is not always perfect. This means verification of the imported DXF file is required. As an example, the large track seen under the KitProg processor should be the exposed pad for the PSoC.

Altium Import DXF Issues

In instances where several snippets of board information are required from an Allegro Gerber (project), which may include dimensions, shape, cutouts, mounting holes to component mounting locations, the method in this blog may reduce the time required to create the same board or features from scratch in Altium.

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