sin() function misbehaving!

Discussion in 'Embedded Systems and Microcontrollers' started by dannybeckett, Jul 9, 2012.

  1. dannybeckett

    Thread Starter Active Member

    Dec 9, 2009
    163
    0
    Hi guys,

    Really simple program is not behaving. Works on a dsPIC33FJ256GP710A. I'm currently using a dsPIC33FJ128MC804, Same error occurs on the dsPIC33FJ32MC204.

    The result of the equation should be 1, which it is when I comment out the initPLL() function. When the processor is working a proper speed the value comes out at 3.4115467 consistently.

    proper code link:
    http://pastebin.com/t90hm4hr

    Any help is greatly appreciated,

    Dan
     
    Last edited: Jul 9, 2012
  2. Papabravo

    Expert

    Feb 24, 2006
    10,142
    1,790
    What does the processor speed have to do with the calculation of a function with a known value. BTW are you sure the argument is in degrees? Could it be in radians perhaps? What value should the variable "i" have in your alternate universe where the processor runs at the correct speed.
     
  3. dannybeckett

    Thread Starter Active Member

    Dec 9, 2009
    163
    0
    whoops, this post makes a lot more sense if i post the correct code:
     
  4. dannybeckett

    Thread Starter Active Member

    Dec 9, 2009
    163
    0
  5. dannybeckett

    Thread Starter Active Member

    Dec 9, 2009
    163
    0
    I have no idea why altering the speed changes the value like this, I'm pretty sure that pic is rated for 80mhz operation. yes it takes in radians, I have sorted that out in the code I wrote to test it all. 'i' should be 1, but it comes out at 3.odd when the clock is sped up
     
  6. Papabravo

    Expert

    Feb 24, 2006
    10,142
    1,790
    That is incorrect. The sin(45°) is most certainly not 1. In fact for any argument, the value of the sin() function must be in the the closed interval [-1,...,1]. There are no exceptions to this rule. Now 45° is the same as π/4 radians and sin(45°=π/4) = (√2 / 2) or about 0.707...

    Try to get your math facts straight before you jump to conclusions about your processor operating correctly. Also do you know how floating point numbers are encoded? Could this be a problem of not understanding what 1.0, 3.odd, or even 0.707 looks like as a floating point number? Exactly what is the purpose of computing the sin() function as an indicator of processor health? Wouldn't 2+2 work just as well?
     
  7. dannybeckett

    Thread Starter Active Member

    Dec 9, 2009
    163
    0
    I have just said that the code I initially posted was wrong. Please view the proper code before you assume I haven't got my maths straight.
     
  8. Papabravo

    Expert

    Feb 24, 2006
    10,142
    1,790
    It wasn't the code it was the text of the post with the erroneous information.

    " 'i' should be 1, but it comes out at 3.odd when the clock is sped up"

    In order to have a chance of understanding your code a schematic would be most helpful. Also can you tell me if the answer to 2+2=4 changes in the same way?
     
  9. dannybeckett

    Thread Starter Active Member

    Dec 9, 2009
    163
    0
    There is no schematic as of yet papabravo, I simply have an explorer 16 board with a PIM module connected to it, and I break the program just after the calculation is made and observe it as a 'watch' in mplab x. I will be with the equipment again tomorrow so I'll run that test then. Cheers for the help
     
  10. bretm

    Member

    Feb 6, 2012
    152
    24
    An optimizing compiler won't necessarily set j equal to 1.0. Because the value of j isn't used, it might not actually call sin() at all. You could be looking at random bytes, even though you initialize j to zero, that might be optimized away as well. Are you debugging the non-optimized version?
     
  11. Papabravo

    Expert

    Feb 24, 2006
    10,142
    1,790
    If you insist on using the sin() function I would examine the function prototype to ascertain the type and precision of the arguments and the type and precision of the return values. Then very carefully review the formatting of floating point numbers. Look for things like where are the mantissa bits, where are the exponent bits, is there an implied 1 bit for the most significant mantissa bit. These things can really trip you up if you are not careful and paying very close attention. None and I repeat none of these things have the slightest thing to do with the processor clock speed.

    We need a schematic to understand if the setup has even a chance of executing instructions properly. You wouldn't ask a knight to do single combat without his weapons -- would you?
     
  12. dannybeckett

    Thread Starter Active Member

    Dec 9, 2009
    163
    0
    Here's the code I have just run to include your test papabravo:

    http://pastebin.com/YbCZJTiH

    When PLL is disabled, i = 1.5707964, j = 1.0 and k = 6. When PLL is enabled, i = 1.5707964, j = 3.4115467 and k = 6. I am absolutely baffled.

    The compiler warns me when a value is not used, but because 1, I am initializing the variable to a value and 2, I am making j equal to the value of sin(x), j is definitely used even if optimization was enabled. I am not sure how to check but as I said, the correct values are calculated when the PLL is not enabled which would not happen if things were getting optimized away. All I want to know is why the sine function does not work properly when the pic is up to speed (my application is heavily speed dependent).

    Thank you all
     
  13. takao21203

    Distinguished Member

    Apr 28, 2012
    3,577
    463
    1. having a function call before variable declerations is slightly unusual.

    2. Do you have any guarantee initPLL is ever completed, and a return is performed?

    You should reset an external LED, switch it on inside the code of question, then switch off again.

    This is what usually helped me to verify if code in question is executed or not.

    The fact that you give that k=6 hints that the code is never executed.

    I have not used this PIC before, but I have used PLL sometimes.

    And what I suggest is easy to try.
     
  14. Papabravo

    Expert

    Feb 24, 2006
    10,142
    1,790
    I notice that your variables are all local to the main() function. The array of 100 float values on the stack could easily cause problems with the methods you are using to test this particular program. I still don't see the prototype for the sin() function. It is probably inside "math.h". Without some kind of schematic I can't tell if PLLinit() will work or not.
     
  15. dannybeckett

    Thread Starter Active Member

    Dec 9, 2009
    163
    0
    I'm not sure what schematic you are after, I literally have the dsPIC connected to an explorer 16 development board with an ICD3 for debugging and programming. Everything I am working on right now is purely software running on the PIC itself. The prototype for the sin function is in here:

    http://pastebin.com/syfnbYsU

    The code for the initPLL was pulled from a microchip dsPIC33F example, it seems like every single example for this series of pic uses the same clock code. I know initPLL works because I have tested it, I have toggled a pin from high to low with and without the initPLL function running and there is a drastic speed change. I have used this very function to populate a whole array (100 elements) with values for a sine wave, and send them out to a DAC via SPI and it worked absolutely fine on the previous chip. The code works when PLL isn't being used, it doesn't when it is.
     
  16. dannybeckett

    Thread Starter Active Member

    Dec 9, 2009
    163
    0
    i look that array out also, still no dice =[
     
  17. dannybeckett

    Thread Starter Active Member

    Dec 9, 2009
    163
    0
    i've just tried slowing the pll down to 40, then 20MHz, then 10MHz (should only let it get down to 12.5MHz really) but it still fails on every speed. So it must be something to do with the PLL being used?
     
  18. takao21203

    Distinguished Member

    Apr 28, 2012
    3,577
    463
    If the PIC is using a crystal in HS mode, that can be changed for a coil, and still using the PLL. But much slower, depends on inductivity.
    22uH is rather fast while 330uH is rather slow.

    So you could see if it is just caused by the PLL, or by the clock frequency as such.

    Whatever is causing your problems, try to isolate it and track it down.

    Try to figure out what can do what and what not at which point of time.

    For what it is worth (I don't think this is causing the issues), also try to move around the initPLL code directly inside the main, put the variable declerations elsewhere, just for completeness sake.

    Have you tried to run the program directly, not in debugging mode?

    Have you tried to replace the sin() function with a fake _sin1() function, where you return some dummy values, or very crude sine values from a table?

    Have you tried, after doing this, to change from float to long?

    Try to track the issue down as much as possible.
     
  19. Papabravo

    Expert

    Feb 24, 2006
    10,142
    1,790
    C'mon there is one and only one relevant schematic. I need to see the processor, the crystal or reference oscillator, the reset circuit and in general anything that might have an effect on the proper operation of the processor. You seem to think the problem is in the piece of software, and I think you are premature in that judgement. The relentless application of Occam's razor is the only path to the solution. In plain terms crawl before you walk by getting something simpler to work before you try to run a marathon.
     
  20. dannybeckett

    Thread Starter Active Member

    Dec 9, 2009
    163
    0
    Thankyou for these suggestions, I will try them. I have just repeated my initial test again for verification, this exact code works completely fine on the dsPIC33FJ256GP710A with PLL running.
     
Loading...