Code misbehaving when enabling features (Possible Size Constraint)

2
votes

I understand this topic is quite vague.... so I'll try to explain it.

I'm working on a project in IAR Workbench. I have gotten to the point where if I add a new feature, such as a simple if statement, the entire code structure breaks. The code compiles fine and downloads to the 8051 device fine, but midway through the code's startup sequence, I lose connectivity. It's as if there is a stack overflow happening. If I pause the debugger, I see that my XdataStack and IdataStack values are low (less than 50%) and there are no stack overflows to report.

In fact, the code that causes the problem isn't even being called by the application.

This is even more evident if I enable a debug #define constant I have in my code. Enabling this causes more string constants to be built into the code for uart debugging.

Another test I performed was to created an array of 100 chars in a function that already existed

char hello[100];
memset(hello, 0x00, 100);

And this also seems to break the code.

I was wondering if there are memory areas I should look at to see if perhaps I have filled up this device (CC2540 with 128Kb flash size)

IAR lets me look into:

  • IDATA
  • XDATA
  • SFR
  • Logical Code
  • Code
  • Data
  • Pdata

As far as my project configuration is concerned:

Stack Sizes:

  • IDATA: 0xC0
  • PDATA: 0x00
  • XDATA: 0x280

Heap Sizes:

  • XDATA: 0xFF
  • Far: 0xFFF
  • Far22: 0xFFF Huge: 0xFFF
1
cheap-memoryiarstack-memory8051
Unfortunately, this is the type of question which does poorly on SO. Suggested next step: try to trigger this behavior with a minimal example (steadily increasing the footprint of an empty application) -- do you see the same symptoms when you cross a threshold? Does that threshold correspond with the flash part's size? - Brian Cain
I expected that. Prior to posting this question, I did what you were talking about. I steadily increased the footprint until i found the threshold. I suppose I'm not versed enough in IAR Workbench to carefully monitor the stack/heap/code size - Jonathan
"I steadily increased the footprint..." ...of a minimal example? "until i found the threshold..." ...and then what happened? - Brian Cain
So the original project was built off a shipping example from TI. I've added functionality as discussed and have gotten to the point where this problem is exhibited. I'm a bit confused as to how XDATA size is reported. I call a function that creates a local variable string of size 100 and the XDATA memory size jumps up. But when the function ends, the memory indicator does not readjust back to its original levels. Wont the string variable get pushed off the stack and be reset? - Jonathan
I see this when the watchdog is enabled at bootup, e.g. on bigger Silabs 8051Fxxx devices, as XDATA fill takes longer than watchdog timeout. The TI CC2540 does not seem to enable it by default if I read the manual correctly. - Turbo J

1 Answers

0
votes

It's as if there is a stack overflow happening.

This is fairly unlikely in a 8051 because the stack is not used very heavily. Without effective indirect addressing modes it is mostly restricted to holding return addresses (managed automatically by the MCU) and saved registers (mostly in ISRs).

Another test I performed was to created an array of 100 chars in a function that already existed [...] And this also seems to break the code.

Your code is basically equivalent to: f() { static char hello[100]; ... } with the compiler managing all of those "local" variables with overlays so that those 100 bytes are only safe to use when f() is executing. This can only work if the compiler can tell which functions might be called while f() is executing. If the compiler's analysis of the call tree is wrong it will cause local variables (including arguments to functions taking too many arguments to pass in registers) to be overwritten in unexpected ways.

The compiler should be smart enough to consider main() and all of your ISRs as roots of independent call trees. It will be easily fooled by computed jumps, calls through function pointers, and concepts like "tasks" in an RTOS. If you use function pointers, for example, you will have to tell the compiler (probably as a linker option) all of the functions that might be called from the function calling through the pointer.