STM32F407VGT6 SPI1 receive problem.

[axel2]

Posted on March 26, 2014 at 21:56

Hello,

For some time I've been developing system at my company, one of the features is SD card, interfaced via SPI (SPI1 to be more precise). However there is a problem with reception of data by MCU. When I map SPI1 to PB3/4/5 it works good, but when I map it to PA5/6/7 it messes up LSB of transmission. This is log from MCU uart (PC<=>Board), during good transmision via PB

[...]

>SD->   SD::1   -> Init::begun                                            FF 01 FF FF FF FF FF FF FF 01 00 00 01 AA FF FF             FF 01 FF FF FF FF FF FF            FF 01 FF FF FF FF FF FF FF FF        FF 01 FF FF FF FF FF FF  FF 01 FF FF FF FF FF FF FF FF       FF 01 FF FF FF FF FF FF  FF 01 FF FF FF FF FF FF FF FF FF 01 FF FF FF FF FF FF  FF 00 FF FF FF FF FF FF FF FF      FF 00 C0 FF 80 00 FF FF                         >SD->   >Block orientated card      FF 00 FF FF FF FF FF FF SD->   SD::1   -> Init::SuccessfulFAT start        =  8192AT Boot offset  =    11                    >FAT->  FAT16   -> Init::Successful         Fat reset[...]And after that system works good no problems whatsoever. HOWEVER if I map SPI1 to PA this is what I get:

>SD->   SD::1   -> Init::begun         

FF 01 FF FF FF FF FF FF  FF 01 01 00 00 AB FE FF             FF 01 FF FF FF FF FF FF            FF 01 FF FF FF FF FF FF FF FF        FF 01 FF FF FF FF FF FF  FF 01 FF FF FF FF FF FF FF FF       FF 01 FF FF FF FF FF FF  FF 01 FE FF FF FF FF FF FF FF       FF 01 FE FF FF FF FF FF  FF 01 FE FF FF FF FF FF FF FF       FF 01 FE FF FF FF FF FF  FF 01 FE FF FF FF FF FF FF FF       FF 01 FE FF FF FF FF FF  FF 01 FE FF FF FF FF FF FF FF       FF 01 FE FF FF FF FF FF  FF 01 FE FF FF FF FF FF FF FF       FF 01 FE FF FF FF FF FF  FF 01 FE FF FF FF FF FF FF FFNow if You compare bold in good/bad transmission You'll see that the bad one sort of delays LSB change, the good one is good because the standards says it should look like this and code was earlier implemented to AVR and gave the very same output as the good one. When checked with oscilloscope everything is good, also this not a problem with single piece of hardware, I've tested it on two separate boards  from different lots and they perform the same. Most likely this has also nothing to do with software as good and bad share the same code (except for two lines where I map pins, which is available 

http://pastebin.com/QQmp9jiD

 ). This is also not a problem with SD card as I've tested this with 7 different cards (including SD/SDHC/SDXC and even microsd). The only thing I can think of is some sort of error of input transistor buffers on silicon connected to this line.Any ideas? I'm clueless.  #discovery #stm32f4 #spi #error

[Tesla DeLorean]

Posted on March 26, 2014 at 22:04

Might it be advisable to mask register content before or'ing values, and testing TXE prior to writing DR?

[axel2]

Posted on March 26, 2014 at 22:13

>Might it be advisable to mask register content before or'ing values, and testing TXE prior to >writing DR?

@TXEThis was also done but I don't have latest code here, however it didn't change anythingMasking or shall I name it clearing/preparing was also done, however it didn't change anything. Also this is one of the first parts of the code (checked with debugger numerous times, and registers are OK). //it doesn't change the fact that it should be there, thank you for reminding me :)

[Tesla DeLorean]

Posted on March 26, 2014 at 23:20

I'm not aware of any differences between the A and B banks, the AF mux shouldn't be an issue. For input's I might consider what pull-up where on the pins, as I presume you have two different sockets wired up. Don't recall seeing any errata issues.