I've confirmed that this is a problem somewhere in the toolchain or C library that is packaged with Energia 0101E0009. As I said, I'm developing on Windows XP 32-bit, although I don't know if the problem is specific to this development platform.
I downloaded the GNU embedded ARM package 4.7.4 (from the Launchpad site: https://launchpad.net/gcc-arm-embedded) and replaced these files/directories in the Energia directory structure with the equivalents from the GNU package:
Note: the Energia bin/ directory contains two files not in the GNU package: arm-none-eabi-run.exe, and lm4flash.exe. I kept both of these. Also note that the GCC binary is version 4.7.4 rather than 4.7.1, so that executable name is different.
I also copied this library directory from the GNU package...
...and put it in two different locations in the Energia tree:
After doing this, I rebuilt the code that I posted above, and atoi() was working properly. I also added some LED-blinking content to the timer ISR, and a call to strcmp(), and everything was working as expected.
I've only recently started using Energia, so I'm not sure if what I have here constitutes enough for a bug report. Please let me know if I should provide any more information.
I'm using Energia with a Launchpad (LM4F120XL), and I've found some strange behavior when using a timer interrupt. When the interrupt setup code is compiled in, functions that do string processing (atoi, strtoul, strtok, etc.) do not return the expected value.
In the code below, atoi() will return 0 when given the input "12". Note that the timer interrupt hasn't even been set up at the point where atoi() is called. In particular, it's the call to IntRegister() that causes the problem. The same code will work as expected if IntRegister() is commented out.
Also note that everything works fine if an infinite loop is placed immediately before the initTimer() call -- in that case, I'm guessing the compiler is optimizing out everything in initTimer() because it's unreachable.
strcmp() was also misbehaving (i.e. returning nonzero values for identical strings), but when I moved the const char* comparison string from global scope to function-level scope, the comparison began working as expected.
Anyone have any ideas about this? It seems like it might have something to do with the arrangement of symbols in memory.