2011-08-31 06:16 AM
Hi,
I am trying to establish communication between STM32F103C8T6 and an ASIC using SPI.The STM32 is the master and the ASIC is the slave. The requirement of the ASIC is that it requires the MOSI line to be high during idle(i.e the MOSI line should have an high state before clock appears on the SCK line).I have added pull up resistors of 4.7kohms on MISO,MOSI and SCK lines. I am not using NSS pin. Here are my observations: 1. The MOSI line latches to either high or low value which is dependent on the data shifted through the buffer. 2. When I set the SPE bit(SPI enable bit) in SPI CR1 register, the MOSI line is pulled low .The pin is configured as Alternate function output(observed in push pull as well as open drain). I have verified the other settings. Please help me out people, this is really very urgent. Regards Rahul #stm32-spi2011-08-31 08:27 AM
2011-08-31 12:37 PM
Unfortunately for you, your urgency doesn't pay my bills.
Have you considered a bit-banged implementation of your specific SPI requirements? ie driving the SPI pins in software. This might permit you to at least validate connectivity, and communications, rather than stare into space. Do you have bandwidth, or timing constraints? You could also presumably mux the data/clock off the pins, and send an 0xFF pattern to the data register if priming it with a specific pattern/level is important.2011-08-31 05:15 PM
Which SPI port are you using?
This is a hardware bug with SPI1 remapped that requires completely disabling the I2C port. I'm curious what you expect the external pull-up resistors to do...2011-09-01 03:30 AM
2011-09-01 03:53 AM
Hi Donald,
I am using SPI2 of the controller. There is no I2C port on those pins, i am using a 48 pin device. If i configure the MOSI line as alternate function o/p open drain then i expect the line to be pulled up at all times by the pull up resistor and only swing when the data has to be outputted on the line. But when i do that,after i set the SPE bit the spi engine pulls the line low for about 500 ns and then starts outputting clock and data on sck and MOSI line respectively which contradicts the requirement of the ASIC i am using. Regards Rahul2011-09-01 05:23 AM
At end of transmission, disable the SPI (as described in Ref Manual) and set pins as GPIO to chosen level. Reenable SPI next time you want to use it.
2011-09-01 05:28 AM
The other option will not help either because by sending 0xff i will have to send clocks too.
That's why I said to mux the clock off the pin. Try setting the pin for GPIO output or input, rather than connected to the SPI peripheral. You could try switching the data to GPIO INPUT PULLUP.One question: Do you think that the behaviour of the SPI engine is normal by pulling the MOSI line low? Don't know for sure, but I would generally expect it to take the value of the last bit shifted out. This should be relatively easy to demonstrate. Usually there four phase/polarity modes for SPI, you could try them. Also if the ASIC expects the data line to float high, what about SPI half-duplex (1 wire) mode.I have considered the bit banging method but since i have a deadline to meet i cant spend more time emulating the SPI protocol. What would it take? 10-20 minutes, and confirm that communication with the ASIC is viable. I'd take that route rather than scratch/bang my head for two hours and make no progress.
2011-09-01 06:34 AM
One question: Do you think that the behaviour of the SPI engine is normal by pulling the MOSI line low?
this seems to be a hot item, I do not see why, the state of MOSI should be totally irrelevant when SCK is steady. Erik
2011-09-01 12:24 PM
I do not see why, the state of MOSI should be totally irrelevant when SCK is steady.
You'd think. That's how everyone else designs an SPI interface. This is about the time I go find the ASIC design guy and pound his head against the desk, and then have him explain to my boss why I'm missing my deadline.