Author Topic: #RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!  (Read 576 times)

0 Members and 1 Guest are viewing this topic.

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 2149
  • Country: 00
  • STM32, STM8, AVR, 8051
#RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!
« on: March 14, 2019, 10:58:19 am »
Hi!

A kind of a rant, this time.  I have fortunately caught this one just in time! I was ready to send a quite complex 4 layer PCB with STM32F429ZIT to be manufactured,  looked in a CS4244 datasheet for the last time and... NO SH!T ... it can't do TDM is master mode.   :palm

http://www.hardwaresecrets.com/datasheets/CS4244.pdf

Why aren't they saying that explicitly, that not all serial port modes do support master? Cirrus, why?!

(To skip the rant, continue reading below the horizontal line.)

Now you may be asking why is that a trouble? Well it is, because STM32 audio peripheral (SAI) can not produce a correct MCLK/BCLK (12.288MHz or multiples) by itself (being a TDM master), it needs to be supplied by external clock to do so.

You may be asking, why don't I just supply those 24.576MHz to the STM32 and be done with it? Well.. that is a good question:

The facking AUDIO_CLK_IN pin,  is not available as free IO to be used. You may now ask why?  Because there is the only free I2C peripheral I need. Why don't I remap the I2C3 to another pin? I f**ng can't, because the only free I2C3 is only available on a single set of two pins.

Who would have thought, that one would like to use LCD, SDRAM and some audio in master mode with I2C to manage the codec and LCD touch panel?

Sometimes I really wonder, how do those ST designers make those alternate function mappings. Because they are one hell of a pain to use and mostly useless for many applications?

I do not say, that I want a full routing matrix capability, just they could put a bit of thought to it! Typical pain in the ass examples of those afio muxing failery, where ALWAYS one freaking pin is ruining everything.

1) I want a simple CAN-USB bridge. I have a nice small 32pin package STM32F042K, but I can't do it, because the CAN has only a single pin available, instead of having both RX and TX!

2) I want a more complicated CAN-USB bridge, having 2 CAN buses and a high speed USB for fast data access to a buffer storage. Good luck finding a MCU for this. (you will end up with something way too much fucking large!) You cant, because USB ULPI always blocks out all possible pinouts of the second CAN peripheral. (you will need an extremely overkill large STM32 MCU with THREE CANs, just to be still able to use only two of them).  :wtf:

3) Now suppose a larger MCU. We want a graphical GUI (LCD + SDRAM), with ETH connectivity.  Nice 144pin package could do it, but hell NO, because a single freaking LCD pin is a blocking the only available RMII interface. (you will likely end up having the largest of all, the LQFP208 to do so).

4) Same as above, but let's add an SD card with fast access to files - 4bit SDIO. In most cases you only end up with just 1-lane SDIO, because one freaking pin is more than likely needed for: the only free I2S, the only free I2C, the only existing I2S_CKIN, etc.

5) Hurray! Some STM32s support QuadSPI.  Good, you say, until you want to add fast accessible storage for a smaller package. Who would have thought, someone would like to have a 64pin package with QuadSPI?  Sorry.. you can do just DualSPI, other pins not available on the package.

6) So you want to add audio to your application with GUI? (LCD+SDRAM). You need also I2C? and standard audio sample rates? hahaha! Forget it. Just another stupid pin is preventing you to do so.  Using LCD+SDRAM is an instant loss of two I2C peripherals on a 144pin package, and the only one left is blocking other important functions.

7) So you want to fix point 6) with a larger 176pin package?  Meh.. try it.  Your I2S_CKIN will get blocked by SDIO, if you want 4bit wide bus. (Who wouldn't want a 32bit SDRAM and 4bit SDIO on such large package?). Just again only a single stupid pin ruining everything.

8)... I could write many more of these examples of the STM32 afio mapping failing basic peripheral combinations, just by one single pin (or two)!

But back to my original problem...



As I have kind of stated in the beginning, I have a board with STM32F429ZI (144pin) and CS4244 audio codec.  Unfortunately, the CS4244 does not support TDM master mode, which is a major pain in the ass, as the STM32 can not provide correct MCLK/BITCLK in master mode, without being supplied with the audio-specific clock of 12.288MHz or it's multiples.

To be able to supply such  clock, one needs the I2S_CKIN pin (PC9). However the PC9 pin is blocked by the only available I2C (I2C3), that for some stupid reason can not be remapped. (I2C1 and I2C2 are automatically blocked by the combination of LTDC + SDRAM ... how rude!)

So I have thought - hey! I could set both the codec and the STM32 to be TDM slaves and supply the BCLK from external circuitry - which is more then simple, because I would need to just copy MCLK to BCLK, or divide the MCLK by 2, then send to BCLK (because the damn SAI peripheral does not support frames longer than 256fs - which is just PURE EVIL STUPID).

The above however can not be done. SAI can not generate the FS (frame sync) when in slave mode. I would need to generate both BCLK and FS using external circuitry.

Generating the FS signal is not unfortunately easy, using just pure logic. (I'd need at minimum an 8bit counter and other logic gates).

Do you have any interesting suggestion how to solve this? Have you ever been in a similar situation with STM32?

What I came up with so far are these:

A) ditch the HW I2C peripheral, use the I2S_CKIN.   Ouch!!! Having to maintain a touch screen controller using software I2C. Evil! (Like if the HW I2C peripheral wouldn't be evil enough by itself!)

B) use a small CPLD (greenpak enyone?) to fix the damn ***  ... ouch!! There is not much space left on the PCB, even for a small  CPLD.

C) This one came to mind just while writing this rant! I could probably find a couple pins left with a timer on them to produce the FS signal, synchronously to the BCLK!

D) any other ideas anyone?  :-//

Thanks for thoughts and comments. Feel free to add a rant on STM32 afio mapping.  :box:
Y.
 
 

Online ajb

  • Super Contributor
  • ***
  • Posts: 1563
  • Country: us
Re: #RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!
« Reply #1 on: March 14, 2019, 12:13:18 pm »
You forgot to mention how all of the high speed interfaces are split up among all four sides of the QFP packages.  And how the RMII REFCLK is right in the middle of all of the analog pins.

Here's an STM32H7 project I've been fooling around with, the idea was to build a system that brings out both USB ports, a good size LCD, ethernet, SD, and gobs of memory to play with.  The buses don't really clarify anything except what it will be like to route this thing.   I had to give up the top two FMC address lines to get Ethernet.  ~16 IOs left to cover SWD, one I2C interface, two UARTs, two user buttons and one LED.  One DAC channel is free, so I guess I'll have mono audio because there's no way I'm getting I2S or SAI.

 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 1539
  • Country: fi
Re: #RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!
« Reply #2 on: March 14, 2019, 09:18:36 pm »
Your rant is spot on. The new STM32H7 has a full DMA connectivity matrix, thank god, but on all older/smaller parts, the totally braindead DMA channel mappings add to the pain, even if you were able to manage the AF mapping.

I'd consider bit-banging the I2C. For good performance, you may need some optimization trickery (possibly asm), but that tends to be somewhat entertaining, at least when compared to fighting with the peripherals or peripheral mapping. You get what you write.
 

Online OwO

  • Regular Contributor
  • *
  • Posts: 168
  • Country: cn
  • Hewwo, I'm Gabwiel from OwOComm!
Re: #RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!
« Reply #3 on: March 14, 2019, 11:11:48 pm »
That's why I don't like to fuck with doing multiple I/O interfaces on a mcu. I2C and SPI are always bitbanged, and if I really need to multitask I use an FPGA. The only point of using a mcu ever is price, so if an application calls for a > $4 mcu I'll just switch to a Spartan 6 instead.
Hewwo, w-welcome to OwOComm headqwarters, yuw can call me Gabwiel! UwU It's abowt time I intrwoduce yuw to a-an exciting worrld ow commuwnication systwems!
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 2399
  • Country: it
Re: #RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!
« Reply #4 on: March 14, 2019, 11:19:50 pm »
PIC32 and ATSAM tend not to have these issues, the pinouts and remap matrix are much less retarded

(Don't mind me i'm just throwing some fuel to the fire)
 
The following users thanked this post: splin, MT

Offline langwadt

  • Super Contributor
  • ***
  • Posts: 1117
  • Country: dk
Re: #RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!
« Reply #5 on: March 15, 2019, 12:03:37 am »
can you use one of the timers to generate the missing signals?
 

Online krho

  • Regular Contributor
  • *
  • Posts: 196
  • Country: si
Re: #RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!
« Reply #6 on: March 15, 2019, 03:20:13 am »
If you have 4 layer board, then take a look at 216 BGA with 0.8 pitch.
 

Offline colorado.rob

  • Regular Contributor
  • *
  • Posts: 186
  • Country: us
Re: #RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!
« Reply #7 on: March 15, 2019, 04:07:00 am »
The only point of using a mcu ever is price, so if an application calls for a > $4 mcu I'll just switch to a Spartan 6 instead.
Eh... power consumption is a big killer on FPGAs.  I have not found an FPGA with the power of a Cortex-M4F that can run with the same current consumption -- or go into standby for under 1uA while keeping an RTC running and an SRAM bank active.  I can do a ton of DSP calculations with only 8mA on the M4F.

I'd love to be proven wrong on this as I do battery powered devices and power consumption has been the one thing keeping me from falling completely in love with FPGAs.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 2941
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: #RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!
« Reply #8 on: March 15, 2019, 04:30:57 am »
I have, at times, found the pinout of V3s making more sense than STM32 in some cases - I do mean that V3s, the Allwinner Cortex-A7 chip in TQFP-128 that has 64MB built-in SDRAM.

For those high end STM32 that supports graphics, a stack of V3s + AXP209 + GD25Q128 is often cheaper. There is almost no pin conflicts on V3s - in fact there is little pin multiplexing to begin with. And V3s has built-in PHY for Ethernet. And it has a 1.2GHz core instead of a ~200MHz one. And the core in question is the much higher end Cortex-A7 instead of a Cortex-M core.

Power consumption of V3s compared to a STM32 is bad, but for the sake of ease of development I would prefer it over STM32 for graphics. Also for my V3s projects I almost always start with stock Debian + mainline Linux kernel, and program it just like a standard Linux PC or even in a few cases as a Mac (when I used GNUstep for the GUI components, which is somewhat compatible with macOS)
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1100
  • Country: us
  • Yes, I do this for a living
Re: #RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!
« Reply #9 on: March 15, 2019, 07:23:33 am »
That's why I don't like to fuck with doing multiple I/O interfaces on a mcu. I2C and SPI are always bitbanged, and if I really need to multitask I use an FPGA. The only point of using a mcu ever is price, so if an application calls for a > $4 mcu I'll just switch to a Spartan 6 instead.

There's a lot to be said for gluing a small FPGA to a micro's EMIF (or whatever they call the external memory) port, if you still need whatever features the micro offers.

I've run into issues similar to Yansi's ... like on the LPC18xx parts, I wanted to use a couple of peripherals and the I2S port, but no can do -- something was blocking the pin selection (it was awhile ago, I don't remember the details). It's all maddening.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5130
  • Country: nl
Re: #RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!
« Reply #10 on: March 15, 2019, 08:15:30 am »
There is always something you want extra or need that is not available no matter how large the micro.
Be glad you caught it in time.
 

Offline MT

  • Frequent Contributor
  • **
  • Posts: 958
  • Country: fo
Re: #RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!
« Reply #11 on: March 15, 2019, 08:58:57 am »
Do you have any interesting suggestion how to solve this?

I used a DAC that had inbuilt MCLK PLL as to avoiding routing MCLK across analog traces and saving 1 pin! :scared: :phew:

Quote
>Have you ever been in a similar situation with STM32?
Continuously for perhip I/O mapping, there is no end . :box:..... With Xtal 8Mhz i get 12.20Mhz! Noooooo! hehe!

STM32F446 have better updated SAI-I2S block and GPIO mapping then F429. Example F446V LQFP100 PC9/I2S2 is remapable to PB10 PB13 PD3, while on F446Z cant be remapped according to STCUBE but i have found softbugs in Cube with other devices while per datasheet a peripheral could do what Cube denied. ^-^
« Last Edit: March 15, 2019, 10:29:46 am by MT »
 

Offline chickenHeadKnob

  • Frequent Contributor
  • **
  • Posts: 714
  • Country: ca
  • doofus programus semi-retiredae
Re: #RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!
« Reply #12 on: March 15, 2019, 11:45:41 am »
PIC32 and ATSAM tend not to have these issues, the pinouts and remap matrix are much less retarded

Not just Atmel/Microchip, virtually every other company gets it better than ST, especially when you go to smaller packages. I understand they put the same die in smaller packages and simply don't bond out some functions, still no excuse. Cypress Psoc4 and 5 are quite reasonable in the pin assignments, especially if all you want is some parallel GPIO on the same side of small package. How hard can this be, ST? (rhetorical ques)

Quote from: Technix
I have, at times, found the pinout of V3s making more sense than STM32 in some cases - I do mean that V3s, the Allwinner Cortex-A7 chip in TQFP-128 that has 64MB built-in SDRAM.

I wish I could find and buy these from a normal supplier, they are disappearing from aliexpress and I am reluctant to order from there as I have been cheated by a  dodgy seller.

 

Online OwO

  • Regular Contributor
  • *
  • Posts: 168
  • Country: cn
  • Hewwo, I'm Gabwiel from OwOComm!
Re: #RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!
« Reply #13 on: March 15, 2019, 01:31:40 pm »
Why the ふぁっく are fixed pin assignments for SPI and I2C still a thing in this day and age? The ESP32 has a full GPIO crossbar that allows assigning almost any pin to any peripheral function even for high speed peripherals like the I2S/camera port. But every micro I've seen still has fixed pins for I2C?
Hewwo, w-welcome to OwOComm headqwarters, yuw can call me Gabwiel! UwU It's abowt time I intrwoduce yuw to a-an exciting worrld ow commuwnication systwems!
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf