1. Home
  2. Embedded Programming
  3. CY7c67300 (EZ-Host) and HSS

CY7c67300 (EZ-Host) and HSS

Hi, I'm using the Cypress CY7c67300 (a.k.a EZ-Host) chip in a dual-role (eg. both USB host and device) application. My code runs in the internal RAM of the chip, and another uC is sending and reading data to and from the EZ-Host chip via HSS commands. Sometimes these HSS commands fail. When I monitor the serial line with an oscilloscope I can see the following:

- I send a proper COMM_WRITE_MEM command

- the EZ-Host sends back ACK

- I send 2 bytes of 0 (as part of the previous COMM_WRITE_MEM command)

- I send a proper COMM_READ_MEM command (I want to read back those 2 bytes)

- the EZ-Host sends back NACK (why?)

- I retry the COMM_READ_MEM command

- the EZ-Host sends back ACK

- then it sends back the data - but instead sending back 2 bytes of 0 it sends 0x08 0xce, which is the code of the COMM_READ_MEM command

This happens very rarely. I don't see any disturbing noise on the oscilloscope. It happens at 1Mbaud and at 2Mbaud with roughly the same frequency (about 1 time during 20000 transfers), and it only happens when the EZ-Host chip is transfering data on both the USB host and device interface. When the chip communicates only as a device I cant observe this bug.

Anybody saw the same thing happening? What can I do to prevent the COMM_WRITE_MEM commands to corrupt memory? Shall I double-check every byte? Thanks for any help in advance, Botond

Reply to
googleaccount
Loading thread data ...

OK, this behaviour can be explained only by the existence of two bugs in the BIOS. One is a design flaw, the other is a pure coding bug.

The BIOS users' manual says that the host shall wait at least 30 microseconds before sending a new LCP command over the HSS interface. However the BIOS can't grant that after the completion of the previous HSS command it will be able to interpret the next command in 30 microseconds. When there's tfraffic on the USB this delay can grow to

30 miliseconds or more. So parts or all of the next command can be lost when the host sends it too early, and there's no way to figure out how long the host shall wait. The designers should have inserted another ACK/NACK handshake phase to signal the completion of each command.

And the coding bug: the above described design flaw alone wouldn't be enough to produce the reported data corruption. When the BIOS finishes the interpretation of a command (like COMM_WRITE_MEM) and prepares for the reception of the next command it 1st sets the HSS Receive Counter Register and then it sets the HSS Receive Address Register, which is wrong. After having set the HSS Receive Counter Register and before setting the HSS Receive Address Register new bytes arriving on the serial line (the next HSS command) can be written into the receive buffer of the previous command (for example COMM_WRITE_MEM).

The only solution to these bugs is to write another HSS interface. My application uses only COMM_READ_MEM and COMM_WRITE_MEM commands after initialization, so it was relatively easy to get rid of the BIOS HSS interface, implement a new one and stay compatible with the old host application.

Reply to
Botond

What bugs, in what system, etc. You should realize that Usenet has no delivery guarantees. There is no reason to assume that any reader can now, or will ever, be able to see any particular posted message. So you have to quote enough of whatever you are replying to to ensure your message stands by itself. The following links may help.

Please do not top-post. Your answer belongs after (or intermixed with) the quoted material to which you reply, after snipping all irrelevant material. See the following links:

--
  
  
  
    (taming google)
    (newusers)
Reply to
CBFalconer

Sorry, here's the quotation:

formatting link

Reply to
Botond

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.