2016-08-12 03:06 PM
Hi,
I have a big problem where I seem to overload the AHB bus. The main components that are involved are SDRAM and LTDC. I am using one layer (at the same time) in svga resolution and the frame buffer is in SDRAM.Just wanted to ask if any of you had similar problem and/or got any advice about how I can get by this problem. I read something in another thread about using special memory area mapping and so forth to help with this dilemma, but it was very vague.I am using stm32f756xx.Regards,Rygelxvi2016-08-14 02:07 PM
removed.
2016-08-15 03:31 AM
Hi rygelxvi,
I suggest to put the result of your analysis as this may help other users having problems with similar symptoms:Ok, so I think I got a hint to why I get this behavior from the bus. I am never doing any large continuous writes or reads in the code and that is why I did not see why I should have this problem in the first place. However I was using large optimizations for the code and I think that made the assembler code look very different. When I change optimization I do not see the problem any more :)
-Mayla-To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2016-08-15 04:14 AM
Hi Mayla,
The reason for why I removed my previous post was because it was wrong. The saturation of the bus is in my case happens simply because I use the AHB bus too much. I do not think it has anything to do with an occasional long duration of a write or read. It is true that my problem partly disappear if I lower the optimization, however this makes me believe that I just use the AHB bus less due to longer execution time and lower efficiency.To get my application working I need to figure out a way to use the AHB bus less but still get high performance. I already use cache and I am also using all the possible bandwidth of my 200Mhz SDRAM etc.Now I am focusing on using DTCM in a more innovative way, since as I understand it, this memory is not using AHB bus if accessed by CPU. Also I will turn my eyes to FLASH-ITCM together with experimenting with different cachetype for SDRAM (WT vs WBWA).Too bad there is no way of giving read priority over writes on the AHB bus, since this would solve many problems for those running the same use case (LTDC).If anyone got any suggestion how to limit the strain on the AHB bus without loosing too much performance I would be grateful.2016-08-15 06:39 AM
As you focus on how to get the best performance, I suggest you to review the following application notes:
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2016-08-15 11:02 AM
Hi again,
Thanks for the information !I have already read a great deal in those documents.I cannot explain it but when I tried swapping the SDRAM region from 0xC0000000 to 0x60000000, all my problems just disappeared and now I get maximum performance without any drawback on LTDC :)Must be something I missed or did not understand in those documents...2016-08-16 02:25 AM
Hi,
In the example STM32Cube_FW_F7_V1.4.0\Projects\STM32746G-Discovery\Examples\FMC\FMC_SDRAM_DataMemory, same mapping (0xC0000000) is used.In this example, MPU_Config function is called at the beginning in order to configure the MPU attributes as Write Through for SDRAM.Did you made the same?-Mayla-To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2016-08-16 12:15 PM
Hi Mayla,
Yes, I still do it that way. But with 0x60000000 instead as mentioned. I read in some document that this is actually needed in order to enable cache for the 0xC0000000 memory area since it is deactivated per default.