STM32F429I-DISCO Coming Soon

[Tesla DeLorean]

Posted on September 16, 2013 at 20:19

http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF259090

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

http://www.mouser.com/ProductDetail/STMicroelectronics/STM32F429I-DISCO/?qs=sGAEpiMZZMvh0aGzCjJ9ppxivASqTeq/

http://www.digikey.com/product-detail/en/STM32F429I-DISCO/497-13898-ND/4310131

[Tesla DeLorean]

Posted on October 02, 2013 at 17:05

what for should be the ACP/RF Connector on board?

http://www.stmcu.org/download/index.php?act=down&id=3660

http://www.st.com/st-web-ui/static/active/jp/resource/sales_and_marketing/presentation/product_presentation/dual_int_ee_kits_and_boards.pdf

[Tesla DeLorean]

Posted on October 02, 2013 at 17:09

Any specific reason for that ? According to RM0090 (Doc ID 018909 Rev 5), sect. 2.1.1, the I-bus should be capable of fetching instructions from ext. RAM/FSMC. IMHO a disappointing feat if not supported.

I tried to make it work from a number of angles, but it always Hard Faulted like the CCM. I could have missed a trick. I will look also at the STM324x9I-EVAL to see if the mapping is any different.

[Tesla DeLorean]

Posted on October 02, 2013 at 23:35

The STM324x9I-EVAL uses Bank1 at 0xC0000000, and I can map that at zero, whereas the STM32F429I-DISCO uses Bank2 at 0xD0000000

[Tesla DeLorean]

Posted on October 03, 2013 at 17:56

With the STM324x9I-EVAL I can't execute code at 0xC0000000, but can map the 8MB at zero and call code there. The next thing to quantify is how fast it runs.

Disclaimer : My EVAL board has engineering silicon. Update: ~6X slower than FLASH at 168 MHz

[Tesla DeLorean]

Posted on October 04, 2013 at 06:37

I've posted an example GNU/GCC project to bring up the SDRAM on the STM32F429I-DISCO, and demonstrate STDIO output via SWV.

https://docs.google.com/file/d/0B7OY5pub_GfIc2JZMks1UzdsOTA/edit?usp=sharing

[kenkyee]

Posted on October 05, 2013 at 16:07

> Update: ~6X slower than FLASH at 168 MHz

Wow...that's hugely slower.  Any idea why this is?

[Tesla DeLorean]

Posted on October 05, 2013 at 19:34

Any idea why this is?

The bus is external, lose half your bandwidth there. SDRAM is inherently poor at random access, and has significant latency, being designed for efficient streaming (video, or cache lines). The Cortex-M4 doesn't have a cache architecture. I should probably benchmark the external SRAM on the EVAL board too.

[frankmeyer9]

Posted on October 06, 2013 at 10:11

The bus is external, lose half your bandwidth there.

IMHO even more. The ref. manual states ''128 bit wide data read'', giving a factor of 8.

[Tesla DeLorean]

Posted on October 06, 2013 at 11:03

IMHO even more.

Indeed, I was throwing in the cheap 180 MHz -> 90 MHz (168 -> 84) Beyond that it potential halves again if the row/column must be clocked in. I haven't dug too deeply into the mechanics of the SDRAM, but it's not hard to see in non-optimal usage it's going to be slow, and not fast. Certainly the generation of SDRAM used here isn't inherently faster than FPM/EDO type devices it replaced, just that it can pipeline wider internal accesses to give the appearance of being faster. With the X-Y-Y-Y timings, X is always significantly more expensive.

[warcatz]

Posted on October 08, 2013 at 12:07

I get mine yesterday and have try the demo and some other examples.

In the perf test it tell me 35.679.000 pixels / sec !! Is that correct ?? On my 'old' stm32f4 board i can put 1Mi Pixels/sec (without DMA) on screen. If this new 32f429 can handle that much i think we can soon see a new video game console :) Now where i am a little lost is for made a driver that use the new feature to work with my ILI9481 controller , apparently the on-board LCD use the vsync,hsync and RGB pin. What i can't use with the other screen i have ;) Now a little question for master Clive , for what is the SPI used in the LCD configuration ? I see it in the source but cannot see what this is doing here :) Cheers. Darth.