STM32 F7 Series: The World’s First ARM Cortex-M7 Core-Based MCUs

[waclawek.jan]

Posted on September 24, 2014 at 19:01

[duplicated thread due to locked thread above]

Impressive, looking forward to real silicon.

Nice:

- all clocks apper to be able to tick up to 200MHz

- low-power timer running independently of the main clock (i.e. also in stop mode)

- quad SPI

Things which made me sad at the first glance:

- ST chose to omit double-precision from the FPU

- up to 1MB FLASH may turn out to be a severe limitation

- there's a gotcha in the ''fully pin-to-pin compatibility to 'F4'': LQFP100 has a shifted row of pins

Question: Will there be DISCOVERY board? If yes, will it be same or different as the existing '429/439 one?

JW

#whiskey-tango-foxtrot

[Tesla DeLorean]

Posted on September 24, 2014 at 21:42

The [DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32%20F7%20Series%20The%20World%E2%80%99s%20First%20ARM%20Cortex-M7%20Core-Based%20MCUs&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&TopicsView=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/AllItems.aspx&currentviews=12]locked thread

Yes, seems a little odd there isn't 1 and 2 MB out of the gate.

A proper cache architecture does however suggest the SDRAM might be a viable place to unpack code, either from internal flash, serial SPI flash, or SD Card

The LQFP100 stuff is just wrong. Pins 18 thru 25 aren't like the diagram on

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/data_brief/DM00116941.pdf

, and surely there was a less broken way of doing this?

[Tesla DeLorean]

Posted on September 24, 2014 at 21:50

[waclawek.jan]

Posted on September 25, 2014 at 09:30

I guess the new core ate up the silicon area of the second MB FLASH while hitting some technological (mask stepping/dicing/packaging) size limit.

> A proper cache architecture does however suggest the SDRAM might be a viable

Viable maybe, but certainly suboptimal. Not only is it inevitably slower (cache helps but is no panacea) and decreases security; it also eats the pins, which in case of  applications utilizing majority of the peripherals may be an asset potentially counterweighing even a drastical price increase for the extra FLASH, or a multi-chip package (ST has or had the know-how - they used to use it in the uPSD3xxx line).

> The LQFP100 stuff is just wrong. Pins 18 thru 25 aren't like the diagram on

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/data_brief/DM00116941.pdf

,

> and surely there was a less broken way of doing this?

No wonder, once they can't draw a proper diagram... :(

JW

[Tesla DeLorean]

Posted on September 26, 2014 at 23:15

Things which made me sad at the first glance:

 

- ST chose to omit double-precision from the FPU

 

Yes, that would be a frustrating omission, because the performance isn't going to be orders better than a M4 @ 180 MHz. With double precision you'd have somewhere to tie your flag compared to competitive solutions.

ARM also suggests it should have single AND double precision, and as it is the CORE is quite small contrasted to the FLASH, RAM and PERIPHERALS, so you'd think having doubles would be a reasonable trade-off. Thermal Issues?

http://www.arm.com/products/processors/cortex-m/cortex-m7-processor.php

''Single and double precision floating point unit IEEE 754 compliant''

http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1858/LN1902/PF260794

''The STM32F756xx devices are based on the high-performance ARM®Cortex®-M7 32-bit RISC core operating at up to 200 MHz frequency. The Cortex®-M7 core features a single floating point unit (SFPU) precision which supports all ARM® single-precision data-processing instructions and data types. It also implements a full set of DSP instructions and a memory protection unit (MPU) which enhances application security.''

[waclawek.jan]

Posted on September 29, 2014 at 09:28

> ARM also suggests it should have single AND double precision, and as it is the CORE is

> quite small contrasted to the FLASH, RAM and PERIPHERALS, so you'd think having

> doubles would be a reasonable trade-off. Thermal Issues?

Or marketing. There may be an even fatter chip in the pipeline, and ARM might have asked an extra buck for the double-precision FP.

At least I hope so. I wouldn't say this a couple of years ago, but we do have a micro*controller* application calling for floating point, which can't be circumvented effectively ...

The gotcha for floating point is that it does not scale so straightforwardly in software as fixed does, so when a genuine need for double-precision arises, hardware support for single precision won't help.

JW

[Montassar BEN ROMDHANE_O]

Posted on September 30, 2014 at 10:37

Hi Clive,

This is a typo in the Figure1. But other figures are correct.

It will be fixed fo the next version.

With regards,

Heisenberg.

[waclawek.jan]

Posted on September 30, 2014 at 11:01

So, does it mean that Fig.9 is OK, and compared to the 'F4xx, pin 19 is not VDD anymore,  all pins from pin 20 to pin 49 are shifted clockwise, and pin 49 is VSS, right?

JW

[Tesla DeLorean]

Posted on May 22, 2015 at 21:41

Was starting to wonder if the STM32F7 had fallen off the road map.

http://www.st.com/web/en/seminar/stm32f7-hands-on-seminars

Not seeing anything in the North-American market, and had an ATSAMV71-XULT for several weeks.

[Andrei Chichak]

Posted on May 22, 2015 at 22:48

Yes, this part got a mention in the RTEMS email list today.

I was wondering if I could order samples in a VG package or some sort of dev board to do some performance comparisons with the F4s, but it looks like they are unobtanium (damn you James Cameron, you've taken a perfectly good word and tainted it in your crappy movie!).