#RANT + #HILFE! STM32 damn SAI and AFIO mux failery. Fack!

[Yansi]

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). 

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.

... 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. 
Y.
 

[ajb]

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.

[Siwastaja]

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.

[OwO]

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.

[JPortici]

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)

[langwadt]

can you use one of the timers to generate the missing signals?

[krho]

If you have 4 layer board, then take a look at 216 BGA with 0.8 pitch.

[colorado.rob]

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.

[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.

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)

[Bassman59]

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.

[Kjelt]

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.

[MT]

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!

>Have you ever been in a similar situation with STM32?

Continuously for perhip I/O mapping, there is no end . ..... 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.

[chickenHeadKnob]

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)

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.

[OwO]

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?

[Yansi]

So, thanks guys for ranting and chanting, PCBs should arrive on tuesday (should.. do you hear me, DHL?)

I have used a TIM to count BITCLK (connected to ETR input) and generate the FSYNC signal, using PWM mode. So we'll see if it'll work.  After paying 60+% of VAT on that little package of poor 5 PCBs, it'll better work or I beat the shit out of it (and DHL too). 

[AndyC_772]

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?

IIRC, true I2C interfaces have Schmitt trigger inputs with defined thresholds. That hardware isn't free and simply doesn't exist on any pins other than the I2C pins. Putting it on every pin would be a waste.

[Yansi]

There are schmitt inputs on every STM32 input, if I am informed right. They may not have the most suitable thresholds set, but they are there.

[OwO]

IIRC, true I2C interfaces have Schmitt trigger inputs with defined thresholds. That hardware isn't free and simply doesn't exist on any pins other than the I2C pins. Putting it on every pin would be a waste.

Yeah well when your MCU costs more than a Spartan 6 FPGA which has ~100 full featured IOs I expect better than that. Much better than that actually. I won't be using a >$3 MCU in any product until they can offer me value at least on-par with a $4 Spartan 6. The amount of engineer hours it takes to troubleshoot esoteric crap in the STM32 I/O and AFIO garbage alone makes even the $1 MCU unattractive at least until higher volumes.

[Kjelt]

Yeah well when your MCU costs more than a Spartan 6 FPGA which has ~100 full featured IOs I expect better than that. Much better than that actually. I won't be using a >$3 MCU in any product until they can offer me value at least on-par with a $4 Spartan 6. The amount of engineer hours it takes to troubleshoot esoteric crap in the STM32 I/O and AFIO garbage alone makes even the $1 MCU unattractive at least until higher volumes.

I don't get your point. Does your Spartan6 have an Cortex M in it with 128kB RAM and 1024kB flash?
What are you talking about then? There are billions of STM32 sold and used in the world in high volume production lines of the largest companies, are they stupid? No they have usecases a Spartan can not handle.
Each has its owm merits AFAIAC and can be used for its own special domains but these are not just comparable chips you can interchange. Try to port an IP stack on your spartan with TLS security, good luck on your mission.

[OwO]

What I'm saying is when you are selling a MCU for $10 I expect better IO features, not fixed SPI/I2C pins, or the excuse of a "remap" feature the STM32 has. Even the $3 ESP32 has a full IO crossbar, and timings aren't an excuse either because the ESP32 IOs can handle high speed I2S.

[Yansi]

I wouldn't consider I2S a hi-speed bus. That's as good as standard SPI gets. (couple tens of mbits)

It  is a big difference to make a full crossbar for a small chip with couple of pins  with just couple of peripherals, and completely different to do it on a high performance chip designed for 200+  IOs and tens of peripherals, with real high speed interfaces such as SDIO, QSPI, SDRAM, USB, ETH etc.

Full crossbar would be lovely, however putting a bit of thought even to the current AFIO mapping would provide so much better results.

[OwO]

The "I2S" peripheral on the ESP32 is not just for I2S as in the audio protocol. It's also used to attach cameras and can run at many tens of MHz.

It does not take much resources to implement full GPIO multiplexing, it doesn't need to be an actual crossbar with N^2 switches. The Clos and Benes switch architectures allow implementing fully multiplexed IOs with a circuit complexity of order N log N. In an FPGA this is rarely a problem and FPGAs have much more IOs than these MCUs.

[Kjelt]

What I'm saying is when you are selling a MCU for $10

that is probably the one of, end customer price.
The price for large quantities will be below $2,50