I'm using this part in our project and I've noticed that this macro is defined.  When I look at the library API code, I always see comments around this macro about correcting mistakes in the ES1 silicon.

I'd prefer not to use ES1 silicon. so I'd like to find out if this is correct and, if it isn't, which device I need to select.

ES1 silicon is clearly marked on the chip and when the chip is connected to a programmer read out correctly and displayed to you.

When you have selected your target-device the programmer will refuse to program yout project into a different one, even if the difference is the ES1, ES2 or no experimental silicon version. Cypress gave sent out the ES-versions to give us developers early access to new chip-developments and most of those went into the development kits and not into production. So when you order PSoC devices you can be sure that they aren't ES-something or it will be explicitly pointed out.

Bob

 The chips were purchased from Digikey a few weeks ago and are not marked ES1 on the top.  Nor is there an ES1 in the device selector.  There are a couple of parts in the device selector with an explicit ES1.

From what I've seen in the header files, ES1 is defined during the build, and probably based on the device selected.  Here are the defines:

cytypes.h

/* Device is PSoC 5 and the revision is ES1 or earlier */
#define CY_PSOC5_ES1 ((CYDEV_CHIP_MEMBER_USED == CYDEV_CHIP_MEMBER_5A) && \
(CYDEV_CHIP_REVISION_USED <= CYDEV_CHIP_REVISION_5A_ES1))

#define CYDEV_CHIP_REVISION_USED CYDEV_CHIP_REVISION_5A_PRODUCTION

#define CYDEV_CHIP_REVISION_5A_ES1 1

#define CYDEV_CHIP_REVISION_5A_PRODUCTION 1

#define CYDEV_CHIP_MEMBER_USED CYDEV_CHIP_MEMBER_5A

As you can see, the 'production' version of the chip is version 1, which is ES1 by the macro.  This means all the ES1 code in the library is executed, which I'm not sure is correct.  Oddly as well, is the definition for CY_PSOC5_ES2:

#define CY_PSOC5_ES2 (CY_PSOC5A && \

    (CYDEV_CHIP_REVISION_USED > CYDEV_CHIP_REVISION_5A_ES1))

Which means every PSOC5 part is either ES1 or ES2, if CY_POSOC5A is defined.  I'm not sure of the meaning of that define, but it appears to be defined for every part I tried.

I put the following code in a test project

#if (CY_PSOC5_ES1)

#error shouldnt be ES1!

#endif

And built it using a sampling of PSOC 5 parts and every single one failed.  This is with PSOC Creator 2.1 with component pack 4.

I thought perhaps the issue was I had Creator 2.0 and 2.1 insalled - I uninstalled 2.0 and I still have the same issue.

Parts seem to work, but I'm a bit concerned I've setup the project incorrectly such that this macro is defined.

So, why don't you trust Cypress and the software? Is there any issue you have got within your project?

I am a (professional) programmer, but I wouldn't go through the sources to decide what fab-internal #defines are set and why.

You ought to remember that, when programmers create new versions or new suppoted devices old #defines are often used for new features etc. I suggest you to trust in the result, there are more challinging features within PSoCs than generated lib-code.

Bob

I'm  having some issues with USB powering up properly on a self-powered device so I was stepping through the library code to try and find out what was going on.  I noticed the ES1 macro was defined, which seems wrong, so I'm curious if that is correct and perhaps either a symptom of my problem (maybe my device is not setup properly) or just an oddity.

Did you follow the guidelines in USBFS datasheet page 34 which says

USB Compliance for Self-Powered Devices

Bob

 Yes, I monitor the pin and start/stop the USBFS manually when I detect power.

It was running fine until I added code to dynamically turn off the crystal and use the internal oscillator when there was no external power, as the crystal consumes a significant amount of current.  This involved a relatively complicated scheme of changing clock sources, flash wait states, etc and now the USB system won't start anymore (the D+/D- pins stay at 0V even after I do a USBFS_1_Start()).

While I was trying to figure out what was going on I ran into the _ES1 macro being defined, which I thought was odd.