IBUSERR with emWIN on STM32F4?

[David Ashman]

I need some advice on how to solve an issue with a forced hard fault IBUSERR when using ST provided emWIN freeware on a custom designed STM32F429BI based board. The STM32F429 is running HSI at 168MHz at 3.3v. As shown below, the forced hard fault IBUSERR bit is set in the CFSR register which happens every few days or so of constant operation. Every time, the LR points to the call to LCD_UpdateColorIndices() within the GUI_SelectLCD() routine of emWIN - see attached disassembly screen shot. I've experienced the error with emWIN v5.28 and v5.32. I've also experienced the error with overdrive disabled and enabled, prefetch disabled and enabled, and instruction/data cache enabled and disabled. Flash latency is set for 5 wait states (I'm currently running tests with 6) . I've contacted Segger and they can't provide any support without licensing the source code. Has anyone else had this problem? Why is IBUSERR happening during calls in the GUI_SelectLCD()? Any recommendation on what to try? Thanks.

In Hard Fault Handler

SCB->HFSR = 0x40000000

SCB->BFAR = 0xE000ED38

SCB->MMFAR = 0xE000ED34

SCB->CFSR = 0x00000100

r3 = 0x00000000

r12 = 0x00000001

lr = 0x08046E13

pc = 0x00E27B80

psr = 0x00000068

[David Ashman]

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"

[David Ashman]

The Kiel app note referenced above.