Hi Michael,
michael_v_truong wrote:
Hi, I currently developing with the MSP430F149 chip and I seem to be running into a lot of bugs. I'm programming in Linux (Redhat 9)
using gcc. I am burning the flash through a parallel JTAG connector, using a python script, pyJTAG, if any of you ever heard of it.
The problems I'm having are as follows:
- If the program is exactly 2778 bytes, nothing works! If I add one single nop command anywhere in my code (I've tried about 15
arbitrarily locations), everything works fine, and if I take out a single line anywhere in my code, it works fine as well. It just seems to
be having trouble with 2778 bytes exact. This is actually the second time this problem came up. The first time I dismissed it, and it
solved itself when I changed the code (which I realized that it solved itself because the number of bytes was no longer exactly 2778
bytes).
What does "nothing works" mean? No binary generated? Binary won't run?
If it won't run, how far does it get? This information is too vague to
be helpful in diagnosing anything. Certainly not every 2778 byte program
fails, so you need to be more specific before we can help. Is it 2778 of
code, or is that that total bytes including vectors? I think we have all
seen things like this at times, but it normally turns out to be a bug in
our own code. :-) Usually it turns out to be that when things are a
specific length, it put something in just the right location to show up
a bug in our own code.
- I cannot compare an unsigned char variable to 0xFF, 0xFE and 0x80, even after I cast them to unsigned chars. This is very strange.
I can compare this char to any other value, like 0xFD, 0xFC and 0x81, etc.
That's a little strange. Getting the casting wrong often gives strange
results, but not these.
- Right now I'm having trouble with global variables. I defined a variable in one of my headerfiles. My main program can change and
manipulate that variable, but if I manipulate it in the interrupt, I can confirm that change in the interrupt, but once I return to main, the
variable reverts back to its previous state (before the interrupt).
That must be something wrong in your code. The compiler certainly does
not generate a separate variable for the interrupt routine, unless you
have declared it static. Check your declarations carefully, and check
which address the interrupt code and the non-interrupt code are using
for this variable.
I've had a few other bugs, but they somehow seem to fix themselves. I don't know if these bugs are inherent in the hardware, or if its
my firmware, or the compiler, or even Linux itself. I've been suspecting my code and have been looking through it for a long time now,
but I've cut down everything to a bare minimum and still no fix.
Since I find mspgcc very solid, I suspect your code. Real bugs in the
tools are usually more reproducable that what you describe.
I can say that I get very solid results with mspgcc. It has a few rough
edges, like the debug download speed being slower than the other
toolchains, but it is a very solid development platform. The rough edges
are being addressed. :-)
Regards,
Steve
