2021-10-20 11:00 AM
Call to MainView::invalidate for a text box causes CFSR_UNALIGNED inside TouchGFX function, in vicinity of TextProvider::endOfString.
Have commented-out our code change to text box text, and simply call invalidate, and observe crash.
Tried solutions 1 and 3 at link below, no help, though not surprised about solution 3 since I can't recompile the TouchGFX code.
https://developer.arm.com/documentation/ka002886/latest
How to avoid CFSR_UNALIGNED?
Edit:
Stepping through the TouchGFX assembler language, the offending statement appears to be:
LDR R2, [R0]
MOV R1, R4
LDR R3,[R2, #0x8]
Where register set 1 R0=20 and R2=FE119ADA.
If that final LDR is loading register R3 from a memory location pointed to by register R0 plus 8, that will not be a valid address.
Edit:
The original software engineer on this project was using TouchGFX Model method "tick" to call a ModelListener method that updated a text box and called Invalidate. That worked fine.
I revised the TouchGFX interactions, both in terms of button presses or slider operations, and in terms of screen updates, to be event driven not periodic [not via "tick"].
So I created several threads which either "get" screen update data from queues or "put" screen button or slider changes to queues.
Apparently, the "get" queue thread, which has a starting argument of "this" for Model, and uses "this" to access the Model instance and ModelListener and the update method that calls Invalidate, annoys TouchGFX.
Once I moved my "get" queue thread data to a place that "tick" could find it, and then from "tick" update the screen, all problems went away, no crashes, no hangs.
I realize TouchGFX documentation emphasizes "tick" operations for screen operations, but there is no professional reason to have to do this periodically rather than via events.
Must everything be done through "tick"?
2021-10-22 10:59 AM
The problem apparently was a stack overflow.
I was smart enough to give the TouchGFX thread a relatively large stack.
But I was not smart enough to give the threads that "get" queue updates for TouchGFX also a relatively large stack, and TouchGFX was of course operating on the update thread stacks.
Once I increased the size of the update threads stacks, the crashing and hanging stopped.
Any reference on how much stack TouchGFX needs?