32F417 / 32F437 auto detect of extra 64k RAM

[AVI-crak]

I don't understand the meaning of the conversation.
Any project with a physical layer is strictly tied to a specific chip. And in some cases there is a link to the chip version of a particular model - as it has a different number of errors, and very different behavior.
The year the chip was made is important!!!
The project simply won't work on another chip.
In the case of using the IDE from ST - you must specify the version of the IDE!!!

If you failed to debug the project in two months, then it is useless to work further. Old projects with an iron level are also dying. In the case of the ST company, the one who runs the fastest wins.

In order for the project not to lose its relevance over the years, you need to get rid of the iron level, from changing software, from rigid binding to a specific chip.
Oh yes, write in pure C - it is eternal.

[peter-h]

The year the chip was made is important!!!
The project simply won't work on another chip.

How?

[nctnico]

The year the chip was made is important!!!
The project simply won't work on another chip.

How?

I guess AVI-crak is referring to different versions of the same chip that may or may not have fixes for silicon bugs. But since you can read the chip revision from the chip, you can determine which silicon bugs you need to work around and which are fixed. But it does take extra software.

[Nominal Animal]

I guess AVI-crak is referring to different versions of the same chip that may or may not have fixes for silicon bugs. But since you can read the chip revision from the chip, you can determine which silicon bugs you need to work around and which are fixed. But it does take extra software.

Yes.  If the chip can be identified before compile time, and its bugs described via preprocessor macros, then one can save RAM/Flash use by only including the required workarounds.

This is nothing new, because standard C libraries on Linux and BSDs have had to do exactly this for decades.  It is why one configuration parameter is kernel version; features available in all later versions are assumed to be available, to limit the set.  Granted, instead of checking the kernel version, the standard C libraries use a fallback-and-flag mechanism, because unsupported syscalls return a special "Not implemented" error code.  (That is, if say openat syscall ever returns not implemented, the C library will fall back to internal path mangling and using open syscall from that point onwards.)

At the source code level, modularization helps a lot here.  You need to write the low-level hardware-access layer to abstract out the hardware differences.  I do not like using HAL for these, because their abstractions are generic; but the abstractions actually needed depend on what the software needs.  That is, the abstractions should be designed based on what the software needs, and not based on what the various hardware provides: the opposite way vendors like ST design their HALs.

Design-wise, it is a lot of work, because you have to simultaneously consider both top-down (ie. what the final software needs, to perform its functions) and bottom-up (ie. what the differences are or may be between the hardware versions this software will run on).  Also takes quite a bit of experience to know what matters in practice, and so on.

Note that I am not claiming that doing it this way makes any business sense; I am only describing what is technically possible and done in other similar circumstances.

[peter-h]

I would be amazed if any of my code relies on some CPU bugs having been fixed.

How long has a 32F417 been out? I bought my main stock in 2019, before covid came and made them unobtainable.

Edit: year 2010 approx.

[Nominal Animal]

Have you checked the errata ST provides?

[peter-h]

Yes, at various times.

Practically the whole lot describes never-fixed stuff e.g.



The yellow is never-fixed (for good reasons, obviously) and only the few shown had been fixed, like the CPU ID (fixed for good reasons, obviously!).

I would conclude that if my software, mostly either written by me or a colleague since about 2019, or based on ex ST Cube MX "HAL" code from c. 2019 (not much left of it now), works correctly, that should be OK.

Most of the stuff in the errata is not even used in my code (but some would be "interesting" if it was, like the I2S stuff) but I spotted this



and I am buggered if I know where this code is. I see FIFO related stuff in a number of places. But the entire USB code is run as an ISR so it would be a question of priorities. But maybe not since the corruption happens only if writing to the other USB regs, ints from other things should not affect it. Anyway, it does work.
 
If ST started fixing that long list, it would break a lot of software.

[nctnico]

I guess AVI-crak is referring to different versions of the same chip that may or may not have fixes for silicon bugs. But since you can read the chip revision from the chip, you can determine which silicon bugs you need to work around and which are fixed. But it does take extra software.

Yes.  If the chip can be identified before compile time, and its bugs described via preprocessor macros, then one can save RAM/Flash use by only including the required workarounds.

No, these workarounds are typically enabled / disabled at runtime to make the software more compatible with all possible hardware out there. This doesn't increase size of the software significantly because the workarounds are only a few lines of code.

[peter-h]

From the 5 pages of unfixed errata, and only a few items which were fixed, and all of those few were fixed after version 1, there is a clear policy by ST to not fix any of the stuff which is there today.

I also think, practically, that with a chip which came out in say 2010, if say UART 3 was dud, somebody would have noticed and reported it.

The ST website confirms the 32F417 with a 10 year min production life commencing 2013.
https://www.st.com/content/st_com/en/about/quality-and-reliability/product-longevity.html#10-year-longevity

[Nominal Animal]

I guess AVI-crak is referring to different versions of the same chip that may or may not have fixes for silicon bugs. But since you can read the chip revision from the chip, you can determine which silicon bugs you need to work around and which are fixed. But it does take extra software.

Yes.  If the chip can be identified before compile time, and its bugs described via preprocessor macros, then one can save RAM/Flash use by only including the required workarounds.

No, these workarounds are typically enabled / disabled at runtime to make the software more compatible with all possible hardware out there. This doesn't increase size of the software significantly because the workarounds are only a few lines of code.

That is what is most commonly done, yes (except workarounds like the stack pointer being loaded from incorrect address if an interrupt happens during the data phase using LDR SP, [Rn], #imm, with workaround being to load the value to a temporary register and from there to stack pointer, tend to be always enabled, since they are harmless on hardware that does not have the bug).

But, if the exact variant is known at compile time, they can be implemented directly, without any runtime checks or patching.  This kind of code adapting to hardware is not new, and can be also done at compile time, not only runtime, was my point.

there is a clear policy by ST to not fix any of the stuff which is there today.

Based on the errata, it definitely looks that way.

The OTG_FS and OTG_HS bugs mean there may be some USB HID devices that won't work with STM32F417 as the host.  (The only low-speed USB devices I've ever seen are some old custom HID devices, like those used in old mini numpads and old bar code readers.)

The OTG_FS_DCFG bug means when read, the DAD and PFIVL bits (4-12) may be incorrect.  The workaround is to use a 32-bit RAM variable for it, initializing it to 0x0220'0000 (it's bootup initialization value), and do the operations on the RAM variable and just copy the value to usbx->DCFG.  I don't see such a workaround in STM32CubeF4/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_usb.c at Github, though.

I didn't look at the other errata.

[SiliconWizard]

The ST website confirms the 32F417 with a 10 year min production life commencing 2013.
https://www.st.com/content/st_com/en/about/quality-and-reliability/product-longevity.html#10-year-longevity

So you're close to EOL now?

I would definitely consider switching to something newer.

As to unfixed silicon bugs, that's annoying but rather common. Silicon bugs are expensive to fix and fixes lead to revisions of the same IC with different behavior, which the customer would have to deal with at run time one way or another, which can be worse than having a workaround for a known bug and sticking to it without ever fixing the bug.

[peter-h]

The 10 year guarantee starts on Jan 2023.

And they have been renewing the 10 year period every year for the last few years.

Based on what I've seen over the last 30-40 years I reckon ST will run these chips for a total of 25-30 years, same as Hitachi have been doing. So maybe another 15 years.

Another positive factor is that the chinese have picked the 407 (417 without hardware crypto) as one of the main chips to rip off (legally or not). They might know something I can use the 407 with just one #define change in one .h file, and it works with no practical performance loss (the aes256 code in MbedTLS runs at almost 1MB/sec). The 407 is a hugely popular chip.

Re the USB thing, my product is a USB client only. The OTG mode was not implemented, not least because a) it was not needed b) it leads to unrealistic customer expectations as regards supported clients and c) available power for clients would be very limited.