I'm running into a weird issue with using the PSoC5LP I2C Bootloader Interface.
I am using a CY8C5467LTI-LP003. Building my project in PSoC Creator Version 4.2.
I am performing the bootload operation with a custom C# .NET application using bootl_utils.dll (built from the source from Creator 4.1 if I'm remembering right), that interfaces with the CY7C65211A (I2C Vendor Driver) via cyusbserial.dll.
I should note that I have modified the bootloader utilities library that I'm using here, as I detailed here in this old thread where I was also having problems bootloading over I2C.
I can see nothing wrong with the operation of the host, it looks to be sending the correct packets in the correct format, but the data coming back from the PSoC appears to be the issue. Particularly with the response to the "Program Row" command. See the logic capture below:
Note the response from the PSoC5, it looks like it's stretching the clock for some reason when its address is called out after receiving the 0x39 (Program Row) command packet. It actually looks like it forms a correct response, but the first byte of the packet is wrong (0xFF). It's a little tough to see, but the bytes in the response on the stretched read are as follows:
This is interesting, because judging from previous responses, the packet SHOULD be:
It looks like it's sending the correct number of bytes, and that it assembles the packet, but for some reason is sneaking an 0xFF into the first byte rather than the 0x01 Start of Packet byte, and pushing out the 0x17 End of Packet byte. I image
I am logging all I2C in and out in the log window of my bootloader application, here's the complete Command/Response history leading up to the failure:
It also looks like the response to the Get Application Status (0x33) command is a little funky, with 2 extra 0xFF bytes tacked on the end, but this doesn't seem to be causing any problem in the process.
The problem appears to be on the PSoC side, but I was also able to successfully load using the Bootloader Host included with creator using the MiniProg3 as my USB-I2C bridge, so there's evidence pointing to both ends being the culprit?
Might anyone have an idea as to what's going on?
Thanks in advance for any tips!