When the CY8CKIT-059 connected to PC with pressing the RESET button, the CY8CKIT-059 kit is recognized as an HID device which VID/PID is 04b4/F13B.
Can you confirm the device instance on the device manager?
I suppose this answer is YES because you can access by the PSoC Programmer and Bootloader Host Tool.
After PSoC Programmer reloading the KitProg program successfully,
What does your CY8CKIT-059 says?
KirProg is recognized as a USB Composite Device in the device manager.
Can you find a composite device?
KitProg has Mass Storage mode recognized as VID/PID=04B4/F138
If you find this device, push the RESET button for 5 seconds to revert to the KitProg mode.
You are correct. The KitProg in bootloader mode is VID=04B4 PID=013B when the reset switch is active during the plugin.
When a properly factory programmed KitProg in USBUART mode is VID=04B4 PID=0139 when the reset is NOT active during plugin. This is not occurring once a factory reset programming has successfully occurred.
does not appear. In fact, a window shows up for about 6 seconds that says something like "USB device not recognized."
New information JUST IN!
When I press the reset button for 5 seconds with the KitProg already plugged in, I get the USBUART HID to appear. I removed the KitProg and plugged it back in, the USBUART is still available. If I reconnect it back to the original target board, I can program it.
All is now working. It's a little confusing how it got where it is at.
Is it possible that some EEPROM is used to store the latest HID functional setting? When I programmed my own application into the KitProg, I use the first 300 bytes of EEPROM. If this is the case, my application probably wrote to the same EEPROM locations and confused the bootloader.
Just a guess.
Thank you for letting me know new information.
The recent KitProg has two modes, KitProg and Mass Storage. The status of the mode is stored in EEPROM and it is not overwritten or erased by the firmware upgrade. I don't know which address is the mode status stored.
Thank you for your help. I ended up changing the starting address of the EEPROM configuration data of my application to the second sector. This hopefully should avoid the collision with the KitProg EEPROM address.
Future note to Cypress: In the section of the KitProg documents regarding bootloading your own application, place a note about what EEPROM addresses are being used by KitProg. These EEPROM locations are fair game if the user never plans on returning the factory code back in KitpProg.