STM32F103C8T6 SPI problem

Thread Starter

cooded

Joined Jul 20, 2007
29
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
 

kavli

Joined Aug 1, 2011
23
How is it behaving if the last word you push to the buffer is all '1's? If you have control over the protocol side of the ASIC, then you can make it always dump the first octet.

If you don't have control over the ASIC side protocol, then I think the only option is to isolate them with an external 3-state buffer and a pull-up.

-- K
 

Thread Starter

cooded

Joined Jul 20, 2007
29
When i push the last word into the buffer which is 1, the line stays high.
I cant add anymore hardware to my design so i cant use a tristate buffer.
Do you think this kind of SPI behaviour is normal?

Regards
Rahul
 

ErnieM

Joined Apr 24, 2011
8,377
Sounds like you're working on a breadboard you built yourself. You didn't do anything silly (like I did on my first SPI build) like connect master data out to slave data out and master data in to slave data in?
 

kavli

Joined Aug 1, 2011
23
When i push the last word into the buffer which is 1, the line stays high.
I cant add anymore hardware to my design so i cant use a tristate buffer.
Do you think this kind of SPI behaviour is normal?
No, I can't find reference anywhere to a demand of the MOSI to be logic high during idle, so I'd consider this to be a design flaw for the ASIC part. That doesn't help you much, of course.

Have you been in contact with the vendor of the ASIC about this problem?

What about the protocol between the uC and the ASIC? Does it has a preamble/postamble that starts/stops on a high level? In that case, your problem is solved implicitly.

Ok, some more ranting and raving, since I find this problem interresting.

Let me qoute you from your first post:
"MOSI line should have an high state before clock appears on the SCK line"

Does this imply that the first bit of the first transmitted octet always should be a high? (which also implies that there is a preamble, like I state above)

If that is not the case, there must be a timeslot from the time the high should be present, until the rising edge of the SCK. During this timeslot, you'll need to replace the buffer contents with the real data that should be transmitted. If not, it will be impossible to transmit a '0' as the fist bit of the first octet.

-- K
 
Last edited:

Thread Starter

cooded

Joined Jul 20, 2007
29
Sounds like you're working on a breadboard you built yourself. You didn't do anything silly (like I did on my first SPI build) like connect master data out to slave data out and master data in to slave data in?
Nope i am not working on a breadboard. Also i have not blundered with the SPI lines.
 

Thread Starter

cooded

Joined Jul 20, 2007
29
Let me qoute you from your first post:
"MOSI line should have an high state before clock appears on the SCK line"

Does this imply that the first bit of the first transmitted octet always should be a high? (which also implies that there is a preamble, like I state above)
Nope, thats not the case. What i meant was that the MOSI line should be high before the clocks arrive to the ASIC.

If that is not the case, there must be a timeslot from the time the high should be present, until the rising edge of the SCK. During this timeslot, you'll need to replace the buffer contents with the real data that should be transmitted. If not, it will be impossible to transmit a '0' as the fist bit of the first octet.
I did not understand this part. Tommorrow i will upload the waveforms.

Regards
Rahul
 

kavli

Joined Aug 1, 2011
23
What would be even more interesting is the timing diagrams for the ASIC.

What I meant by the last part, is that if you are to transmit a 0 as the first bit, there must be a time period allowed between what the ASIC considers "idle" until the clock edge is driven.

If the time-period between the "idle"-state and the clock period is zero, then the first bit transmitted is always going to be a '1'. Are you with me?

-- K
 
Top