In the reference manual for STM32H7 interrupt with NVIC position 123 is missing. What is the interrupt?

[Tomasz Zeman]

Reference manual for STM32H7 series (RM0433), on page 697, does not show an entry for NVIC interrupt 123.

What is the interrupt? Can the documentation be fixed by the team.

Interrupts that are not triggered by the MCU are normally marked with a line across the row.

Current errata document (June 2018 ES0396 Rev 4) does not have information about it.

[waclawek.jan]

JW

[Tesla DeLorean]

No, he means the jump between MDMA (122) and SDMMC2 (124) below.

Likely undocumented functionality, for things like DSI that don't work properly.

[waclawek.jan]

Oh I see.

That's nasty, I agree, there should be an empty line.

JW

[Tesla DeLorean]

Well it's inconsistent. Not something I'd lose sleep over, it's not as if the numbers are wrong, or misleading.

The design itself is overly convoluted for what was delivered, and the technical documentation has been frustrating (inconsistent signal names, labels on diagrams in PDF unsearchable). During the May Tech-Tour they mentioned Multi-Core and DSI support when pressed.

https://community.st.com/s/question/0D50X00009XkeAiSAJ/nucleoh743-out-of-stock (16-June 16:02 post)

[waclawek.jan]

There are three things with the documentation: one that there are minor (yet annoying, and at times causing headache) typos/omissions etc. - these are worth being labelled and corrected with the upcoming revision of the document (note that Khouloud has already put his mark on this thread so it's presumably in the pipeline by now).

The second issue are systemic problems. Some chapters (e.g. TIM) are badly structured, others (e.g. the Synopsys IPs') are next to unusable. While the former might be rewritten with an internal effort, the latter was bought thus apparently there's no incentive to spend internal money on it.

The third issue is that much documentation is simply missing - not only a decent bridge to ARM's documentation (heavily diluted and fragmented and so notoriously hard to read that they own employee made a side business from rewriting it into readable form), but also appnotes, which now cover only a ridiculously small area of use.

I understand ST's stance on spending as little on documentation of the older chips as possible and simply milk them as much as possible; OTOH the recycling character of creating the new chips' documentation together with explosion of their complexity leads to disaster.

(Here, I wanted to link to my previous rant on the topic, but it hasn't been migrated (yet?) - https://st-microelectronics.jiveon.com/thread/46022-is-there-money-for-better-documentation-and-more-support )

> labels on diagrams if PDF unsearchable

This is a long-lasting problem in many if not all STM32 pdfs. This will be a similar problem to the forum - once a corporation starts to use other corporation's software product, it invests a significant amount of money/time/training/etc. into it and gets locked, so that the supplier can then easily avoid correcting defects which are not apparent at the beginning.

JW

[Tesla DeLorean]

ST is creating a lot of work for itself. The exploding number of STM32 parts and families, and increasing inconsistency in how they all function, along with the software bulking up to handle that, or complexity it causes in the software libraries to provide uniformity in operation, is an enormous and expanding task.

The H7 is a significantly more complicated part than anything else that has been delivered in the STM32 family, and I think the guys with a grasp on the IC/gate level implementation are getting far more distant from the technical writers who are left to cull the documentation from multiple IP vendors and sources, removing sensitive or option information. Again an issue of how it is difficult to provide uniformity, both with regard to style and level of informational content.

ST is also still organized to deal with large commercial clients, they don't have a way to bill for support or NRE to smaller clients, and really flat footed when it comes to makers. The DISCO and NUCLEO boards are very aggressively priced, so will get into the hands of many people, but organizationally they don't seem to have the depth of staff to adequately support those people. Throwing "The Monkey Presses the Button" software at the problem side steps some of the teething issues, but it doesn't make those people any smarter or knowledgeable about the mechanics.

[Khouloud GARSI]

Hello,

• Many thanks Tomasz for bringing this to our attention. This will be rectified in the next release of the reference manual.
• Gentlemen, we really appreciate your comments/contributions and we're trying our best to report all of your feedback internally in order to fix/enhance our documentation.

Khouloud.

[waclawek.jan]

> organizationally they don't seem to have the depth of staff to adequately support those people

But that's exactly why generating proper documentation is a win-win situation. It caters for the corporate clients too, potentially cutting down the direct support (which even if billed is probably not the way ST wants to make profit); and even if the garage-scale clients or makers come here or elsewhere for "public" help, its much easier to direct them to existing appnotes or a good description in the DS/RM/wherever, than try to create that sometimes even reverse engineering the chips' internals. Heck, bad documentation hampers their own support too!

I keep stressing that I understand how hard task it is; my point is that it's a worthy effort to focus on.

2 eurocents.

JW

[LMI2]

Almost off-topic but how many programming styles or interfaces there are now for STM32 chips. SPL, obsolete or not? Examples, low level, and Cube HAL. What it is going to be.