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

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.

Reply to
Peter
Loading thread data ...

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
Reply to
Tauno Voipio

I've gotten excellent support from their sales and FAEs in workshops and exhibitions. (Especially after doing one high volume project)

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.

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
Reply to
Mikko OH2HVJ

Tauno Voipio wrote

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.

Reply to
Peter

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,

formatting link
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 
 Click to see the full signature
Reply to
Uwe Bonnes

Mikko OH2HVJ wrote

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.

Yes; I get this, from Tauno's post.

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.

Reply to
Peter

Uwe Bonnes wrote

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

Reply to
Peter

That's exactly why there are two banks.

Either can be written while running code from the other.

Reply to
Clifford Heath

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  
 Click to see the full signature
Reply to
John Larkin

onsdag den 20. november 2019 kl. 22.36.37 UTC+1 skrev John Larkin:

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

Reply to
Lasse Langwadt Christensen

Lasse Langwadt Christensen wrote

Is the "stalling" actually implemented with wait states, or does the CPU just crash?

Normally, if you run code from a normal external eeprom or flash chip, and you start writing to it, the CPU instantly crashes.

If the ST implements wait states, that would actually be OK in most applications, because it can hardly do anything else that's useful.

Reply to
Peter

Lasse Langwadt Christensen wrote

What happens in the STM32F437VGT7? Does the CPU get wait states while writing the other flash bank?

What happens in the STM32F417VGT6? Does the CPU get wait states or does it crash?

Reply to
Peter

It is stalling.

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de 

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt 
 Click to see the full signature
Reply to
Uwe Bonnes

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.