[DONE] The New STM32F429/F439

[Tectu]

The demo does not yet initialize the SDRAM and the LCD.

Any updates on this, Giovanni?


~ Tectu

[Giovanni]

Not yet, there are too many bug fixes waiting and I have to empty the queue and make a release first. You may do a temporary initialization in board.c using the ST code in the meanwhile.

Giovanni

[Tectu]

Is it possible to copy paste the ST code when I enable the STDLIB in the Makefile?


~ Tectu

[Giovanni]

You can add to the Makefile just the modules you need, not the whole thing.

Giovanni

[TechNick]

hi guys,

played a bit with your port to the stm32f429. great job!

but maybe you need to adapt the vectors.s-file. the last irq-handler in your file is the one for the fpu. according to the startup-file from st the f429/439-line has 9 additional interrupts. noticed this while porting seggers emwin from the freertos-example to chibios, because it uses dma2d.


greetings
nick

[Giovanni]

Hi,

Thanks for finding, fixed in repository.

Giovanni

[trepidacious]

Hi,

I'm just trying out a 427 on my own board, the port is looking great so far, there are quite a lot of peripherals used on there so it should be good testing. I'm also looking forward to finding out whether the DCMI DMA errata is really fixed, which I should be able to do soon

I did notice that the .ld file for the 429 defines the whole DMA-able SRAM as one region "ram", whereas on the 407 this was mapped as separate "ram" and "ethram" regions for the 112KiB and 16KiB SRAM regions. One big region seems much more convenient, but I was wondering whether the SRAM can always be treated this way, for example for DMA transfers etc.?

I've been reading through the datasheet and reference manual, and I can't really find anything that seems relevant, except that the DMA controller apparently has separate bus connections for the 3 regions, not sure what the significance is, I guess putting buffers for use by different DMA controllers in different regions might help performance, but I'm not too bothered about this.

Ben.

[Giovanni]

There are 3 separate regions and many combinations plus the external memory so I decided to support the most simple solution. An application so advanced that would require attention to such details, almost certainly, would also require a custom scatter file.

Giovanni

[TexZK]

You forget that there is also a CCM, so the memory regions are actually 4 Of course each of these regions is better suited for some purposes. Splitting them inside a custom linker script is rather easy anyway, so that you can partition them the best way for your application requirements, as it isn't easy to provide a good default linker script.

[trepidacious]

You're right, I was omitting the CCM since that has a clear difference with the DMA, but I wasn't clear on the significance of the non-CCM SRAM regions. On the 407 I used a custom linker script to use the ethram specifically for some large DMA buffers, so I was sure nothing would run across a boundary. I guess on the 427 I'll just define another region, and manually assign stuff to that as well.

One drawback of that approach is that (AFAICT) there is no static initialisation of variables except in the first "ram" region. This was a bit of a surprise when I first ran into it, so it would be quite handy to have one big ram region that all supported static initialisation. I've not looked into it but my understanding is that this could alternatively be addressed in startup code that handled multiple regions.