• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 80 subscribers
  • Views 1809 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430 weird behavior of math.h functions

Shuozhi Yang
Intellectual 440 points
Other Parts Discussed in Thread: MSP430F2274, MSP430F1232

Hi,

I am trying to use sin(), cos() and sqrt() functions from math.h in my project, and I got some weird behavior from them. Each time I run the program, these functions gave me different results for the same input data. The test code is as follows, all variables are floating type (32-bit):

dummy=1.234;

dummy1 = sin(dummy);

dummy2 = cos(dummy);

dummy3 = sqrt(dummy);

I first saw this problem with sqrt() that always gave incorrect results for any floating data with decimal, such as 1.2, 16.1, 0.09, etc, but correct results for integers like 16.0, 4.0, etc. Then I found that sin() and cos() were not working properly either. The results from sin() and cos() were kind of random, but some time (about 20% of time) they gave me correct results. As I added more code in the project, the results changed as well.

I tried the same test code on three board, two with MSP430F2274 and one with MSP430F1232. So far only the one with MSP430F1232 gave me correct calculation for all the functions. Besides the test code

I am wondering if this problem is somehow related to the execution of the run-time library. I search similar problem on E2E community and followed some instructions to check the memory location of the sin()/cos()/sqrt() function and make sure that they were intact in execution. They are actually intact.

I would really appreciate any suggestions on my problem!

 

Yang

  • 0
    Guru 227245 points

    Well, I think the 1232 is the only one that has no hardware multiplier module (I haven't checked)
    It is possible that the implementation of these funcitons is faulty in the runtime library version that uses the hardware multiplier. Or code is linked that uses the HWM when there actually is none, so e.g. the correction of the decimals fails, which is not necessary if there are none.
    Or does your program do any multiplications inside ISRs? If the HWM is used inside an ISR while the main code jsut uses it too, you get corrupted results in main. (Usually, the compiler disables interrupts before using the HWM to avoid this, but who knows how the runtime lib was compiled).

  • 0 in reply to Jens-Michael Gross
    Intellectual 440 points

    I tried to avoid complex computation inside ISR. 

    I found a solution to this problem. I lowered the clock frequency from 16MHz to 12MHz, and then everything started to work properly! Is it possible that when using highest DCO frequency, the processor gets instable in the execution of run-time library? I don't have any clue. 

    Further explanation would be appreciated.

    Thank you very much for you reply!

  • 0 in reply to Shuozhi Yang
    TI__Genius 14940 points

    This kind of indicates you may have a supply voltage problem.  Note that you must be at a minimum of 3.3V to operate at 16MHz as shown in this graph taken from the 2274 spec sheet.

     

    If your setup is using a battery you may want to get a new one.  If it is powered by the debugging probe you may need to make sure you don't have some voltage drop due to some jumper setting or other cause on your target board.

    Jim Noxon

  • 0 in reply to Jim Noxon
    Intellectual 440 points

    Thank you so much! This totally answered my question! 

  • 0 in reply to Jim Noxon
    Guru 227245 points

    Good catch, Jim.

    Usually, with VCC too low, the code will either still run okay, or run wild and fail to reach the checkpoint at all. Or crash completely.
    It's a rare case that it almost works and only the calculation results are wrong.

     

    But to give an additional answer to the DCO question: The DCO can indeed run the CPU with a larger frequency than allowed, even if programmed to do not.

    The reason is that the DCO ha sonly a few discrete frequency outputs. To get an average frequency, it is programmed to switch between two frequencies, a larger and a smaller one, every so often. The average frequency then might be okay, but during the process, it will still exceed the limit:

    e.g. if the DCO only has 15 and 17MHz output, it can be programmed to make one clock cycle with 17 and one with 15MHz, giving an average of 16MHz. However, every second clock cycle is too short to ensure proper operation. It may or may not work.

    Some time ago I calculated a maximum safe target frequency of ~14.3MHz when letting the FLL adjust the DCO output (for one specific MSP, based on the worst case datasheet informations)

  • 0 in reply to Jens-Michael Gross
    TI__Genius 14940 points

    Thanks JM.  I remembered seeing your comment about the true max for the DCO in a previous post but I couldn't find it to reference.  Thanks for restating it.

    Jim Noxon

**Attention** This is a public forum