This is one of the most common problems users face with an ADC while debugging.  The ADC result is always corrupt after you hit a breakpoint in the program.  Why does this happen?

Let us take a look at how an ADC is created in a PSoC.  Except for the SAR6 ADC, which uses a single Analog block, all other PSoC ADCs (ADCINC, ADCINCVR, DelSig, DELSIG8/11 etc) are a combination of Analog and Digital blocks.  The block diagram of an ADCINC12 is shown below.

An SC Bloc configured as an analog modulator converts the input analog signal into a digital bit stream, whose On Time / Off Time ratio is proportional to the input signal.

0V - 50% on, 50% off
+Vref/2 - 75% on, 25% off
-Vref/2 - 25% on, 75% off
…and so on.

A counter integrates this bit stream for a fixed integration window set by a timer, and at the end of the integration cycle, the CPU reads the value in the Counter which is the ADC result.  The hardware implementation of the digital integrator is different in different ADCs, but the concept is the same.  For the ADC result to be correct, the CPU has to read the value from the counter exactly at the end of the integration cycle.  If it fails to do so, the counter will continue counting the bit stream and will result in an incorrect ADC result. 

When a break point is hit while debugging, the CPU halts.  But the analog and digital blocks continue to run in the background and the counter would be counting many ADC integration cycles.  So, naturally when CPU resumes execution after the breakpoint, the value read from the counter would be wrong.  If you are debugging some other section of the program that does not have any dependency on the ADC result, then just ignore this.  When you program the device and the program runs continuously, the ADC result would be correct.  If you are debugging a section that depends on the accuracy of the ADC result, then here are some things that you can do.

1.    As the program is running, dynamically set a breakpoint after the instruction that reads the ADC result, by left clicking on the left margin of the code window (left side of the Line number).  When the program halts, the value read from the ADC would be correct.  Now clear the breakpoint, run the program and dynamically place the breakpoint again.

2.    Use the following code.

      for(i=0; i<2; i++)
      {
         while(ADC_fIsDataAvailable() == 0);
         ADCResult = ADC_iGetData();
         ADC_ClearFlag();
      }
      asm("nop");  ---> Place breakpoint here

In the above code, the “for” loop runs two cycles.  The ADC result read during the first iteration of the for loop is corrupt. The second ADC result is clean.  So, when the break point is hit, the ADC result will always be correct.  Remember, when using a Delta sigma ADC, the for loop should be written for 3 cycles, so that the first 2 results are dropped.  For other incremental ADCs, dropping one result is enough.

3.    Instead of running the ADC in continuous sampling mode, run it in single sample mode.

      ADC_GetSamples(1);
      while(ADC_fIsDataAvailable() == 0);
      ADCResult = ADC_iGetDataClearFlag();
      asm("nop");  --------------------------> Break point here

When the ADC is run in single sample mode, the ADC conversion starts when the "ADC_GetSamples" function is called.  On end of conversion, the counter and timer are stopped.  They will be started only when the ADC_GetSamples function is called.  Thus, the ADC result would never be corrupt.  This applies only to incremental ADCs and can not be used for Delta sigma ADCs.

Happy debugging!!

At last, after a long wait and lots of suspense, PSoC3 and PSoC5 have been officially announced.  I sat down to do my first project, measure an analog input signal with an ADC, pass the result through an FIR filter, convert to voltage and display on the LCD.  Or should I call this is my pseudo first project as I have been in some of the PSoC3 training sessions and had worked with some very early versions of the PSoC Creator.

The download and installation of the PSoC Programmer and PSoC Creator went quite smooth without a hitch.  But for some reason, the registration happened only after a few retries and “Invalid user name and password” errors. 

Working with the PSoC Creator is fun.  The Creator looks like a hybrid of PSoC Designer and OrCAD.  In PSoC Designer, you place user modules in the correct analog/digital blocks, use the Analog / Digital interconnect nets to connect between blocks and pins etc. In the Creator, you draw a schematic instead.

You place the required resources, connect them using wires, and configure the pin outs in the pin configuration window.  Voila, the device is ready.  Writing code is similar to PSoC Designer where you use the Library API of the components - the user modules of PSoC Creator.  If you have worked with PSoC Designer, it should be quite easy to learn PSoC Creator.  Once I had the schematic and the pin configurations done, writing code was quite simple and I was able to get the project working in less than 20 minutes.

Overall, my pseudo-first experience with the PSoC Creator was great.  I relived the thrill of working with PSoC Designer version 1.31, back in 2002.  There is so much to explore - New IDE, new processor cores, new compiler, new debugger…  I am loving it.

Hello World.  PSoC3, PSoC5 and the Creator are here and are here to stay!!!

One another passion I have other than PSoC is bird watching and photography.  I enjoy trekking into jungles or waterbodies during week ends with my Canon DSLR camera and 300mm telephoto lens and shoot birds (with my camera ofcourse).  It is a great experience seeing all those colorful birds in their natural habitat and is a great stress buster.  Here are some photos from my collection.

Spot Billed Pelican in Flight - Shot at Karaji lake,Mysore, Karnataka, India, a waterbody thousands of migratory birds come from all over the world every year.  It took 1/2 an hour and 10's of shots to ge this perfect photo of the majestic bird in flight.  Due to dwindling habitat of water bodies, this bird is now classified as "Near Threatened"

Australian Ibis - Resting after flight - Shot at Karanji Lake, Mysore

Yellow billed babbler - This is a very noisy bird and is always found in groups of 7 to 10.  Also called as 7 sisters.  When I was showing this photo to my boss, he observed that the bark that the bird is sitting looks like a snake's head.

Rose Ringed Parakeet - I shot this in Birla Institute of Technology in Pilani Rajasthan which I had visited to conduct a PSoC workshop.  This bird patiently posed for me till I got the perfect shot.

Red Wattled Lapwing - Shot at Birla Institute of Technology, Pilani.  This bird which is considered to be very shy always tries to keep distance from human beings.  But surprisingly, this bird came quiet close so that I could get a very clear shot.

Send me your comments to graa@cypress.com.

“Can’t Acquire Device”, “Verify Failed”, “Checksum Error”, “Device not in database”.  These are some of the errors the PSoC Programmer throws at users when programming a PSoC In System.  When you dedicate the P1[0] and P1[1] pins exclusively for ISSP, there usually is no problem in programming the chip on board.  But the trouble begins when you share P1[0] and P1[1] for other functions.

The most commonly encountered problem in ISSP is when P1[0] and P1[1] are used for I2C.  In programming mode, both SCLK and SDATA pins of the PSoC are configured in Pull Down mode with an internal 5.6K pull down resistor.  There is no issue with the SCLK line as the programmer always drives the SCLK line.  But things are different with the SDATA line.  When the programmer is reading information (like device ID, verify, checksum etc), the PSoC has to drive the SDATA line.  The external I2C pull up resistor forms a potential divider with the internal pull down resistor and does not allow the PSoC to drive LOW on the SDATA line.  This results in a plethora of errors mentioned before.

There are various approaches to solve this problem.

• The first and the best “DO NOT USE THE ISSP PINS AS I2C”.  Use P1[5] and P1[7] instead.
• If you are compelled to use the ISSP lines for I2C as well - like when you use a CY3240 I2C USB bridge on the ISSP header for debugging - try isolating the I2C pull up resistors from the SDATA line using a jumper when programming.
• If you cannot implement the above because of board space problem, add an external load resistor on SDATA line to GND on the ISSP Programmer.  This resistor will apply in parallel with the internal pull down resistor of the PSoC and will reduce the effective resistance and reduce the potential divider effect.  The value of this external resistor will depend on the value of the I2C pull up resistors.  The criteria is that when PSoC drives a LOW on the pin, the potential divider should drive a voltage less than VIL level of the programmer (less than 0.6V should be fine).  Usually a value of 500 ohms to 1K should solve the problem.  Below is a picture on a hack on MiniProg to add the 1K pull down resistor based on a post in psocdeveloper forums a few years back.  As I could not locate the post, I had to risk one of my own programmers.

If the SDATA or SCLK line is configured as an input pin and is driven by a low impedance source, this will load the programmer.   So, always use the SDATA and SCLK pins as output pins driving a high impedance load.  This will prevent the programmer getting loaded.

Do not use direct capacitive loads on the ISSP lines as this will affect the rise and fall times of the programming signals and will affect programming.

Check out AN2014.  This application note provides some details about the ISSP programming, pin loading etc.

Happy ISSP Programming!!

Hi Everybody,

I am M. Ganesh Raaja and I work for Cypress Semiconductor as a Principal Applications Engineer.  I completed my Diploma in Electronics and Communications Engineering in 1992 and since then have worked in various jobs like servicing computer peripherals (huge floppy drives, huge hard disks, huge line printers etc), design engineer in a power electronics company designing UPS, design engineer in an Instrumentation company designing industrial sensors and having my own company developing custom industrial automation products using 8051 controllers. 

In 2002, I came across PSoC when searching for a microcontroller for an advanced panel meter design.  You could call it love at first sight.  Though that panel meter design never went through, it completely changed my life and brought me and PSoC together.  I bought the CY3205 development kit with the ICE-4000 emulator and started playing around with PSoC.  Since then I have been addicted to this device and have been doing various PSoC related things like writing application notes, conducting PSoC seminars for customers, writing user module code, training engineers on PSoC etc.  Another addiction I have is posting regularly in PSoC Developer forums as “graaja”.  In the past 6 months though, my activity there has reduced due to various reasons, which I plan to restart soon.

In this blog I would like to share with you many of my experiences with PSoC, tips and tricks of using PSoC, interesting articles I come across on PSoC and microcontrollers in general etc.

Welcome.  Let’s Talk PSoC!!