Thank you for sharing this solution with everyone.
I run a 32-bit Windows 7 SP1 guest on VMWare Fusion (6.0.3) under OSX 10.9.3 on a 2012 MacBook Air. I do not have this issue that you have. I have used this virtual setup for quite some time now and programmed PSoC devices using the on-board KitProg3 that comes with the PSoC5LP dev kit, the on-board programmer (not sure what it's called) on the PSoC4 pioneer dev kit, and also using my own FX2LP based programmer (same as the PSoC5LP dev kit) on custom boards.
I do occasionally see that PSoC Creator can't capture the PSoC5LP (It detects the programmer and detects an ARM Cortex-M3 connected to the programmer, but cannot determine that it's a PSoC5LP) -- I have to power-cycle the board which also reconnects the programmer to get it working again. Virtually disconnecting the programmer from the Windows guest and reconnecting it sometimes works as well.
Interesting that you do not see this problem on your setup as it is identical to mine. I tried using a fresh Windows XP install under both Parallels and VMWare and the problem was still there. The release notes for the programmer also claim compatibility with Parallels 8 and VMWare Fusion 5, however I was using Parallels 9. Incidentally, I'm using PSoC Creator 3.0 SP1.
I've also seen the "ARM Cortex M3" issue, however that is only with my own 5LP designs, not with the dev kits. Strangely enough, with my own designs (which follow the kit reference design to a tee), although XRES is supposedly pulled up internally, the voltage on the pin is always zero and I have to manually pull it up with an external 10k. I've poured all over the docs for a solution to this issue but haven't found anything. If I hold the device in reset and then let it go, it reports as a PSoC device again.
Incidentally, the exact error:
Error: dbg.M0023: There was an error while programming the device: PSoC Programmer reported error (100 - Unknown error)
I'm also a mac user and have seen the same problems that you're reporting. The need to unplug/replug was definitely annoying. My solution (to this problem and others) was to use a Segger J-Link for debugging. It plugs right into the -050 kit and works just fine, with no hiccups at all.
I'm also doing builds natively on the mac as well, using the launchpad.net toolchain and makefile. Builds are *much* faster natively than they are when run on a VM. Plus, I don't have to worry about PSoC Creator crashing when it sees my C++ code. Creator is still necessary to configure all the special PSoC stuff, but the "generate application" button takes care of the magic. From that point on, it's just source code for a Cortex M3.
@mfj: see the exact same error message when it fails to find the PSoC5LP through the DVK; sometimes virtually unplugging and plugging it back in works, but not always. Resetting the PSoC5LP target never works. Physically unplugging and replugging always works.
@andyturk: I didn't think of using a jlink; that'd certainly be an option and would speed things along with native (OSX) builds and debugging. Thanks for the tip!
I forgot to mention, I use PSoC Creator 3.0 SPI as well.
Thanks for this info... I found that my MiniProg3 was VID 04B4 and PID F113... use the PID of your probe when attempting this! You can find this through Device Mangler.