Fault ISR [ FaultISR() ] when calling GrStringDraw()

Robert

I've pasted a link below to a document that helps to diagnose software faults on these devices. As an overview, you will be checking the NVIC_FAULT_STAT register at 0xE000.ED28 for determining the type of fault. Based on what bits are set, you can reference other registers to determine what happened. For example, if the BFARVALID bit is set, then the NVIC_FAULT_ADDR register will contain the value of what memory access triggered the fault. This document also shows how to analyze the exception stack frame, which will include the PC and the LR to determine down to the assembly instructions where it screwed up.

http://www.ti.com/lit/an/spma043/spma043.pdf

Regards,

Reagan

Reagan,

I followed the instructions and was able to determine that the NVIC_FAULT_STAT = 0x0000 8200, which indicates a Precise Data Bus Error. The NVIC_FAULT_ADDR = 0x46BF0000. So apparently this is the address that the software is trying to access (which is invalid). The question is, who is trying to do this in the Stellarisware Graphics library?

I'm trying to write to a 3.5" LCD display. Any ideas?

Thanks,

Robert

Glad to read of your troubleshooting initiative - persistence - and success!  Good for you.

This suggests that these widgets make multiple function calls - increasing the stack's usage  - and that the stack size should be increased as a preventive measure.  It would be useful to see if this, "increase in stack size" is referenced w/in the Graphic Lib User Guide or other related references.  (although a 256 size stack does seem very small...)

cb1_mobile said:

a 256 size stack does seem very small...)

Indeed it is a constant source of the problems reported via these forums!

Noted here: http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/p/227176/799092.aspx#799092

Robert,

  The graphics library in general and, specifically, the text rendering functions do have a rather deep function call tree (maybe up to 6 levels or so?) so you would likely need to increase the stack size when using these functions. As regards the FPU, if you are on an LM4F device, our examples typically set the system up for "lazy stacking" where the FPU registers are only dumped onto the stack if a function actually uses the FPU. Remember, like the main CPU registers, there is only 1 set of FPU registers so they need to be saved and restored on function and ISR entry/exit too. As far as I can remember, space is left on the stack for the FPU registers even if they are not actually written to the stack on a particular function call so this again increases the amount of stack you need.

@Dave W:

As you are resident expert on many things Graphic -> Stellaris (and the new issue) - might you suggest the best "trade-off" stack size?  (should this exist somewhere w/in existing documents - seems in need of better "high-lighting" - so users may avoid this pitfall... appears many have become so entrapped...)

As a rule, we typically start with a 1KB stack for any application using the graphics library. Some examples, especially those using the widget library, international text support, sprintf-type functions from the C runtime or floating point, use a 2KB stack. I would recommend starting with a stack larger than you think you will need (2KB is a good bet in most cases) then, once the application is done or when you find that you're running out of SRAM, put some stack probes in place and run the code for a while to determine how much stack it's actually using before adjusting the project setting. Note that the required stack size will vary enormously depending upon the code that you are running. Our previous SSL appnote example required a 7KB stack, for example, due to the number of large arrays it declared as local variables.

By "stack probes", I mean either make use of any facility your toolchain offers for stack size profiling (I've hardly ever done this, though) or fill the stack with some odd value (0xDEADBEEF and 0xFEEDFACE are popular here) inside ResetISR() then run the application and, after a while, look to see how far down from the stack top you have to go before you start seeing this pattern in memory.

The truly rigorous approach would, of course, analyze every possible code path to determine maximum function nesting and local variable space requirements, analyze the interrupts to determine maximum interrupt nesting, and calculate the worst possible stack usage based on all this. Some project may like or need to do this but I've found the simpler approach works fine in most cases especially if you leave a bit of extra leeway in the final stack allocation.

@Dave W:

Far above/beyond expectations - truly outstanding - much thanks...

Here you've not only supplied a crisp/clear answer - but have made the time/effort to include: "the" what, where, when, & how - which is especially insightful and greatly appreciated.

If this safeguard could someway/somehow be incorporated w/in Graphic User Guide - suspect it would prevent many user headaches - and reduce "wear/tear" on TI tech staff...

Again - thank you for a truly awesome write-up...

Dave Wilson said:

The truly rigorous approach would, of course, analyze every possible code path to determine maximum function nesting and local variable space requirements, analyze the interrupts to determine maximum interrupt nesting, and calculate the worst possible stack usage based on all this.

Rather than a script which you have you know to run manually, could CCS be enhanced with an option to perform the worst case stack analysis itself and report a warning if worst case stack size is more that the stack size set in the project?

That looks rather useful! I've seen a few commercial static analysis tools but had no idea we had one available for download. I'll have to take a look at it.

As regards having CCS do this for you, it may well already include dynamic stack analysis features (I'm no CCS expert!) but you would likely have to go and ask over in the CCS forum and make your suggestions there.