• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 79 subscribers
  • Views 676 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.

CC430F5137 Periodically Reboots

Lior Baz
Intellectual 375 points
Other Parts Discussed in Thread: CC430F5137

Hello team,

I am a newbie with MSP430, and I am using a CC430F5137 for A/D sampling and RF transmit.

It seems that my program keeps rebooting every ~10 seconds. When I use the debugger, it performs the execution cycles as it should, but when I let it run repeatedly, I can see it transmit the "welcome" message over and over again (this should happen only once, at the start of the execution).

I have large data buffers (I am using IAR which resets these structures, thought I minimized it by using "__no_init" pragma ), and it takes time to init all these structures, so I've disabled the WDT during __low_level_init().

Could you kindly assist me with finding a lead? I would thank for any guiding questions.

Thank you,

Lior.

  • 0
    Guru 227245 points

    Didn't I answer a similar quesiton jsut a few hours ago?

    YOu see the welcome message, so the firmware starts and the problem ahs nothing to do with your init.

    You didn't post any of your code, but in this other thread, the reason was a change of the timer (compared ot the original demo code) and an accidentally enabled interrupt for which no ISR existed.
    So when the timer did overrun after ~11 seconds, the MSP jumped into the void and did a reset.

    The description (repeated elcome message) and the interval (~10s) in both cases doesn't seem to be a coincidence. YoU're not the only one doing the same thing at the same time, facing the same problem. :)

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

    Hey Jens-Michael,

    Thanks for the quick response. I agree that the iissue seems very similar - Could you please refer me to the exact case you've answered? I couldn't find it by a regular search.

    I will try to implement the suggested solution and update the post.

    Thanks,
    Lior. 

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

    OK, I narrowed it down to this:

    When I enable this code (specifically, the line inside the "for" loop), I get periodically resets. When I comment it out - all is OK.

    I guess that sum_sq32 accumulates a huge value - however, how can this cause a reset...?

    uint16 UTIL_CalcRMS(register uint16 *buff_ptr,register uint16 buff_len)

    {

       buff_p = buff_ptr;
       sum_sq32=0;

       uint32 sum_sq32;
       uint16 *buff_p;     // See buffer below the code.
       uint16 buff_idx;    // Typical value is ~543.

       for (buff_idx=0;buff_idx<buff_len;buff_idx++,buff_p++)
       {
           sum_sq32 += (uint32) (((uint32)*buff_p) * ((uint32) *buff_p)); // <<<=== PROBLEM <<<====!!!!
       }

    }

    I've also copied the Buffer to here (each 2 bytes is an array's value. i.e: {31 00} ==> 0x0031 = 49 Decimal). Basically, it is the positive sinusoidal wave which I've  sampled, and the values starts at value 49, raises to peak value of 2090 and goes back down to 41:

    31 00 3b 00 46 00 50 00 5b 00 66 00 71 00 7c 00 86 00 91 00 9c 00 a7 00 b2 00 bc 00 c7 00 d2 00 dd 00 e8 00 f2 00 fc 00 07 01 12 01 1d 01 27 01 32 01 3c 01 47 01 52 01 5c 01 67 01 71 01 7c 01 86 01 91 01 9c 01 a6 01 b0 01 bb 01 c6 01 d1 01 dc 01 e5 01 f1 01 fb 01 05 02 10 02 1a 02 25 02 2e 02 39 02 44 02 4e 02 59 02 63 02 6e 02 78 02 82 02 8c 02 97 02 a1 02 ad 02 b6 02 bf 02 cb 02 d6 02 df 02 eb 02 f5 02 ff 02 09 03 13 03 1e 03 29 03 33 03 3d 03 47 03 52 03 5c 03 66 03 70 03 7b 03 85 03 8f 03 99 03 a3 03 b5 03 bf 03 c9 03 d3 03 dd 03 e7 03 f0 03 fb 03 04 04 0e 04 17 04 21 04 2a 04 34 04 3e 04 47 04 51 04 5a 04 64 04 6d 04 76 04 7f 04 89 04 91 04 9b 04 a5 04 ae 04 b7 04 bf 04 ca 04 d3 04 dc 04 e6 04 ef 04 f8 04 01 05 0a 05 13 05 1c 05 25 05 2e 05 37 05 3f 05 4a 05 52 05 5b 05 64 05 6e 05 77 05 7f 05 88 05 91 05 99 05 a2 05 ab 05 b4 05 bd 05 c6 05 cf 05 d7 05 df 05 e9 05 f1 05 fb 05 02 06 0b 06 13 06 1c 06 24 06 2c 06 35 06 3e 06 46 06 4e 06 56 06 5f 06 66 06 6e 06 76 06 7e 06 85 06 8d 06 95 06 9c 06 a4 06 ab 06 b3 06 ba 06 bf 06 c9 06 d0 06 d8 06 df 06 e6 06 ec 06 f3 06 fb 06 ff 06 09 07 0f 07 16 07 21 07 28 07 2f 07 36 07 3c 07 3f 07 49 07 4f 07 56 07 5c 07 62 07 68 07 6e 07 74 07 7a 07 81 07 84 07 8b 07 90 07 95 07 9b 07 a0 07 a5 07 ab 07 af 07 b5 07 ba 07 be 07 bf 07 c7 07 cb 07 ce 07 d3 07 d7 07 da 07 de 07 df 07 e4 07 e7 07 ea 07 ee 07 f1 07 f3 07 f6 07 f9 07 fb 07 fd 07 ff 07 ff 07 ff 07 ff 07 ff 07 ff 07 ff 07 ff 07 0e 08 0f 08 11 08 12 08 13 08 15 08 16 08 16 08 17 08 19 08 1a 08 1b 08 1b 08 1d 08 1e 08 1f 08 1e 08 1f 08 1f 08 21 08 22 08 22 08 23 08 23 08 24 08 25 08 25 08 25 08 25 08 26 08 26 08 27 08 28 08 27 08 28 08 27 08 29 08 29 08 2a 08 2a 08 2a 08 2b 08 2a 08 2c 08 2b 08 2b 08 2b 08 2c 08 2c 08 2d 08 2c 08 2d 08 2d 08 2d 08 2d 08 2d 08 2e 08 2d 08 2e 08 2e 08 2e 08 2d 08 2d 08 2d 08 2d 08 2d 08 2c 08 2c 08 2a 08 28 08 28 08 26 08 24 08 21 08 1f 08 1f 08 1f 08 1e 08 1d 08 1b 08 1a 08 17 08 15 08 13 08 11 08 0f 08 ff 07 ff 07 ff 07 ff 07 ff 07 ff 07 fd 07 fb 07 f9 07 f6 07 f3 07 ef 07 ec 07 e9 07 e7 07 e3 07 df 07 df 07 de 07 dd 07 dc 07 db 07 da 07 d9 07 d7 07 d7 07 d6 07 d5 07 d4 07 d2 07 cf 07 cd 07 cb 07 ca 07 c8 07 bf 07 bf 07 bf 07 bd 07 b9 07 b6 07 b3 07 ae 07 ab 07 a6 07 a2 07 9e 07 99 07 94 07 8e 07 89 07 85 07 7f 07 79 07 73 07 6e 07 67 07 5f 07 5b 07 54 07 4e 07 47 07 3a 07 32 07 2c 07 24 07 1f 07 16 07 0f 07 07 07 ff 06 f8 06 f0 06 ea 06 e1 06 db 06 d2 06 cb 06 bf 06 bc 06 b4 06 ac 06 a4 06 9d 06 94 06 8c 06 85 06 7c 06 76 06 6d 06 65 06 5d 06 55 06 4d 06 45 06 3c 06 35 06 2c 06 23 06 1b 06 14 06 0b 06 03 06 fb 05 f2 05 eb 05 e3 05 d9 05 d1 05 c9 05 bf 05 b8 05 af 05 a7 05 9f 05 96 05 8e 05 85 05 7c 05 73 05 6b 05 62 05 59 05 4f 05 47 05 3e 05 35 05 2d 05 24 05 1a 05 11 05 08 05 ff 04 f5 04 ec 04 e1 04 d8 04 cf 04 c6 04 bb 04 b1 04 a7 04 9d 04 93 04 89 04 7f 04 74 04 69 04 5f 04 55 04 4b 04 3f 04 36 04 2b 04 20 04 15 04 0b 04 00 04 f6 03 eb 03 df 03 d5 03 cb 03 b6 03 ab 03 a1 03 95 03 8a 03 7f 03 74 03 68 03 5d 03 52 03 46 03 3b 03 2f 03 24 03 18 03 0d 03 02 03 f7 02 eb 02 df 02 d4 02 c8 02 bd 02 b2 02 a6 02 9b 02 8f 02 84 02 79 02 6e 02 62 02 56 02 4b 02 3f 02 35 02 2a 02 1f 02 14 02 08 02 fe 01 f3 01 e8 01 dd 01 d2 01 c7 01 bd 01 b1 01 a8 01 9d 01 92 01 87 01 7d 01 72 01 68 01 5d 01 52 01 47 01 3c 01 32 01 27 01 1c 01 11 01 07 01 fc 00 f1 00 e7 00 db 00 d0 00 c6 00 bb 00 b1 00 a6 00 9b 00 91 00 86 00 7c 00 71 00 67 00 5b 00 51 00 47 00 3c 00 32 00 29 00

  • 0 in reply to Lior Baz
    Intellectual 375 points

    Another update:

    Lior Baz said:

    uint16 UTIL_CalcRMS(register uint16 *buff_ptr,register uint16 buff_len)

    {

       buff_p = buff_ptr;
       sum_sq32=0;

       uint32 sum_sq32;
       uint16 *buff_p;     // See buffer below the code.
       uint16 buff_idx;    // Typical value is ~543.

       for (buff_idx=0;buff_idx<buff_len;buff_idx++,buff_p++)
       {
           sum_sq32 += (uint32) (((uint32)*buff_p) * ((uint32) *buff_p)); // <<<=== PROBLEM <<<====!!!!
       }

    }

    I've managed to narrow down the problematic issue to a single command within the "for" loop:
    1. The following expression DOESN'T cause the issue: *buff_p; (just approaching the variable , without casting or assignment)
    2. The following expression still causes the issue: (uint32)*buff_p;
    3. The following expression still causes the issue: (some uint16 or uint32 variable) = *buff_p;
    So it seems that when I perform actions using this pointer, it will eventually cause a reset action (approx. after 20 - 40 times entering enter that "for" loop).
    Any leads? Suggestions? Debugging steps I can follow? Traces? 
    Thanks,
    Lior.

  • 0 in reply to Lior Baz
    Guru 227245 points

    Lior Baz said:
    DOESN'T cause the issue: *buff_p;

    Well, this statement has no effect, so it is most likely completely discarded by the compiler (except if the variable read is volatile - then the compiler mus tgenerate an access).

    It is possible that your buff_p points to a vacant memory location. Any access may cause a reset then. (actually, it will trigger a vacant memory access NMI, but since you don't have an ISR for NMI...)

    However, you're 'overcasting'.

    It is sufficient to write

    sum_sq32 += (uint32)(*buff_p)*(*buff_p):

    Since one of th eoperands of teh multiplicaiton is an uint32, th othe rone is automatically expanded, and the result of the operation is an uint32 too.

    Note that for better readability (and less ambiguit) i did put the *buff_p into brackets.

    Also, it makes no sense demanding the puff_ptr parameter as register variable (it already comes in a register nayway on most compilers, unless you have a long or variable parameter list), and then you assign it to a local variable (which is probably on the stack) and use this local variable for all the work.

    Also, you should declare your local variables before you use them. Don't you get a compiler warnin?
    Imagine what happens if there is a global variable buff_p. Now you assign buff_ptr to buff_p (th eglobal variable), then you declare buff_p (local variable) and from this moment on you use it - and never assigned something to it, so it may start with 0 or with a random value.
    You should get some warning like 'local declaration of buff_p shadows global declaration" on the line uint16 * buff_p:

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

    Hey, thanks again for the reply. Since I wish to learn from this experience, rather than just solve the problem, I have a few questions regarding your comments:

    Jens-Michael Gross said:

    (actually, it will trigger a vacant memory access NMI, but since you don't have an ISR for NMI...)

    Is it possible to write an ISR for such NMI case? Alternatively, is it possible to prevent the reset and let it just halt, so I can check registers and SFR for an error (easier for debug purposes)?

    Jens-Michael Gross said:

    However, you're 'overcasting'.

    It is sufficient to write

    sum_sq32 += (uint32)(*buff_p)*(*buff_p):

    Since one of th eoperands of teh multiplicaiton is an uint32, th othe rone is automatically expanded, and the result of the operation is an uint32 too.

    How come one of the operands is uint32? It is declared as uint16...

    Jens-Michael Gross said:

    Also, it makes no sense demanding the puff_ptr parameter as register variable (it already comes in a register nayway on most compilers, unless you have a long or variable parameter list), and then you assign it to a local variable (which is probably on the stack) and use this local variable for all the work.

    Also, you should declare your local variables before you use them. Don't you get a compiler warnin?

    You are 100% correct - it was a mistake in the copy-paste action.. :) However, it is weird that I haven't received any compiler warning....

    Anyhow, I could check the issue again only next week - I will update this thread once I will get to it.

    Thanks,

    Lior. 

  • 0 in reply to Lior Baz
    Guru 227245 points

    Lior Baz said:
    How come one of the operands is uint32? It is declared as uint16...

    hence one (!) cast to uint32. The others were superfluous.
    (uint32)(*buf_p) is an uint32. Multiplying an uint32 with an uint16 or less auto-casts the other operand to uint32 too (all operands are cast to the size of the largest operand), and the result is an uint32 too (again, size of the largest operand).
    So it is sufficient to cast one operand to uint32. But be careful, the size of the largest operand is done for each operator separately, not for the whole formula.

    So "uint16*uint16+uint32" does a 16*16 bit multiplication and a 16 bit result, then expands the result to 32 bit, doe sthe addition and returns a 32 bit result.

    Lior Baz said:
    Is it possible to write an ISR for such NMI case?

    Sure. Jus twrite an ISR for the system NMI vector. YOu may put a while(1) into it to catch the processor. (and/or place a breakpoitn on it)

    Lior Baz said:
     is it possible to prevent the reset and let it just halt

    No. When the processor tries to call a non-existent ISR, it fetches 0xffff from teh vector table. THis makes the processor execute code at 0xfffe (LSB ignored) which actually is the reset vector (so the reset funciton address is interpreted as instruction) and then continues (depending on what this 'instruction' looks like) to 0x0000. Which will cause an instruction fetch error (teh processor mus tnot fetch code from peripheral memory) which causes a reset.

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

    Jens-Michael Gross said:

    It is possible that your buff_p points to a vacant memory location. Any access may cause a reset then. (actually, it will trigger a vacant memory access NMI, but since you don't have an ISR for NMI...)

    Hey Jens-Michael,

    I've tried it again today, and an invalid address was indeed the cause for the reset. I've fixed my code so it will not exceed the correct memory range and... no reset! :)

    Thank you very much again.

    Lior.

**Attention** This is a public forum