Discussion created by greenwood.greg on May 2, 2018

Some time ago I started out with CubeMX thinking that I would be able to setup my project for the H743i-eval board, include the middleware and be off to the races writing code to use FreeRTOS using a FAT file system.  I also needed to use UART and ethernet.  Much to my dismay the out of the box experience was dismal.  OK so I learned a good deal with help from the forum including the art of the linker.  Much of the project I need to get going is working in its basic form, pieced together from the application examples and not from the CubeMX tool.  Having come up a very steep learning curve I thought I would go back and look at the CubeMX generated project and again to my surprise, the first thing I noticed is that the Cube generated project linker script is putting .data, .bss, heap and stack in the DTCMRAM!  No wonder the DMA required for FatFs, and Uart never worked.  The .TxDecripSection, .RxDecripSection, and .RxArraySection for the ethernet buffers are there as well since there is no explicit call outs in the linker script and are woefully inadequate in size compared to the application example.  At the very least all should have been put into RAM_D1 and I believe the application example for tcp/udp under FreeRTOS puts the ethernet buffers in RAM_D3.  But in the beginning I would never had thought to look in the linker script.  Which brings me to my point; If CubeMX does not have the feature to setup the memory, and if even if it did, shouldn't the default for linker script not be using DTCMRAM owing to the operational limitations?  After having looked around on the web I have found that other than the standard documentation for LD (linker script)  there is really not much out there to aid in removing the mystique of the linker script.  This opens a great opportunity for ST to step in and fill the void with CubeMX which would be the perfect place to maintain such an animal.  A GUI based tool that allows the specification of memory partitioning and section assignment naming along with  some basic check and warning like "heap in the DTCMRAM is a bad idea" if the heap will be used to allocate buffers that will need memory to peripheral DMA.  Sure would have saved me a bunch of time which I believe is the raison d'etre for CubeMX.  Either that or now that Atollic is on board perhaps they could offer a GUI based tool for managing the linker script.