View Full Version : [Question(s)] Math.h lib with Bioloid CM-530 and C

03-05-2013, 05:20 PM

I am trying to program a CM-530 using C and the examples provided by Robotis. The problem is that I am having trouble with floating point math because there is a problem with the math.h library being linked during the building of the project. I have been looking for a solution for days, so I thought I would ping the community to see if anyone else has had success doing floating point math on a CM-530. The interesting thing is that if you use math.h functions with constants, the compiler pre-calculates the values and skips the linking (that tricked me in to thinking things were working fine), but if the compiler can't pre-calculate, then the library has to be linked and I get a linking error.

From what I have read, the Cortex-M3 processor supports at least software floating point, so it seems like it should work. I'm open to any and all ideas. Thank you in advance.

03-05-2013, 06:19 PM
Did you add "-lm" to the linker options/flags? When I omit that, I get:

...arm-none-eabi/lib/libm.a(lib_a-w_log.o): In function `log':
w_log.c:(.text.log+0x130): undefined reference to `__errno'
w_log.c:(.text.log+0x140): undefined reference to `__errno'
w_log.c:(.text.log+0x150): undefined reference to `__errno'
make: *** [cm530_math_test.elf] Error 1

Adding it compiles and links fine, but I do not have a CM-530 with me to check whether it actually works correctly. A quick look through the .lss file shows lots of libm related functions, so I would hope it works right. The basic source file and modified makefile are attached (they expect my cm530 (https://github.com/tician/cm530/) repo for misc. device setup and the arm-none-eabi-gcc compiler which might be different from what you are using).

03-05-2013, 07:50 PM
Thank you for responding so quickly, tician. I have included the -lm in multiple places within the linker options (I read some where that order can matter). Even with -lm in the linker options, the errors I am getting are similar to the one you posted, in fact I get that one too, but I also get more undefined references to __aeabi_fadd, __aeabi_fsub, __aeabi_dadd, etc. etc.

As a side note, I'm using the arm-eabi-gcc compiler, so I will try it with the arm-none-eabi-gcc compiler since you have had success with that.

03-06-2013, 07:28 AM
Windows with WinARM, or linux? WinARM should work out of the box, so to speak, as arm-eabi-gcc. Linux requires manual installation of the arm-none-eabi (baremetal) toolchain since ubuntu packages only the arm-gnu toolchains, which require a linux kernel running on the processor (not likely for Cortex-M3).

Order does matter in newer versions of gcc (older versions were tolerant of mis-ordering, but not happy). The library/linker options/flags have to follow the other build options and target when sent to gcc (took a while to figure that one out when first upgrading the DARwIn-OP to 12.04-server from 10.04). If you add "-lm" to the very end of the "LDFLAGS" line in the makefile (after "-T stm32.ld "), it should work.

03-06-2013, 07:56 AM
I'm using WinARM on 32-bit Windows 7. Unfortunately, arm-eabi-gcc is the compiler that is giving me the errors. Last night I installed arm-none-eabi-gcc and used your Makefile (with a small tweak to the output file name, of course) in my project. The build completed with no link errors. I'm going to try it on the CM-530 sometime this morning and see if it actually works, or if it is just a mirage. Thanks again for your help.

03-06-2013, 08:29 AM
I've got an update. Everything builds fine, I checked the lss file as well and I see lots of math.h stuff in there, but when I load and run the program it's just a test of the square root function, it runs right up until the sqrt call at which point it hangs. Any ideas? This is getting in to that place where things are harder to debug and I don't have a ton of experience writing embedded C. Thanks.

03-06-2013, 08:47 AM
One more update, just in case it is helpful. I removed the sqrt function call and just added some floating point arithmetic and type casting (careful to make sure that the compiler doesn't just pre-calculate the operations) to see if it was related to that, and it hangs on simple float division with two float variables. Again, everything builds fine, and I see the proper functions (__aeabi_fdiv) being linked in the lss file, so now there seems to be some issue with the controller. Are there any compiler or linker options I need to include to trigger the floating point support? Thanks.

03-06-2013, 11:15 AM
Progress! I had to update your Makefile to include -msoft-float and -mfpu=vfp to the COMPILE_OPTS. I am not sure if I needed to, but I also added them to the link options as well. So to sum up, in case anyone else is having these same issues, my path to getting this working looked something like this:

On my 32-bit windows machine:
1) Set up my environment per the instructions from Robotis for embedded C programming...this doesn't work with floating point out of the box.

2) Installed the arm-none-eabi-gcc compiler and replaced the Makefile in my project with the one from tician's post (post #2) above (modifying the MAIN_OUT accordingly). This solved the linking issues with the math.h library, but the controller would still lock up whenever a float operation was excecuted.

3) Edited the Makefile by adding the -mfpu=vfp -msoft-float flags to the compiler options and linker options, and this solved the controller crashing during floating point operations. The respective lines in the Makefile now look like this:

COMPILE_OPTS = -mcpu=cortex-m3 -mthumb -mfpu=vfp -msoft-float -Wall -g -Os -fno-common -lm

LDFLAGS = -mcpu=cortex-m3 -mthumb -mfpu=vfp -msoft-float -Wl,--gc-sections,[email protected],-cref,-u,Reset_Handler $(INCLUDE_DIRS) $(LIBRARY_DIRS) -T stm32.ld -lm

It's possible that the -msoft-float is optional, and it may be optional to include them in the linker flags, but I have already spent more time than I should have on this, so perhaps someone can test those out and confirm. I hope this ends up being helpful to others. Thank you tician for the great starting point.