Here is a video I made for Getting Started debugging a PSoC1 project.  This is a two part series and in the first part, I have covered the hardware requirements.  The second part that covers the PSoC Designer part of the debugging will follow soon.

Application note "AN73212 - Debugging with PSoC1" provides all the information required to debug a PSoC1 project.

Happy Debugging!

I made a video showing how a precision full wave rectifier may be created in PSoC 1 by configuring a Switched Capacitor block as a modulator.

Execercise to the User:

1. Set the ASign parameter of the SCBlock to "Positive" and observe the result
2. Set the ACap value to 8, 24 and 31 and observe the result.
3. Set the Polarity of the Comparator to Negative and observe the result.

For more details about Switched Capacitor blocks, refer below application note.

AN2041 - Understanding PSoC 1 Switched Capacitor Analog Blocks

The project file for the video may be found below.

PSoC Designer Project - Precision Rectifier

With its flexibile Analog and Digital resources, PSoC 1 is a very strong candidate for Thermal Management applications.  The PSoC can measure temperature from various types of temperature sensors like Diodes, Analog sensors, I2C based sensors, PWM based sensors and 1 wire sensors.  PSoC can implement a closed fan controller function by using 8 or 16 bit PWMs to drive fans and 16 bit timer to measure speed of the fan from the tach signal provided by some fans.

This video shows how a thermal managament application may be implemented using PSoC 1. 

More information on the kits used may be found in the below links.

CY8CKIT-001 PSoC Platform Development Kit

CY8CKIT-036 Thermal Management Expansion Board

The project used in the demo may be found below.

PSoC Designer Project - Thermal Management

In today s world of mixed-signal systems, many applications require analog quantities including but not limited to voltage, current, temperature, pressure, acceleration, pH, flow, and ECG to be measured and processed. The field of uses ranges from lab and medical equipment operating in controlled environments to industrial equipment running under harsh operating conditions. The analog signals to be measured can range from a few micro-volts in ECG systems to thousands of volts in electricity generation plants.

Unfortunately, there is no such thing as an ideal converter in the real world, where systems have to contend with errors that are introduced into the system and affect the ADC s output. The most important errors are offset and gain errors.  

Refer graph below.  This is a plot of an 8 bit ADC with a range of +2.5V.  X axis denotes the input voltage and Y axis denotes the ADC counts.  The blue line is the ideal ADC output. The red line is the actual ADC output.  Notice the actual output is shifted from the ideal.  This shift is called the offset error.

 
All operational amplifiers have a finite offset voltage at the input.  This offset voltage gets added to the input signal, gets amplified by the amplifier s gain and manifests at the output.  Apart from the amplifier stage, the ADC also has its own offset voltage which adds to the system error.  Offset error is an additive error and can be easily removed from the system.

Graph below is the plot of the same 8 bit ADC with the +2.5V range.  Note that the slope of the actual output is now different from the slope of the ideal output.  This shift in slope is called the gain error.

 
These errors may be removed from a system using many calibration techniques like:

• Correlated Double Sampling
• Two-point Calibration
• Gain calibration using external reference. 

PSoC 1, with its flexible analog resources and routing makes it very easy to implement all of the above calibration techniques.  Depending upon the application, one or more of these methods can be combined to achieve maximum accuracy.
Recently, I, with my friend and colleague Pushek Madaan, wrote an article on this topic in EETimes.  The article may be found in the following link.

Calibrating Amplifiers and ADCs in SoCs

The article in PDF format and the PSoC Designer projects for the Correlated Double Sampling and Two-point calibration technique are attached here in this post.

Happy Signal Conditioning!!

Calibrating Amplifiers and ADCs in SoCs - PDF Article

PSoC Designer Project - CDS Calibration

PSoC Designer Project - Two Point Calibration

Many times in applications using the Watchdog timer, there may be a requirement to detect if a reset occurred due to Watchdog or POR / XRES and the application may either start fresh in case of POR / XRES or recover and start executing from the state when the watchdog reset occurred.

DETECT THE SOURCE OF RESET

The first requirement is to find out the source of reset.  This can be done by checking the WDRS bit in the CPU_SCR0 register.  This bit is set in case of a watchdog reset event.  The below code in the beginning of main.c can be used.

if(CPU_SCR0 & CPU_SCR0_WDRS_MASK)
{
    // Reset is due to Watchdog
}

PRESERVE GLOBAL VARIABLES

In order to recover from a watchdog reset and resume the application, it is necessary that the Global variables be preserved when the watchdog reset occurs.  This can be done by setting the IRAMDIS bit in the CPU_SCR1 register.  When this bit is set, all the cells marked “??” in the below table are preserved during a Watchdog reset (taken from Technical Reference Manual Section 3).

Add the below code in the beginning of main.c to preserve the content of these RAM locations.

CPU_SRC1 |= CPU_SCR1_IRAMDIS;

There are a few more points to consider in the usage of the IRAMDIS bit.

When using C as the programming language, the boot.asm sets all the global variables to 0x00.  This has to be disabled.  The boot.asm has a constant “C_LANGUAGE_SUPPORT”, in the beginning.  Set this constant to 0 to disable the global initialization.  Change the value of the constant in boot.tpl in the project folder, save boot.tpl and Generate Application.  As “boot.asm” is generated from boot.tpl, the change will now reflect in boot.asm.

Only RAM locations from 0x03 are preserved when IRAMDIS is set.  Locations 0x00, 0x01 and 0x02 will still get reset.  So, no global variable should be placed in these locations.  This is highly unlikely to happen though.  By default all the global variables are placed in the area “bss”, which follows the areas “virtual_registers” (used by the compiler to store virtual registers) and “InterruptRAM” (used for user module variables).  These areas will mostly occupy the locations 0x00 to 0x02 and more.  In the remote possibility that both these areas are empty and “bss” starts from 0x00, you will have to create a custom area and place it at a location above 0x02, and place all the locals in this area.  More details about placing globals in the desired RAM location can be found in this KB article.  The location of the RAM areas can be checked in the project map file (with .mp extension) in the “output” folder in the project.

Only RAM Page-0 gets cleared by resets and need be preserved by IRAMDIS bit.  In devices with more than 256 bytes of RAM, Page-1 and above are not changed by a watchdog reset.  So, locating all the global variables in RAM Page-1 or above will not require setting the IRAMDIS bit.

ADDING SOME MORE RELIABILITY

What if the event that caused the watchdog reset (RF interference or a power supply spike), also corrupted some of the global variables?  We need to be able to detect this and start the program normally.  Create a checksum of all the global variables that are critical to the program and store it in another variable.  Every time one of the global variables is updated, update the checksum as well.  On watchdog reset, calculate the checksum of all the global variables and compare it with the checksum variable.  If the calculated value matches the stored value, then the global variables are intact and the process may proceed to recover from the last state.  If the checksum values do not match, then the process can start from beginning.

The code in the beginning of main.c will look something like this:

CPU_SRC1 |= CPU_SCR1_IRAMDIS; // Set the IRAMDIS bit

if(CPU_SCR0 & CPU_SCR0_WDRS_MASK) // Check the source of reset
{
   Reset is due to Watchdog.
   Calculate the checksum of the global variables.
   If Checksum matches:
      Resume from the last state
   Else
      Start application from beginning
}
else
{
   Reset is due to POR / XRES. Start the application from beginning
}