When Bus Transceivers/Buffers come in handy in an embedded design?

Hello everyone!

I have a legacy SCSI controller interfaced to STM32F407 via the FSMC. I spent almost a year working on this project until I became acquainted with the protocol. Anyways, I have been running into several issues and I was wondering if using buffers on the outputs and octal bus transceivers on the bidirectional pins could help improve the performance of the data transfer. The datasheet of my SCSI device says the device is capable of 3 MBytes/s (asynchronous transfer) in the worst conditions, however, I couldn't achieve a fraction of that. Right now, the best I could get was 20 seconds for a single MB, which is far from acceptable. I spent the past month working almost 10 hours/day trying to solve it to no avail. I just don't know what might slow down the transfer like that.

Since I almost gave up at the software side, I thought I might need to take another look down the bus and the electrical specs. I noticed that there's some interference between the impedance of the STM32F4 board and that of the SCSI processor board. I had them connected to each other by means of jumper wires. Even when no power is applied to the Vdd pin of the SCSI Controller, I could read 1.3 V on that pin when the STM32F4 board is powered. The SCSI device itself is a 5.0 V CMOS device. Not sure if level-shifting is necessary, but as far as I know, the GPIOs of the STM32F4 are 5V tolerant.

Aside from the result I have obtained, how about using an Octal Bus Transceiver between the STM32F4 FSMC and the data/address bus of the SCSI controller? WHat are the advantages/disadvantages of using one?

Thanks in advance!

Hi,

I don´t think that busdrivers will solve the problem.

From software side you should know how long each function takes (at least you should have a clue for timing critical functions).
You should have a scope or a logic analyzer to make your signals and the timings visible.

I recommend to use some pins to ouput diagnostic signals. Use a scope to verify timings like:
* processing time to read a block from SRAM
* processing time to transmit a block via SCSI
* time from sent_out_data (SCSI master) to received_data_acknowledge (SCSI_device)
and so on.

First you have to draw a sketch of the complete signal flow.
Then you have to check the signal flow step by step to find the bottleneck. Don´t follow random ideas...

Klaus

SCSI was once common in Macintosh computers. In every installation we had to consider whether a SCSI device needed a 'terminator' (connector with a resistor network to reduce reflections in the cable). If a SCSI device failed to be recognized then frequently termination needed to be added, or if present then it had to be removed.



Some cables need passive termination. Some need active termination. SCSI success or failure tended to be unpredictable. Strategies for attacking problems took on a 'voodoo' flair.

Hi Klaus,

Thank you for the input. Yes, you are absolutely right. I believe getting the appropriate timings is more than critical for this application. The problem is, I don't have access to a Logic Analyzer at the moment so I've been doing things blindly. I've been looking at some of them recently and I'm thinking about ordering one pretty soon. However, I have found a piece of software that turns a development board into a Logic Analyzer and I've been able to scope the signals, including the data bus, and I got some interesting results. I think an FPGA based Logic Analyzer with a faster sampling rate and better interface is all I need to get the exact timings.

Will be back as soon as I have the Logic Analyzer handy!

Thanks again!

P.S. This is a screenshot of the results obtained using Analyzer2Go:


- - - Updated - - -

@BradTheRad:
Yes, I have terminators on both sides of the bus. Thank you!

Hi,

The picture is good.
It tells that 8 bytes (words) are transferred as a block, but then something freezes the bus.
I can't see (because I don't know the protocol) wheter this is caused by the master or the slave.
(You should know...)

Find out how long this takes and who is responsible for that.

Btw: you may use timers/counter within your microcontroller to get some timings.
Just let a 16 bit counter run with a fixed frequency, then at some debugging points in your software read them out (as timestamp) and send them via another debugging interface to the PC. Just use the difference of both values to get exact timing informations. (Maybe * at the beginning of a function and * at the end of a function)
So you are able to find out timing problems without a logic analyzer.

Klaus

Hi Klaus,

Timestamps with a timer seems a great idea. I will try to do it!

Thank you!

- - - Updated - - -

Klaus,

Could you please explain this for me. The datasheet of my SCSI controller says CS/ must make a HIGH to LOW transition to latch a new register address. However, the RM of the STM32F407 says the following:

The FMC Chip Select (FMC_NEx) does not toggle
between consecutive accesses except when performing accesses in mode D with the
extended mode enabled.

Click to expand...

What is the real difference between modes A, B, C, and D?

Well, apart from SCSI timings for REQ/ACK handshake, do you think I can achieve the exact timings needed using the FSMC or bit-banging the interface might work better for me?

Multiplexed vs non-multiplexed access:
Right now, multiplexing is disabled in the FSMC setup, and I have dedicated 4 address signals for the SCSI controller. I tried to enable multiplexing and I changed the mode for the SCSI controller to the "Multiplexed Bus", but it didn't work for me. I was wondering if you have used that mode or you can elaborate more on how the address signals are output on the bus when multiplexing is enabled.

Thank you again!