STM32F767 examples / support

[tau]

Posted on May 03, 2016 at 14:08

Hi,

any idea when support for these is out? I've got a 767ZI... I whacked on a nucleo board and would like to check out some DP FPU stats,regards 

[Tesla DeLorean]

Posted on May 03, 2016 at 14:45

How hard would it be to just modify other F7 examples?

[tau]

Posted on May 03, 2016 at 15:24

Well I need a header for a start, there's 745, 746 and 756 headers in the CMSIS\Device folder in the cubeMX 'F7 download. So I'd want a '767 header especially for the new peripherals mapping.

then I'd have to modify an existing debug script config for OpenOCD or my tool of choice - are the 767s supported on JLink yet? I do have one of those. then I'd have to fiddle with the compilation switches and find out exactly what FPU its using amongst other things - I know for example the F746 uses an FPV5-sp-d16 - ok, so I suppose that'd be dp instead of sp there. I think there'd be a bit of pain with the startup file as well. So all in all it seemed like waiting for the support would be the easier option...

[Tesla DeLorean]

Posted on May 03, 2016 at 18:26

Having brought up Atmel and ST Cortex-M7 devices on my own, it honestly isn't as hard to get things started as you're making out. Atmel had a 300 MHz M7 with FPU-D in the *retail* channel back in April 2015, and there was enough GNU/GCC support then to create a viable startup file supporting all the vectors, though honestly that's not required to start the part or FPU

If you have familiarity with the tools it shouldn't take more than 30-60 mins to get something working, certainly enough to benchmark the FPU. I'd be surprised if the ST software shows before mid May. Have you tried running stock F7 code on your board? You should be able to read out and printf() the FPU configuration. Segger's usually ahead of the curve on most things, they Keil and IAR tend to have to build the tools that ST uses. I guess we're still waiting for ST-LINK Utilities 3.9 to appear, and that was promised a few weeks back. If you have open tools, you could patch the ID's if required. Failing JTAG/SWD connectivity, there's always the System Loader.

[tau]

Posted on May 04, 2016 at 09:46

Apologies, I didn't meant to be dismissive. My experience lies in software rather than toolchains, so I haven't dug around much actually bringing up an MCU. what I have had trouble with recently is the GNU ARM plugins (which are great) and getting an F7 Disco board working / debugging correctly with STLink V2-1 debugging. F4 disco, fine. F7 disco, something not working. So, I suppose I imagined a bit more pain than that getting things going...

I'll look into this at home a bit more as I'm time constrained at work unfortunately! thanks for the guidance though 🙂

[tau]

Posted on May 04, 2016 at 10:06

Hahaa! Well... thought I'd try running running the nucleo '746 example I had on the nucleo with the 767 in and it worked. (unsurprisingly maybe?)

Anyway, I shall remember this trick for another time. I'll try modifying from here.Thanks Clive 🙂

[Tesla DeLorean]

Posted on May 04, 2016 at 17:37

I built the code for the F7 in mid June 2015, when the F7-DISCO made it to the retail channels. They can't deliver the new part on DISCO's to the May seminars this year, so I'm kind of expecting a June 2016 time frame there too.

//****************************************************************************
// FPU Programmer Model
// http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0489b/Chdhfiah.html
void FPUCheck(void) // sourcer32@gmail.com
{
uint32_t mvfr0;
printf(''%08X %08X %08
X%08X %08X %08
X'',
*(volatile uint32_t *)0xE000EF34, // FPCCR 0xC0000000
*(volatile uint32_t *)0xE000EF38, // FPCAR
*(volatile uint32_t *)0xE000EF3C, // FPDSCR
*(volatile uint32_t *)0xE000EF40, // MVFR0 0x10110021 vs 0x10110221
*(volatile uint32_t *)0xE000EF44, // MVFR1 0x11000011 vs 0x12000011
*(volatile uint32_t *)0xE000EF48); // MVFR2 0x00000040
mvfr0 = *(volatile uint32_t *)0xE000EF40;
switch(mvfr0)
{
case 0x10110021 : printf(''FPU-S Single-precision only
''); break;
case 0x10110221 : printf(''FPU-D Single-precision and Double-precision
''); break;
default : puts(''Unknown FPU'');
}
}
//****************************************************************************

I need to double check the USART on the Nucleo-144, which I presume you are using, and port my F7-DISCO GNU/GCC project to that.

[Tesla DeLorean]

Posted on May 05, 2016 at 19:45

Chatted with my local FAE, all the F767 stuff is still under NDA (Reference Manual, ..), which seems a bit odd as the product has been announced, and they are doing the road show/seminars this month in the US. Really not sure what can possibly be in there that still needs an NDA at this point, and it just dampens interest when you're trying to ramp it. There's some ODD management and strategy going on there, and I'm not going to try to hurt my head rationalizing it.

Would suggest you chase down your FAE, or contact point, and get some software from them.

[Amel NASRI]

Posted on May 06, 2016 at 11:37

Hi clive1,

STM32F767 devices are announced but not yet available in mass production.This is aligned with

http://www2.st.com/content/st_com/en/about/media-center/press-item.html/n3780.html

in January 2016 where we said: ''The STM32F767/769 microcontrollers are sampling now and will enter mass production in May 2016.''So all required materials will be available soon, with mass production.-Mayla-

[Tesla DeLorean]

Posted on May 06, 2016 at 14:50

Ok, and this precludes you from releasing ''preliminary'' documentation now why exactly? The US seminar series promoting this part started earlier this week.

The silicon is already committed at this point, making it's way through the process. Are there some features that haven't been released that the NDA would protect, like it actually runs at over 300 MHz, instead of over 200 MHz? Because currently you're well over year behind the competition playing catch up, you're at a strategic and tactical disadvantage which is further aggravated by the lack of documentation and software. May be your management doesn't understand this, but it's apparent from the outside.