SPI MISO problem

[michaelm000]

Posted on November 23, 2013 at 23:09

I know this is weird, but any help would be great. This is driving me nuts.

I'm tyring to use A5, A6 and A7 as SPI for communication with a touchscreen controller. SCLK and MOSI work fine, but MISO (A6) works only the first time and then becomes active high thereafter? What could cause this? I have included the configuration code. Thanks,

// enable clock for used IO pins

RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA,

ENABLE

);

/* configure pins used by SPI1

* PA5 = SCK

* PA6 = MISO

* PA7 = MOSI

*/

GPIO_InitStruct.

GPIO_Pin

= GPIO_Pin_7 | GPIO_Pin_6 | GPIO_Pin_5;

GPIO_InitStruct.

GPIO_Mode

=

GPIO_Mode_AF

;

GPIO_InitStruct.

GPIO_OType

=

GPIO_OType_PP

;

GPIO_InitStruct.

GPIO_Speed

=

GPIO_Speed_25MHz

;

GPIO_InitStruct.

GPIO_PuPd

=

GPIO_PuPd_UP

;

GPIO_Init(GPIOA, &GPIO_InitStruct);

// connect SPI1 pins to SPI alternate function

GPIO_PinAFConfig(GPIOA, GPIO_PinSource5, GPIO_AF_SPI1);

GPIO_PinAFConfig(GPIOA, GPIO_PinSource6, GPIO_AF_SPI1);

GPIO_PinAFConfig(GPIOA, GPIO_PinSource7, GPIO_AF_SPI1);

#spi

[Tesla DeLorean]

Posted on November 24, 2013 at 03:28

I know this is weird, but any help would be great. This is driving me nuts. I'm tyring to use A5, A6 and A7 as SPI for communication with a touchscreen controller. SCLK and MOSI work fine, but MISO (A6) works only the first time and then becomes active high thereafter?

You're asking the wrong question. The STM32 in this equation is presumably the MASTER, the pin you're complaining about is driven by the SLAVE device. The question should revolve around the slave device, what it is, what your sending to it to configure it, and how and what you expect it to communicate back to you. Is there an expectation of a chip select? Is the data you are sending actually received and acted upon?

[michaelm000]

Posted on November 24, 2013 at 10:54 Correct me if I am wrong, as I wonder if incorrect configuration of the ST part is my problem.. As best I can tell PA6 on the STM32F407VG when used as an SPI alternate function can only be an input? Also, the data sheet for the slave shows the pin connected to A6 can only serve as an output. That is, it is physically not capable of bidirectional function. Using PA5/6/7 in SPI mode there is full duplex operation with a byte sent on PA7 and received on PA6 simultaneously under control of the master ST clock PA5. When I break line PA6, everything works find: PA7 sends the correct data, while the slave pin output also sends out the correct data. However, when I connect this pin to PA6, I see a tri-state signal on the oscilloscope - logic highs, lows and mid level values. This can only occur when two outputs are fighting each other on the same line. The funny thing is after reset, the first transmission works correctly, that is PA6 receieves the data correct. Thereafter, only the output PA7 functions properly. Is it possible PA6 somehow changes its configured state as an SPI pint?

[Tesla DeLorean]

Posted on November 24, 2013 at 13:40

Once you have configured a pin in AF mode the peripheral behind it controls the pin state and direction. What and how the pin behaves will then be determined by how you have configured the peripheral and what you do with it, and this code is absent.

Perhaps you are setting it up as a slave or something on the STM32 end, or that in sending data to the slave in your first communication you are misconfiguring the slave. Again things I can't know with the code presented, and documentation for the slave cited. In order to troubleshoot this remotely you are going to need to reformulate how you describe the problem to include a code example that is complete and demonstrative of the problem you are having, and which provided detail of the slave device you are communicating with, and documentation that explains it's connectivity information and command/response expectations.