TI GNU assembler errors in new version

Since I had kept a copy of the older version around I tried using the new version of as with the older header file and that worked. Comparing the two versions of msp430fr5969.h shows that it has changed quite a lot. In fact I cannot tell what the device register addresses are since only the base address is defined. So I suspect that even if it could get past the sfr confusion it would die on all of the undefined symbols.

David,

Thanks for reporting the issue.  Could you please send some details on how to reproduce your particular error?

I've filed a ticket to investigate further.

Greg

What is to recreate? All that is required is a source file with "#include <msp430.h>" in it. Give it a ".S" filename suffix and let it rip.

I edited iomacros.h and was able to get it to assemble. I also discovered that all the symbols that used to be defined in the machine .h files are now defined in new _symbols.ld files used by the linker. Which came as quite a shock to the linker when it couldn't find that file. Adding the -L switch to tell it where to look fixed that.

I changed the macros for sfrb, etc to:

#define sfr_b(x)
#define sfr_w(x)
#define sfr_a(x)
#define sfr_l(x)

So it appears that someone really worked over all of machine files but then failed to test it adequately.

Hi David,

I ran in to this same issue.

Is defining sfr_* macros for assembly files to do nothing just for it to compile or is it what the header file should already be doing?

I can see iomacros.h for c files define sfr_* to define extern volatile unsigned variables, is the equivalent for assembly to define sfr_*  as .global x?

or is that just unnecessary?

i.e. I'm talking about changing sfr_* to do

#define sfr_b(x) .global x 

#define sfr_w(x) .global x

...

This does compile, but I'm not sure if it's the right thing to do.

Thanks for any help

There is no need to do anything since the assembler assumes that anything referenced that is undefined is a global. That is why changing the macros to nulls (no output at all) works just fine.

Thanks David, that makes sense. You're recent posts have been very helpful for my project to port CTPL and contiki to the fram series

Greg,

Has there been any movement on getting a fix for this into a release?

Thanks,
- Chuck

Hi Chuck,

we fixed the bug in the iomacros.h file by adding the following to the assembler section as suggested by David:

#define sfr_b(x)
#define sfr_w(x)
#define sfr_a(x)
#define sfr_l(x)

The change will make it into the upcoming MSP430 GCC release end of June.

Thanks,
Bob