PSoC™ 5, 3 & 1 Forum Discussions

One of the more powerful aspects of PSoC 3 and PSoC 5 is the ability to use components that encapsulate both hardware and software functionality.  Cypress provides a large library of the most common components that you might need (I2C, UART, DAC), but there is no end to the possible components that PSoC 3 and PSoC 5 can support.  The Creator platform allows you to develop and use your own components using the same methodology as Cypress engineers.

There are 3 levels of components that a user might want to develop:

    
1. Schematic Component
    
2. Verilog Component
    
3. Datapath Component
   

Each level gets progressively more involved and more powerful.  A schematic based component provides a hierarchical schematic capability.  Here you can combine any of the components in the current library and also encapsulate the APIs that go with that combination.  With a Verilog based component you have the ability to pull in more complex unique digital content and take direct advantage of the PLDs built into PSoC 3 and 5.  The capability to do either Schematic or Verilog based components is in Creator today.  The third level, datapath based components, adds to a Verilog component the usage of the datapath resources in PSoC 3 and 5.  With datapaths you can create denser designs and more flexibily communicate between your hardware component and the CPU. 

In order to get you started on the right track, several training classes are developed that include:

    
• Video
    
• Slides
    
• Example Projects
   

They are all posted on the Cypress website under the Design Support tab, then Technical Training, then On-Demand Training, or you can skip directly there with the following links:

    
• PSoC Creator 110: Schematic Components 
    
• PSoC Creator 111: Component Parameters 
    
• PSoC Creator 112: Introduction to Component API Generation 
    
• PSoC Creator 113: PLD Based Verilog Components
   

Many of you may know that both PSoC1 and PSoC3/5 devices have PGAs (Programmable Gain Amplifiers).  These are handy devices allowing you to either select the system gain during design time or during run time.  The gain for these PGAs is controlled by calling one of the API function calls.  Sometimes it would be nice to be able to control the PGA's gain with a digital signal.  With PSoC 3 and 5, there is a way to do this by making use of the handy internal opamps.  There are a couple of ways to do this using different combinations of pins and analog muxes. 

This first option is the simplest, using the internal opamp, a couple of external resistors, and some GPIO pins.  If the signal you want to amplify is referenced to Vss, you can use GPIO pins in the open-drain, drive low mode to select one of N resistors.  The diagram below shows an example of how to use three GPIO pins and four external resistors to provide eight selectable gain combinations.  The LUT (Look Up Table) controls the the gain selection by what ever means that is required by your application.

Another option is to use a hardware mux to select the feedback resistor.  This allows you to select a reference other than Vss.  In the diagram below, the VDAC8 is used to generate the reference voltage which is then buffered with another opamp.  The disadvantage for this design, is that to maintain gain accuracy the resistors should be as large as possible to wash out the affect of the analog mux switch resistance.  Each analog switch in the hardware analog mux is about 200 ohms, so the external resistors should be above 10K or more. The gain for this option is the same as the first, it provides 2^N gain combinations where N is the number of pins and resistors used for gain control.

A third topology eliminates the issue with switch resistance.  The analog mux is used to select the tap point along a string of external series resistors.  Since the current through the mux switches is just that of the opamp input, the 200 ohm switch resistance can be ignored.  The disadvantage, is that one pin is required for each gain setting you want to select, therefore using more pins.  As with the other two options the gain can be controlled purely with digital signals.

 

If we add a window comparator to one of theses examples, a simple AGC (Automatic Gain Control) can be implemented.  The LUT in this example  uses the comparator outputs to determine if the gain should be increased, decreased, or remained the same.

Many of you may know that both PSoC1 and PSoC3/5 devices have PGAs (Programmable Gain Amplifiers).  These are handy devices allowing you to either select the system gain during design time or during run time.  The gain for these PGAs is controlled by calling one of the API function calls.  Sometimes it would be nice to be able to control the PGA's gain with a digital signal.  With PSoC 3 and 5, there is a way to do this by making use of the handy internal opamps.  There are a couple of ways to do this using different combinations of pins and analog muxes. 

This first option is the simplest, using the internal opamp, a couple of external resistors, and some GPIO pins.  If the signal you want to amplify is referenced to Vss, you can use GPIO pins in the open-drain, drive low mode to select one of N resistors.  The diagram below shows an example of how to use three GPIO pins and four external resistors to provide eight selectable gain combinations.  The LUT (Look Up Table) controls the the gain selection by what ever means that is required by your application.

Another option is to use a hardware mux to select the feedback resistor.  This allows you to select a reference other than Vss.  In the diagram below, the VDAC8 is used to generate the reference voltage which is then buffered with another opamp.  The disadvantage for this design, is that to maintain gain accuracy the resistors should be as large as possible to wash out the affect of the analog mux switch resistance.  Each analog switch in the hardware analog mux is about 200 ohms, so the external resistors should be above 10K or more. The gain for this option is the same as the first, it provides 2^N gain combinations where N is the number of pins and resistors used for gain control.

A third topology eliminates the issue with switch resistance.  The analog mux is used to select the tap point along a string of external series resistors.  Since the current through the mux switches is just that of the opamp input, the 200 ohm switch resistance can be ignored.  The disadvantage, is that one pin is required for each gain setting you want to select, therefore using more pins.  As with the other two options the gain can be controlled purely with digital signals.

 

If we add a window comparator to one of theses examples, a simple AGC (Automatic Gain Control) can be implemented.  The LUT in this example  uses the comparator outputs to determine if the gain should be increased, decreased, or remained the same.

This blog post tells you how to observe memory locations in the debugger watch window. This is useful if you want to group together and view separate memory locations that are linked by functionality such as DAC configuration, DAC routing and DAC trim.

To observe memory in the XDATA space, use the following in the watch window: 

*((char*)0x01yyy)

Where YYYY is a 2 byte address. This limits the addressable range for XDATA to 64KB. The char designator restricts it to a single byte, which for most debugging purposes is sufficient.

*Note: There are no spaces in the name.

Other observable memory locations:

The address spaces are limited based on address type through the watch window (Keil limit), and everything must be addressed via the 24 bit address.

XDATA: 0x01YYYY    64k limit

DATA:  0x0000YY    128 byte limit

CODE:  0xFFYYYY    64k limit

PDATA: 0xFE00YY    256 byte limit

Other types: Char is not the only allowable type. For larger values (16 and 32 bit) you can also use int and long:

*((int*)0x01YYYY)

*((long*)0x01YYYY)

Be aware though, Keil is a big endian compiler, so it will interpret memory differently than if you read it out of the memory window. For example:

In the memory map:

0x7000   0x7001   0x7002    0x7003

FE           00            00             1F

The result of the watch window:

Watch window expressions:

You can also create interesting expressions in the watch window:

In the memory map:
0x4690    0x4691
77        02

(int)(*((char*)0x014690)+(*((char*)0x014691)<<8))

This generates the following value -> 0x0277

   
For PSoC 5 (GCC), there are no memory restrictions for PSoC 5 so the entire register space can be accessed in the debugger.

The same techniques apply for PSoC 5 when setting up watch variables for memory locations, although the compiler is little endian oriented, so the int and long values will look different from PSoC 3 to PSoC 5 for the same value:

In the memory map:
0x7000    0x7001    0x7002     0x7003
FE        00        00         07

The result of the watch window:

 Quick Reference (PSoC 3):

XDATA: *((char*)0x01YYYY)

*Limited to 64 KB, no spaces in name

CODE: *((char*)0xFFYYYY)

*Limited to 64 KB, no spaces in name

DATA: *((char*)0x0000YY)

*Limited to 128 B, no spaces in name


Quick Reference (PSoC 5):

ALL MEMORY: *((char*)0xYYYYYYYY)


* no spaces in name

How to prevent unwanted DMA transactions after enabling a DMA channel with queued transaction requests.

Summary:
If a disabled DMA channel receives a request to perform a transfer, the request will be queued up similar to a pending interrupt.  When the channel is enabled, the pending transfer request will be executed, resulting in a transaction that may not be desired.

The workaround is to queue up a “terminate channel” request.  This request takes precedence over the transfer request.  As soon as the channel is enabled, the terminate request is executed instead of the transfer request.  This clears the pending transfer requests and disables the channel.  The channel must be re-enabled afterward to function as intended.

Details:
This problem was discovered when an ADC End Of Conversion (EOC) was connected to the DMA ReQuest (DRQ) terminal of a DMA channel.  The DMA channel was only really needed during a brief high speed sampling window.  The ADC would be used normally other times, with software requesting a start of conversion and the "conversion done" bit being polled by the CPU to determine when the conversion was complete.

It was observed that when the ADC was disabled and the DMA channel was turned on (enabled), a sample would mysteriously appear in RAM.  This was occurring even though it was guaranteed that the EOC signal was not asserted when the channel was enabled.

It was determined that when the ADC was used normally, the EOC was asserting the DRQ of the disabled DMA channel. This request was remembered by the DMA channel, even though the DMA channel was disabled.  When the channel was enabled, this "remembered" DRQ was being executed immediately, resulting in an unexpected DMA transfer.

The fix is to assert a CPU request to terminate the chain before enabling the channel.  By doing this, both requests (the transfer request and the terminate request) will be queued up in the DMA channel, waiting for the channel to be enabled.  When the channel is enabled, the terminate request will take precedence over the transfer request and the DMA channel will terminate immediately, erasing the pending transfer request.  The channel needs to be re-enabled after being enabled the first time since the terminate request will also disable the channel.

Below is example code, showing how the terminate request should be made before enabling the channel:

// Your DMA configuration code goes here
// --->
// ....
// <---
// End DMA config code

// To clear unwanted transfer requests (DRQ), issue a CPU terminate chain request
CyDmaChSetRequest(DMA_Channel, CPU_TERM_CHAIN);

// Enable the DMA channel, This enable kills the spurious DMA transaction if there is one
// and disables the channel, must re-enable
CyDmaChEnable(DMA_Channel, 1);

// re-enable the DMA channel
CyDmaChEnable(DMA_Channel, 1);