Forums

Is an STM32F437VGT7 an exact plug-compatible superset of STM32F417VGT6?

Started by Peter November 20, 2019
Sorry to ask this rather obscure Q but ST "engineering" is not really
contactable via any normal means...

It looks like a superset in every way, comparing the data sheets.

They even made the 2MB of flash in the 437 as two 1MB banks, which
rather defeats the point of having 2MB unless you can generate "large
model" code like one used to do with the old Z80 etc if wanting to
have > 64k of code. It's really naff. It likely limits the usage of
the extra 1MB to storing copies of backup (known working) firmware,
and such like.
On 20.11.19 17:51, Peter wrote:
> Sorry to ask this rather obscure Q but ST "engineering" is not really > contactable via any normal means... > > It looks like a superset in every way, comparing the data sheets. > > They even made the 2MB of flash in the 437 as two 1MB banks, which > rather defeats the point of having 2MB unless you can generate "large > model" code like one used to do with the old Z80 etc if wanting to > have > 64k of code. It's really naff. It likely limits the usage of > the extra 1MB to storing copies of backup (known working) firmware, > and such like.
It seems that you have misunderstood the flash banks. A STM32 has 32 bits of address, enough to address over 4000 megabytes. When reading (or running code from), the banks are shown as one contiguous chunk of memory. The banks are only significant when writing to the flash, and the programming tools do know baout the banks. The idea of having two flash banks is to keep one alive when erasing or writing the other bank. -- -TV
Peter <nospam@nospam9876.com> writes:

> Sorry to ask this rather obscure Q but ST "engineering" is not really > contactable via any normal means...
I've gotten excellent support from their sales and FAEs in workshops and exhibitions. (Especially after doing one high volume project)
> It looks like a superset in every way, comparing the data sheets.
I did a quick check on the shared (which indicates very close design) reference manual index. It looks like there are differences in flash, power management (RCC) and related sysconfig. Also, they've got different datasheets, so there might be differences in electrical specs, especially since they not that F42x/F43x has much lower power consumption.
> They even made the 2MB of flash in the 437 as two 1MB banks, which > rather defeats the point of having 2MB unless you can generate "large > model" code like one used to do with the old Z80 etc if wanting to > have > 64k of code. It's really naff. It likely limits the usage of > the extra 1MB to storing copies of backup (known working) firmware, > and such like.
I don't understand why this would be a problem. The flash is visible as a linear adress space and the differences are mostly in how it's divided in blocks. An even if the two banks would be in different addresses, that's simple do manage in linker script. It's not like you'd need to switch the bank on the fly, like in old stuff. I really like the way you can use SCB->VTOR to switch vector tables when having current and updated firmware available. If I had some data blocks and especially updates for bootloader, having 1:1 flash structure might be a benefit. Or maybe they just did a cut&paste for the flash part and called it a day. -- mikko
Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote

>It seems that you have misunderstood the flash banks. A STM32 has >32 bits of address, enough to address over 4000 megabytes. When >reading (or running code from), the banks are shown as one contiguous >chunk of memory. > >The banks are only significant when writing to the flash, and the >programming tools do know baout the banks. > >The idea of having two flash banks is to keep one alive when erasing >or writing the other bank.
OK; I get it - thank you. We did find that the 417 cannot run code from the flash while programming the flash. You have to copy code to RAM and run it there.
Peter <nospam@nospam9876.com> wrote:
> > We did find that the 417 cannot run code from the flash while > programming the flash. You have to copy code to RAM and run it there.
You do not need to find it, it is documented behaviour. With two banks, you can flash one bank from the other. For the differences, https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html is a start. MCUFinder get's you further, reference manuals and application note even further. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> wrote

>Peter <nospam@nospam9876.com> writes: > >> Sorry to ask this rather obscure Q but ST "engineering" is not really >> contactable via any normal means... > >I've gotten excellent support from their sales and FAEs in workshops and >exhibitions. (Especially after doing one high volume project) > >> It looks like a superset in every way, comparing the data sheets. > >I did a quick check on the shared (which indicates very close design) >reference manual index. It looks like there are differences in flash, >power management (RCC) and related sysconfig. Also, they've got >different datasheets, so there might be differences in electrical specs, >especially since they not that F42x/F43x has much lower power consumption.
Thank you very much! Now that is REALLY interesting. However the data sheets don't support that. The 417 draws less current. For example, 168MHz, all peripherals enabled, 25C, 87mA versus 98mA. The RTC draws much less on the 437 though. 0.66uA versus 2.4uA. Sounds like a lot of people told them 2.4uA is way too much for a lithium cell, and a supercap lasts only a day or two.
>> They even made the 2MB of flash in the 437 as two 1MB banks, which >> rather defeats the point of having 2MB unless you can generate "large >> model" code like one used to do with the old Z80 etc if wanting to >> have > 64k of code. It's really naff. It likely limits the usage of >> the extra 1MB to storing copies of backup (known working) firmware, >> and such like. > >I don't understand why this would be a problem. The flash is visible as >a linear adress space and the differences are mostly in how it's divided >in blocks. An even if the two banks would be in different addresses, >that's simple do manage in linker script. It's not like you'd need to >switch the bank on the fly, like in old stuff.
Yes; I get this, from Tauno's post.
>I really like the way you can use SCB->VTOR to switch vector tables when >having current and updated firmware available. If I had some data blocks >and especially updates for bootloader, having 1:1 flash structure might >be a benefit. > >Or maybe they just did a cut&paste for the flash part and called it a day.
The data sheets differ quite a lot. On a very quick look, the 180MHz mode on the 437 is achieved by winding up the internal supply voltage a bit. There is a significant settling time involved there. They call it "over drive". I spotted a very subtle difference on the internal temp sensor. On the 437 it can somehow also measure Vbat, using the same ADC channel, which is weird. There must be a mux. Also you don't want to draw ADC IN current from Vbat. Probably a lot of small differences.
Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> wrote

>Peter <nospam@nospam9876.com> wrote: >> >> We did find that the 417 cannot run code from the flash while >> programming the flash. You have to copy code to RAM and run it there. > >You do not need to find it, it is documented behaviour. With two >banks, you can flash one bank from the other. For the differences, >https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html >is a start. MCUFinder get's you further, reference manuals and >application note even further.
We didn't have to discover it literally :) It is known with all flash/eeprom devices which use special programming procedures that you cannot run code from them during programming. I did discover it many years ago with a 32k x 8 EEPROM :)
On 21/11/19 7:55 am, Peter wrote:
> > Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> wrote > >> Peter <nospam@nospam9876.com> wrote: >>> >>> We did find that the 417 cannot run code from the flash while >>> programming the flash. You have to copy code to RAM and run it there. >> >> You do not need to find it, it is documented behaviour. With two >> banks, you can flash one bank from the other. For the differences, >> https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html >> is a start. MCUFinder get's you further, reference manuals and >> application note even further. > > We didn't have to discover it literally :) It is known with all > flash/eeprom devices which use special programming procedures that you > cannot run code from them during programming.
That's exactly why there are two banks. Either can be written while running code from the other.
On Wed, 20 Nov 2019 19:38:32 +0200, Tauno Voipio
<tauno.voipio@notused.fi.invalid> wrote:

>On 20.11.19 17:51, Peter wrote: >> Sorry to ask this rather obscure Q but ST "engineering" is not really >> contactable via any normal means... >> >> It looks like a superset in every way, comparing the data sheets. >> >> They even made the 2MB of flash in the 437 as two 1MB banks, which >> rather defeats the point of having 2MB unless you can generate "large >> model" code like one used to do with the old Z80 etc if wanting to >> have > 64k of code. It's really naff. It likely limits the usage of >> the extra 1MB to storing copies of backup (known working) firmware, >> and such like. > > >It seems that you have misunderstood the flash banks. A STM32 has >32 bits of address, enough to address over 4000 megabytes. When >reading (or running code from), the banks are shown as one contiguous >chunk of memory. > >The banks are only significant when writing to the flash, and the >programming tools do know baout the banks. > >The idea of having two flash banks is to keep one alive when erasing >or writing the other bank.
The ST that we are using, STM32F207, has 1 Mbyte of flash divided into 12 sectors of various sizes. I think one can erase and write individual sectors. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
onsdag den 20. november 2019 kl. 22.36.37 UTC+1 skrev John Larkin:
> On Wed, 20 Nov 2019 19:38:32 +0200, Tauno Voipio > <tauno.voipio@notused.fi.invalid> wrote: > > >On 20.11.19 17:51, Peter wrote: > >> Sorry to ask this rather obscure Q but ST "engineering" is not really > >> contactable via any normal means... > >> > >> It looks like a superset in every way, comparing the data sheets. > >> > >> They even made the 2MB of flash in the 437 as two 1MB banks, which > >> rather defeats the point of having 2MB unless you can generate "large > >> model" code like one used to do with the old Z80 etc if wanting to > >> have > 64k of code. It's really naff. It likely limits the usage of > >> the extra 1MB to storing copies of backup (known working) firmware, > >> and such like. > > > > > >It seems that you have misunderstood the flash banks. A STM32 has > >32 bits of address, enough to address over 4000 megabytes. When > >reading (or running code from), the banks are shown as one contiguous > >chunk of memory. > > > >The banks are only significant when writing to the flash, and the > >programming tools do know baout the banks. > > > >The idea of having two flash banks is to keep one alive when erasing > >or writing the other bank. > > The ST that we are using, STM32F207, has 1 Mbyte of flash divided into > 12 sectors of various sizes. I think one can erase and write > individual sectors.
yes but you cannot read from flash while you are doing it, so if you run code from flash the cpu stalls for microseconds while writing, milliseconds while deleting if the application can handle that, no problem