cancel
Showing results for 
Search instead for 
Did you mean: 

Problem getting STemWin to work with RA8875-Based LCD...

Zaher
Senior II
Posted on October 11, 2015 at 19:17

 

 

The original post was too long to process during our migration. Please click on the attachment to read the original post.
3 REPLIES 3
Posted on October 11, 2015 at 19:31

Not sure Segger is regretting the agreement, but the nature of such agreements is that ST provides ALL SUPPORT related to it's use an application. If you expect Segger to support you, then you'd want to pay them to license the code directly, which is obviously going to be more expensive, because good support and engineering staff are expensive.

If your code is Hard Faulting, then add some reasonable handler to dissect what exactly it's faulting on. Hard Faults are pretty gross failures, and usually occur because you're touching memory that doesn't exist, or your crashing the heap/stack into each other.

The other way the Segger code exits is with an ASCII error message, and you need to provide a handler for that. I think I've covered this in other threads, probably ones I had with Roy.

A quick Google yields

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/the%20STemWin%20used%20external%20SDRAM%20can%27t%20pass%20the%20GUI_Init&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5...

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Zaher
Senior II
Posted on October 11, 2015 at 20:53

Mr. Clive,

Thank you very much for the fast input. As I mentioned earlier, this only happens when I select theGUIDRV_FLEXCOLOR_F667 With other options,GUIDRV_FLEXCOLOR_F66708, the GUI_Init() seems to work and the caller returns normally to the main loop. I have changed the code to select the driver that is supposed to talk with RA8875, and here's the output of bt in the debug session:

bt
#0 WWDG_IRQHandler () at ../startup/startup_stm32f429_439xx.S:121
#1 <
signal
handler called>
#2 0x00000000 in ?? ()
#3 0x08002a4c in _FillRect ()
#4 0x0800325a in _FillRect ()
#5 0x08003a7e in LCD_FillRect ()
#6 0x08003ede in emWin_LCD_Init ()
#7 0x0800440c in GUI_Init ()
#8 0x080004e4 in main () at ../src/main.c:100

After GUI_Init(), only a tiny black strip of pixels is shown on top of LCD and here the program enters into that infinite loop. Thank you again!
Zaher
Senior II
Posted on October 11, 2015 at 21:13

Just a small addition, you were right! It was a Hard Fault. I have added a small piece of code into the HardFault_Handler() and I got there when the program crash! I will try to add some debugging code into the HardFault Handler so I can get more details about the possible fault. 

By the way, I have also noticed that there's a possible problem within my SysTick and Delay functions. When delays are called from outside of main, the delay decrement variable is never decremented, which means the program stays in delay loop forever! I hope that had something to do with the HardFault I'm getting from emWin. 

P.S. Sorry, I forgot that the CPU is halted in debug/Hard Fault so SysTick has no effect right there!