STM32U5A5: LQFP64 (STM32U5A5RJT6Q) - SAI2_SD_A, SAI2_SD_B - why not available?

[tjaekel]

I could cry... ("rrrr", the more I dive into latest STM MCUs - the more I get frustrated - LOL)

The datasheet for STM32U5A5, LQFP64 package, tells me: there are PB15 as SAI2_SD_A and also PC12 as SAI2_SD_B.

But the CubeMX does not let me configure these signals as SAI2: I need just one pin (one of them, preferred as PB15 = SAI2_SD_A, for a S/PDIF output).

But:

• if I load and see the features of this STM32U5A5, LQFP64 package in CubeMX:
  it tells me just SAI = 1
  - it is actually not true: the datasheet shows me a complete signal set "possibility" for SAI2 as I2S!
  - SAI2_A and SAI2_B are complete on the STM32U5A, even for this package!
• if I try to configure pins, e.g. PB15 as SAI2_SD_A, or PC12 = SAI2_SD_B:
  the SAI2 features for these pins are not there (not in list) - using CubeMX

Is this a "bug" in the CubeMX tool? (I hope so!)
Or:
based on datasheet - still possible to use SAI2 and one pin as SAI2_SD_A or SAI2_SD_B as a S/PDIF output?
How to generate code for SAI2_SD_x as S/PDIF output? (assuming, changing to a different package just for code generation).
Assuming (hoping) just the CubeMX software is wrong - but the chip has a complete SAI2.

It is very confusing: the datasheet tells me something which is not correctly reflected in CubeMX.

Dear STM team:

• is there an SAI2 available in STM32U5A5 LQFP64 package? (I think so, or your datasheet would be so wrong)
• can I use SAI2_SD_A (PB15) or SAI2_SD_B (PC12) still for S/PDIF Tx?
  (even your CubeMX does not "allow" me to configure - reporting this issue here also as a "bug")

[tjaekel]

OK, I will try to configure these SAI2 pins for S/PDIF out (manually) and will provide an update here.
It is just "frustrating" that features in datasheet are not supported by CubeMX. I just hope that the Cube_HAL drivers are supporting what I need (never spent so much time on a STM32 MCU to bring it up, spending more time meanwhile to find all the "bugs"...).

[KDJEM.1]

Hello @tjaekel ,

Thank you for this feedback. The STM32U5A5RJT6Q (LQFP64) have one SAI as mentioned in the datasheet table 2 based on that it didn’t have an SAI2.

The "STM32U5Axxx pin/ball definitions (1)" table  covers all IP available on that pin regardless of package. The customer should be referred to availability of IP on his product package. This behavior is explained by this note: 

"1. Function availability depends on the chosen device."

Thanks and best regards,

Kaouthar

[tjaekel]

Thank you.
I have not seen table 2 (telling me just one SAI) - OK, got it.
But the pin/ball definitions give me the conclusion, that available pins would even support SAI2.

Just curios:
How is your pad ring working? If a pin is not connected/populated (because of a smaller package) then it is obvious that this function (ALT) is not available.
But if there is PB15 and the pinmux table lists also as SAI2_SD_A - how is just the SAI2_SD_A feature "removed"?
Do you have bonding options on the padring, an internal bump to enable/disable SAI2? (maybe, SAI2 might be still there but powered down internally).

"Hmmmm": so I have to change to a LQFP100 package (just for this "missing" SAI2).

[tjaekel]

I think: the STM32U5A5 datasheet is wrong:

• I can configure PC12 on a LQFP64 package (STM32U5A5RJT6Q) as SAI2_SD_B (for S/PDIF)
• I see the signal coming out

So, the statement that STM32U5A5RJT6Q has just one SAI1 does not seem to be true:
SAI2 works as well!

[KDJEM.1]

Hello @tjaekel ,

Thank you for bringing this issue to our attention.

I will check internally  and I will get back to you with more details as soon as possible.

Kaouthar

[KDJEM.1]

Hi @tjaekel ,

Thank you for you feedback.

Even if SAI2_SD_B and SAI2_SD_A work, but they are not guaranteed to be functional since they aren’t tested in production.

Thank you.

Kaouthar

[tjaekel]

Thank you.
I saw it working once (but with a lot of audio artefacts). Now, I cannot replicate anymore: even I see the SPDIF signal coming out - I cannot receive it. I might need a SPDIF decoder on scope (or another STM board with SPDIF RX, just to figure out what is wrong, via checking Rx status and data). I assume, the clock config is not yet correct or the handling of the CS, U, V bits.

When you say "not tested": I understand that datasheet says for STM32U5A5 LQFP64 package just one SAI1, not SAI2 (even some pins for SAI2 are there). But the LQFP100 has support for both SAIs. Why SAI2 should not be tested? If it works for LQFP100 package - then it should work also on LQFP64 package, shouldn't it?

Maybe, I try SAI2_A as I2S, the pins are there (PB13, PB15, PC0). For SAI2_B, the SAI2_FS_B is missing on LQFP64.

[tjaekel]

even not working yet (SPDIF on SAI2_B) - I think the HAL driver has an issue to configure the SPDIF clock properly.
(a separate thread following)