I received the below very detailed response from ST Tech Support that I thought I would share. I'm in the process of performing some of the recommended tests. Note the part that tech support has also had hard faults with their emWIN.
"Hi, FAEs don't have the source for STemwin either. The agreement between ST and Segger, ST supplies only the library, the source is not provided other than in ST Division. However, I can submit to division and ask for help which will take a couple days... Before I do that. I've used STemwin several times and have had hardfaults, several of the issues were caused by the heap/stack on the STM32F4, too small. The more windows you use, the more the stack/heap is used. As the STemwin runs, the stack would over flow.... a couple ways to debug the stack 1) shot gun approach, increase the heap/stack in the STM32f4xx.s startup file, not in emwin allocation or OS task allocation, which is memory allocated for the application. The issue with this, you don't know how large it needs to be, if this fixes, you may delay the failure with more stack to burn... shorten the stack, may occur faster. 2) Along with increase/decrease the physical stack/heap, init ALL the stack SRAM with some value, 0x5a. The first entry into the vector table is the stack location. When the hardfault occurs, look at the stack area, if it did overflow, all 0x5A gone. Some of the IDEs have stack tools as well… I use IAR, they have a good one to look at stack/heap usage. 3) Debugging the faulut, remember the M4 is a mulit-pipe execution machine. The last entry in the system registers, may or may not be where the fault was from, it could have happened a couple cycles prior. When it comes to debugging hardfaults, Turn OFF the ART… no caching of anything is what the ART is kind of like... prefetch, data or instrucitions. Icache..... When it comes to this kind of fault debug, the ETM is the way to go… but in actuality many many customers don’t bring out the ETM…. A Segger ETM trace with 64M of SRAM, are expensive… So if you have the ETM, use it if not…. I have attached a good Kiel app note for debugging farther hard faults. I’ve also attached a zip file I’ve used in the past to gather the info from the hardfault, as you may have done below… maybe of help or not. If you’ve done all the above, great, let me know, I’ll then start looking into the emwin call with division. Regards, ST Tech Support M1"
