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.

__TI_resource_lock(__TI_LOCK_RAND)

Other Parts Discussed in Thread: MSP430F5438A

Hi,

I have created a new project in CCSv6 - Version: 6.0.0.00156.

When I try to use the rand(); function the MSP430f5438a reboots when the line __TI_resource_lock(__TI_LOCK_RAND); is executed. This is because the address it's trying to jump to in the disassembly is 0x00000.

Is there something I have missed when setting up my project that creates this error?

I actually have another project where rand() works fine, and can't figure out whats different in it.

Thanks.

-Fredrik

From rand.c v4.3.1:

_CODE_ACCESS int rand(void)
{
     int r;

     /*---------------------------------------------------------------------*/
     /* To maintain backwards compatibility with releases that do not use   */
     /* TLS, we use a mutex lock to protect accesses to the variable 'next'.*/
     /*---------------------------------------------------------------------*/
#if !defined(__TI_USE_TLS)
     __TI_resource_lock(__TI_LOCK_RAND); <---- Here
#endif

From disassembly(when I mouse over &_lock it shows _lock = 0x000000:

0117b0:   8321                DECD.W  SP
62           __TI_resource_lock(__TI_LOCK_RAND);
0117b2:   1380 2000           CALLA   &_lock
64           next = next * 1103515245 + 12345;

  • Do you only see this when using that version of the compiler v4.3.1? Just curious if you are able to try the same project with an older version of compiler such as a 4.2.x. or 4.1.x. 

    Alternately if you are able to send us a simple project that we can use to reproduce the behavior we could take a look as well.

  • Fredrik said:
    From disassembly(when I mouse over &_lock it shows _lock = 0x000000:

    The run time start up code initializes the _lock pointer to point at the _nop function.

    Since the _lock pointer is zero it suggests the _lock pointer has been corrupted in some way, e.g. the code wrote off the end of an array or their was insufficient stack space.

    Try setting a hardware watchpoint in the CCS debugger to watch a write to the _lock pointer, so try and find what is corrupting it.

  • Thank you both for your answers and sorry for the late reply.

    It turned out to be an overflow error caused by our lcd function happening only if written to the last line. That's why we haven't seen it before.

  • BTW, I ran into much the same problem with _lock pointing to 0x0.  No amount of changing stack sizes helped. _lock was 0x0 from the moment the code was loaded, so I don't think it was corrupted.

    On a lark I downgraded my compiler from 5.2.6 to 5.2.5 and random started working at that point.  Not certain what the difference is between the two compilers, but right now it seems to be confined to 5.2.6.


    Now if I could just figure out why malloc is failing....


    Quinn