SC18IS606 puts extra byte at the end of SPI transaction

[kaolpr]

When trying to program FPGA bitstream to flash using SC18IS606 I've faced a strange problem that manifested itself with FPGA not starting properly from programmed memory.

After looking into the problem and doing some logic-analyzer work I have found that the first byte of bitstream readout was equal to 0xF1. Surprisingly, such value did not occur in a bitstream.

First I thought it's some transmission error on I2C side. However, analyzing it revealed perfectly normal transmission. Then I started recording the whole page write operation, and it turned out that there was an extra byte at the end (it had 261 instead of 260 bytes - 256 bytes of page data + 1 op code + 3 address bytes) with value 0xF1 that due to address wrapping was written at 0-th byte.

The only place where 0xF1 occurred in my code was writing operation (interrupt register clear)  just after writing a page that was supposed to check (by getting ACK) that write operation was finished, and if next operation can be performed.

For some reason, this 0xF1 opcode was sent over SPI. It is totally unclear to me why as 0xF1 was sent in a separate I2C operation (see fig.).

Adding a 5 ms delay after writing made a good walkaround. However, I do not understand the behavior here. According to the datasheet:

SC18IS606 will place the data received into a buffer and continue loading the buffer
until a STOP condition is received. After the STOP condition is detected, further
communications will not be acknowledged until the function designated by the Function ID has been completed.

From this I read that if the operation was not finished, the device should NACK. But here, not only it did not NACK (even with top frequency of 1843 kHz should take a bit more than 1ms) but it seems it put this op-code into the buffer.

Am I missing somthing here, or this is not what was expected?

[JozefKozon]

Dear Mikolaj, 

possible explanation:

This behavior suggests a race condition or buffer mismanagement in the SC18IS606:

• The SC18IS606 might not have fully cleared its internal SPI buffer or state machine before accepting the next I2C command.
• If the STOP condition is issued too soon after the SPI write, the chip might still be in a state where it interprets the next I2C byte as part of the SPI stream.
• The 0xF1 byte, intended for a different function, gets misrouted into the SPI buffer.

The delay is effective and safe.

With Best Regards,

Jozef

[SMNJS]

I observed the same issue during a page write sequence to a AT45 flash device.
During the flash write process, the SC18IS606 replies with an ACK despite the SPI communication is fully in progress. 
It seems to me that the necessary (and documented!) NACK response for indicating busy mode of the SC18IS606 device doesn't work at all in this situation.

Please see the attached images in order to comprehend the issue.

In my case the behavior of the SC18IS606 also leads to the problem, that further commands are send to the AT45 in order to read its status register for busy mode. These commands are then appended to the data in the SC18IS606 buffer which are then appended in the SPI transfer and result in a flash buffer write overflow (the first bytes of the flash buffer are overwritten with the status register commands). Of course, this creates ton's of garbage data in the flash...

Can you confirm this behaviour of the SC18IS606 chip on your side?
Am I missing some restrictions regarding the end of a SC18IS606 transfer and the beginning of the next one?

Kind regards,
Julian

[JozefKozon]

Dear Julian,

please see below an answer from an application engineer. Please provide requested and answer the questions. 

DESCRIPTION

1. Can customer provide the sequence of commands been sent and refer them to the specific capture been shared? Can’t get which commands and information is been sent on the specific images, as well as delays between commands.
2. Is customer using the INT pin? If not, can customer use it? Interrupt based operation uses less traffic than polling based.
3. Provide customer’s SC18IS606 FW version (Function ID 0xFE).

With Best Regards,

Jozef

[SMNJS]

Hello Jozef,

Thank you for the reply.

Here the desired answers:

1. On the first image (01 ...), you can see from 168.5ms to 170.42ms the transfer of the data to be written into the flash device, that lies on the SPI interface after the SC18IS606.

   The I2C transfer is then completed with the shutdown of two I2C multiplexer ICs (addr 70 and 71, as slighetly observable on the image) up to 170.9ms. This part shouldn't be of your concerns.

   The actual data transfer of the flash data to be written from the µC to the SC18IS606 ends at 170.42ms and you can see, that the SC18IS606 immediately starts its SPI transfer to the desired flash IC:

   ==> see the waveforms in the upper half of the image from 170.42ms to ~175ms.

   During this "long" SPI transfer, you can observe in the lower half of the image, that from 171.38ms to 172.34ms the next I2C transfer to the SC18IS606 is performed in order to poll the state of the transfer.

   As this transfer gets an ACK instead of a necessary NACK because of the busy SC18IS606 with an ongoing SPI transfer, the microcontroller proceeds with further transfers which lead to the mentioned behavior.

   On the other two images (02 and 03) the red-framed area is zoomed in in order to see exactly the waveform of the error-prone response.

   Hope this description clarifies the issue.

2. We are note using the INT pin on our electronics and in the current design it is not possible to consider this feature for a redesign.

   In addition, we interpreted the INT pin as optional for a correct function of the IC, as polling seems to be a valid approach by the data sheet.

3. I am not aware of all chip-revisions we are using in the field, as we delivered systems with this IC for the past two years and I didn't register the IC version for each component we build.

   Nevertheless, I am aware of at least two versions of the IC that I have in office. One of them is SC18IS606 1.0.1 and the other was SC18IS606 1.0.2 (where I attached wires for the attached scope images).

       For now I am sure that both IC revisions seem to work alike for this issue.

Kind regards,

Julian

[JozefKozon]

Dear Julian,

please see below answer with suggestions from the application engineer. Please test as suggested.

DESCRIPTION

Thanks for the information and customer for the detailed information.

1. Do you know if customer is issuing the Clear Interrupt (ID 0xF1) prior to the data transaction? (the one customer is showing in the 168.5ms to 170.42ms)
1. If not, can customer implement Function ID 0xF1 prior to every valid transaction? Is there any difference?
2. Mainly, might be that the internal state machine, even if doing polling-based communication, is still looking into the interrupt flag to ACK or NACK its address. If Interrupt flag is set (meaning, transaction has finished) then address will be ACK as per internal logic.

2. Thanks for the comments. If not for a redesign, can customer also probe INT pin? To understand the status of it.

3. Thanks, it is mainly for reference, if required.

With Best Regards,

Jozef

[SMNJS]

Hello Jozef,

Until now, I did not use the clear interrupt command prior to any transmission, because it is stated optional in case of polling the IC.
I performed several tests with the INT pin also probed and recognized no noteworthy difference in behavior whether I used a clear interrupt command or not.
In my attached usecase, you can see your desired behavior with the clear interrupt command before any write buffer command on my µC to the SC18 IC.
In general, the insertion of the clear interrupt command did not solve my problem.

Please have a look at the attached scope images, where I did a zoom on any important part of the transaction.
The images are numerated and the number increases proportional to the timeline of the sequence. A short explanation of each specific zoom is in the name of each image.

As far as I can tell, there seems to be an issue with the reset of this interrupt, as I can observe a state change of INT without any clear interrupt command (see especially attached image "04 zoom - flash ready SC18 readout - INT clear despite no command was send.png").
I don't know if this correlates with the absence of NACK in the SC18 IC beeing busy.

I think it would be most effective, if you could check this behavior with an evaluation board of the SC18 on your side, in order to see if it behaves different.
If it does, it would be really interesting how this is possible.

Looking forward to hearing from you.
Kind regards,
Julian

[JozefKozon]

Hello Julian,

another application engineer joined the internal conversation and is suggesting to add the 5ms delay after writing, as described in the first message. Have you tested this workaround? If not, please test it. 

With Best Regards,

Jozef

[SMNJS]

Hi Jozef,

I do have a timeout-based workaround. I measured the time the SC18 needs in order to transfer the data with the scope. As far as I can tell, the SC18 takes ~2x the time that should be necessary in order to transfer the data with 1.8MHz via SPI. This is because of a delay between each transferred byte that is as long as the transfer of a single byte itself (see attached image).

Because of this behavior, my timeout can be much smaller than 5ms but is implemented at least long enough to ensure the end of the write transaction on the spi bus.

I implemented this workaround before appending my observation to this thread, as I was in high need of a quick solution. Nevertheless I am very interested in finding the root cause of the error behavior, as I'm really interested in further improving the transfer speed for my application.

Could you verify the same behavior on an evaluation board in the meantime?

Kind regards,
Julian