problem using SAI block B on STM32F427VIT6 (100 pin LQFP)

[galens]

Posted on May 24, 2015 at 22:22

Hi,

I've been trying to use the SD_B output on an STM32F427VIT6 with no success.  This is the 100 pin package.  With typical SAI usage, SAI block B would not be usable since the MCLK, SCLK, and FS pins are on port F, which is not pinned out on the 100 pin package.  However, for my application, all I need is the SD_B output.  I was planning to use SD_B to create a custom pulse train, where SD_B would be the only output (no MCLK, SCLK, or FS needed). To experiment with the SAI, I took the STM324x9I_EVAL SAI_Audio example from the STM32Cube_FW_F4_V1.5.0 release and tweaked it to run on a board that has an STM32F427IGT6 (176 pin LQFP).  When I run my code on this board, all outputs behave as expected.  The code configures the GPIO such that both of the possible SD_B pins are driven (PE3 and PF6), and that is the behaviour I see.  PE3 and PF6 are identical and are shifting out audio sample data. When I take the identical code and program it into the STM32F427VIT6, port PE3 does not toggle.  If I use a debugger to read the GPIOF input data register, I don't see any input activity.  When I read the GPIOF input data register on the 176 pin device, I can see all of the associated SAI B pins toggling. Note that I have tried this same experiment, but with SAI block A.  The SAI block A pins are on ports D and E, which are available on both the 100 and 176 pin devices.  In this case, both devices perform as expected, driving MCLK, SCLK, FS, and SD, with SD appearing at both PD6 and PE6. Both the 100 and 176 pin devices appear to be rev Y. To summarize, I was expecting the 100 pin and 176 pin devices to behave the same with respect to SAI SD_B, but that does not appear to be the case.  Are the unbonded GPIO ports on the smaller packages disabled in some fashion?  Why is SAI SD_B at PE3 not functioning in the 100 pin package? thanks, galen #stm32f4-sai

[Tesla DeLorean]

Posted on May 24, 2015 at 22:49

I'd expect the unbonded GPIO's to work, make sure the clocks to them are enabled (and you can confirm the enable bit), and that the AF settings are in fact correct. Make sure the peripheral clock is enabled, and if it's a slave device, that the master is enabled too. Sorry not got any mileage on the SAI.

[galens]

Posted on May 25, 2015 at 01:41

Thanks for the response.  In case it wasn't clear from my initial message, I'm running the exact same binary on each device.  For the purposes of my experiment, the only difference between the the two boards is that at runtime the code uses the state of a single pin to select between an 8 MHz and a 16 MHz HSE xtal.  Other than this dynamic setting of the M divider, the code paths are identical.

Anyway, I just used my debugger to poke at the configuration registers on the 100 pin stm32f427.  First I enabled the port F clock, then I configured PF0 as an output.  Finally I attempted to set PF0 by writing to the output data register.  Writes and reads of the mode and output registers seem to be normal, suggesting the clock to the port is functioning.  However, the input data register always reads back as all zeroes.  It's as if the Schmitt trigger input buffer is forced off for the unbonded port pins. galen