Stemwin GUI and external SDRAM

[Luiz Pereira]

Posted on March 15, 2018 at 01:59

Dear all

I know that this is a very old question but after more than two months, I'm really sad... I'm developing a work (for scientific research) using a stm32f746igt mcu (from waveshare 746i) with several middleware/peripherals (freeRTOS, stemwin, usb hid, uart, spi, i2c, adc, timers, TFT controlled by fcm, etc...). Everything works absolutely OK, (including some DMA process). Trying to move stemwin to external SDRAM, the process hangs in GUI_Init (alloc / unlock) with a bus fault or at a first attempt to create a window (no problem in GUI_Init in this case) with a usage fault (invalid state). The different kind of fault, is not correlated with changes in software but sometimes seems to be dependent on the rebuild process, i.e. compiling the same code, the fault type can change... I'm using TrueStudio. I tried to configure everything  (fmc config, timings, MPU, cache...) performing almost know memory tests (read/write, 8, 16, 32 bit aligment, integrity of the physical memory) and, (obviously) all perfect (including using large amount of data - up to 512K). At this point, I give up. The only thing that I wish to know (because after seen hundreds of discussions in specific forums I still have no precise idea) is if effectively someone was successful in put this 'thing' (stemwin) working without any problem in external sdram. Thanks.

Regards

[boomerblur]

Posted on March 15, 2018 at 08:20

Hi ! Nice to meet you. I have already work with stm32 and STemWin and external SDRAM. In my projects I Init External SDRAM before call any function of STemWIn, and every things is OK. Could you want to see my example ?

[Luiz Pereira]

Posted on March 16, 2018 at 21:37

 ,

 ,

Hi ! Thanks for the replay (and interest). Yesterday I had the possibility to test the software in Keil with a colleague (my free version cannot compile the my very extended sofware!) as the debug tools are better. Really I follow all the usual procedure: init fmc (sdram, 16 bit, etc..) / init sdram (use the example from stm32cube F7_V1.9.0) and init MCU (with MPU_PRIVILEGED_DEFAULT). , As a general address, I use some in the 0xD0000000 - 0xD0800000 range (the waveshare f7 board is configure by default to use the sdram in bank_6), etc... Using a memory pointer, I'm able to write / read any amount of data, 8-, 16- and 32-bit aligned with no errors (I can do that using also the HAL functions HAL_SDRAM_Read_Xb / HAL_SDRAM_Write_Xb , where X = 8, 16 or 32), doesn't matter what kind of data (int, float, double, strings....). All this, with stemwin using internal mcu sram. At this point, I need to consider that there is no problem in fmc/sdram configuration (BTW the mcu is clocked at 200MHz, allowing a maximum freq for memory of 100MHz - sdram is IS42SI6400J, according to the manufacturer). , Moving the stemwin memory to this external chip, problem starts. I teste two different approches in GUIConf:

 ,

the most known way:

 ,

♯ define GUI_NUMBYTES ,  , ,(256*1024)

 ,

static U32 aMemory[GUI_NUMBYTES / 4] __attribute__((at(0xD0000000))),

 ,

GUI_ALLOC_AssignMemory((void *)aMemory, GUI_NUMBYTES),

 ,

and a 'pointer-like' way:

 ,

♯ define GUI_NUMBYTES ,  , ,(256*1024)

 ,

volatile U32* aMemory = (volatile U32*)(0xD0000000), ,

 ,

GUI_ALLOC_AssignMemory((void *)aMemory, GUI_NUMBYTES/4),

 ,

Both cases fails: in the first case, a hardfault in GUI_Init (in the GUI_ALLOC_UnlockH), bus fault, with PRECISERR and BFARVALID flags on (SCB->,BFAR = 0xEC3C2EA0, strange for me!), in the second case, usage fault with INVSTATE flag set, no caller code, fault in processing GUI_CreateDialogBox and I can see the beginning of the windows paint ! As an interesting thing, in both cases I can write into LCD using GUI_DispStringAt, choose colors for fore- and background, etc), since it does not access the functions of windows! For now, I can still developing my project only with internal sdram, but as I can see in the forum, this is not 'my own problem' as many others have similar problems. , As I never saw a very detailed description of this problem (except one or two situations a little similar in emwin forum) I'm not sure if the problem is always like I described. In any case, I think that this discussion is much more useful for further understanding about the problem than try to get an immediate solution (really I cannot understand how a company like segger made this...). So, considering my curiosity at this moment, if you can share the basic ideas regarding your solution, I will appreciate. Really I'm convinced (and I want to believe in it) that I'm doing a 'stupid' error something and I'm not able to see it...

 ,

Thank you very much

 ,

Regards

[Viktor Tomov]

Posted on March 18, 2018 at 16:00

Hi Luiz,

Where did you defined the framebuffer address? In your case it should be after aMemory. It could be that the framebuffer overlaps with the GUI memory?

Victor

[Luiz Pereira]

Posted on March 19, 2018 at 03:33

Hi Victor

Thanks for the suggestion but I'm not using multibuffering. The display is a 7'' ssd1963 in GUI FlexColor mode, one buffer, controller managed. At this moment (and updating previous information) no matter of kind for aMemory initialization in sdram, the stemwin gives a usage fault with INVSTATE flag set, no caller code, fault in processing GUI_CreateDialogBox in a first attempt to draw the window and after start drawing...Really this is an interesting question. Before calling GUI_CreateDialogBox and after successful GUI initialization with GUI_Init and GUI_X_InitOS, I can perform the almost usual GUI drawings - if no windows functions are called.

WM_SetCreateFlags(WM_CF_MEMDEV);

WM_SetSize(WM_HBKWIN, 800, 480);

----> in this point, GUI basic functions appears to work without no problem GUI_SetBkColor(GUI_BLACK); GUI_Clear(); TouchUpdate(); GUI_Exec(); hWndMain = GUI_CreateDialogBox(_aDialogCreate, GUI_COUNTOF(_aDialogCreate), _cbDialog, WM_HBKWIN, 0, 0); <---------------------------------- fault in this point (at least I can consider that setting aMemory in external sdram works!) Exactly the same code in internal sdram, everting fine and perfect!!! As soon I have time, I will try to 'dissect' point by point in code the error, as (bad to be true) I cannot found any debug version of stemwin library(!) Meanwhile, I leave the relevant parts of my code (the major part from the stm32 examples) related with fmc / sdram / lcd / GUI config if someone is curious enough to give a look ________________ Attachments : project_LCD_FMC_SDRAM_related.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxsg&d=%2Fa%2F0X0000000b1m%2Fr1CBJcx0xW69boEm_t9ufFnKkFzb7uZ6xRW9LjpoiYw&asPdf=falseproject_LCD_FMC_SDRAM_related.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxr6&d=%2Fa%2F0X0000000b1j%2F6_.KVeh5_6_hY4SOUZOhjLAZInuHhLWscIGNV6P8..Y&asPdf=false

[Rohit Mishra]

Posted on March 26, 2018 at 15:26

I was too facing exactly the same problem, Configure MPU attribute for SDRAM will solve the issue.

static void MPU_SDRAM_Config (void)

{ MPU_Region_InitTypeDef MPU_InitStruct;

/* Disable the MPU */

HAL_MPU_Disable();

/* Configure the MPU attributes for SDRAM */

MPU_InitStruct.Enable = MPU_REGION_ENABLE; MPU_InitStruct.BaseAddress = 0xC0000000; MPU_InitStruct.Size = MPU_REGION_SIZE_8MB; MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS; MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE; MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE; MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE; MPU_InitStruct.Number = MPU_REGION_NUMBER0; MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL1; MPU_InitStruct.SubRegionDisable = 0x00; MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE;

HAL_MPU_ConfigRegion(&MPU_InitStruct);

/* Enable the MPU */

HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);}

[boomerblur]

Posted on March 26, 2018 at 15:36

Hi nice to meet you. Where this function is called ?

Tải Outlook for iOS

[Tesla DeLorean]

Posted on March 26, 2018 at 16:06

After you initialize the memory, but before you use it.

[boomerblur]

Posted on March 26, 2018 at 16:08

Thank you. I will try it .

Tải Outlook for iOS

[Luiz Pereira]

Posted on March 26, 2018 at 22:34

Hi

Thanks for all suggestions and interesting discussion. Considering that I tested everthing that was suggested and this discussion starts to point for similar things already seen in many forums, let me point (as simple as possible) the fundamental questions:1-> I'm using a stm32f746igt (waveshare core7xxi) with external 8MB sdram (issi-ic42s16400j), 16bit, controlled by fmc in bank6 (0xD0000000). Initialization of both fmc and sdram are in my previous attachments2-> I'm using a LCD, 7inch, buydisplay, RGB565 with integrated ssd1963 chip. Is controlled by fmc (bank1 - chip select 4, register selected A6, 0x6C000080). No framebuffer is used.3-> Both memories need to have MPU configured (even if external sdram is not used, bank1 cannot correctly control de TFT without MPU configuration). The MPU configuration is also shown in my previous attachment4-> Process:a) initialized HAL/system/pheriferalsb) initialized sdramc) MPU for both bank1 and bank6d) GUI_Inite) GUI_X_InitOS (I'm using FreeRTOS)f) write startup informations using GUI basic routines (GUI_SetFont, GUI_SetColor, GUI_DispStringAt, ...)g) init Windows Manager drawing the initial framewinh) ---execution---5-> Memory:a) The GUI_Init calls GUI_X_Config where the stemwin memory is assignedb) if internal sdram is used, allocation is: static U32 aMemory[GUI_NUMBYTES / 4]c) if external sdram is used, allocation is: static U32 aMemory[GUI_NUMBYTES / 4] __attribute__((at(0xD0000000)));d) in BOTH cases, GUI_ALLOC_AssignMemory(aMemory, GUI_NUMBYTES) works perfectly without any problem6-> Resultsa) in BOTH cases everthing works perfectly from 4a) -> 4f)b) if external sdram is used, 4g) starts WM and starts drawing the framewin (I see more or less half of the framewin in the display), BUT, hangs during the process with bus fault, preciserr and bfarvalid flags set, scb->bfar pointing to something like 0xF6FFF503 address. Caller function is often  GL_DrawBitmap or GUI_ALLOC_h2p. Some times, an usage fault, unaligned flag set, with caller function WIDGET_init... Changing the MPU initialization parameter MPU_InitStruct.DisableExec to MPU_INSTRUCTION_ACCESS_ENABLE or MPU_INSTRUCTION_ACCESS_DISABLE (as some examples shows) seems to have no relevant changes as the same problems appears; also enabling or not CPU cache, is indiferent...c) External sdram memory tests, including 8-, 16- and 32-bit aligment as well DataBus and AddressBus gives all results OK; manipulating the sdram with HALL functions (both read and write, also 8-,16-,32-bit) and up to large amount of memory blocks, gives all results OK. At this point, I should really consider that I'm not seeing some small, BUT relevant aspect or I'm trying to make an impossible thing. Hope that this discussion can be helpful for someone...Once again, thanksRegards