I believe 64 bytes per BULK endpoint is a hardware limit of the PSoC.
Might be a workaround somehow?
I think in any case you still need to read in the endpoint in sets of 64-bytes, and if your total data is a multiple of 64, ensure there is a null packet at the end to signal that there is no more incoming data.
Why do you need more the 64 bytes?
Let's assume 64 bytes is the limit for the buffer. You can use DMA transfer for the bytes if you need to reduce the CPU load.
I have to store 3K blocks of data in an I2C EEPROM that comes from a PC GUI app The EEPROM has 32 byte rows and data is continuous. For every byte of hex data that gets programmed into the EEPROM, there are 2 ASCII characters coming in on the USB. I attempted to do a 64 byte packet but that also holds the CR-LF, so best I can do is 62.
The work around is to just split the lines into lower and upper half and send only 32 bytes at a time.
The PSoC 5 has a load of memory, so I just thought there might be some way to expand the Endpoint. You can go less but not more.
I suspect that the 64 byte endpoint is a HW limitation with the PSoC USB fixed function resource.
There is the ability to use DMA with the USB transfer. There is documentation on how to use this in the datasheet.
With DMA, you can create a virtual endpoint size of basically what ever size you want.
Yes, I looked into the DMA but it doesn't do me any good because the GUI will still have to send 64 bytes at a time. Burdening the CPU isn't an issue because at the time of the transfer, that's all that's happening. The way it's working is, the PSoC receives a line from the GUI, programs it into the EEPROM and reads it back out before processing the next line. It's just a bummer that I have to split the line in half because with the CR-LF, you can only get 62 characters. Oh well, I told the GUI programmer that we were beating on a poor little micro and there might be limitations, just didn't know what they were at the time. He wanted to blast the whole block.
Cool stuff to know though.