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.

Compiler/MSP430F5335: MSP430F5335 WDT does not reset the micro

Part Number: MSP430F5335

Tool/software: TI C/C++ Compiler

There is not way to reset a micro due to some init error.  Going through the debugging the function in autoinit.h function, system runs to BREAKPOINT_2 (See below), I press on run, but the system never goes back to the BREAKPINT_1, but it display an error in console

Console

Assertion failed, (!((*((volatile uint16_t *)((uint16_t)baseAddress + (0x0000)))) & (0x0002))), file ../driverlib/adc12_a.c, line 1

Code referenced above.  What can I do?


/*****************************************************************************/
/* cinit */
/*****************************************************************************/

static __inline __attribute__((always_inline)) void run_cinit(void)
{
#if defined(__TI_EABI__) && \
    defined(__MSP430__) && \
    defined(__LARGE_CODE_MODEL__) && !defined(__LARGE_DATA_MODEL__)
   /*------------------------------------------------------------------------*/
   /* Process the compressed ELF cinit table. The format is as follows:      */
   /* |4-byte load addr|4-byte run addr|                                     */
   /* |4-byte load addr|4-byte run addr|                                     */
   /*                                                                        */
   /* Processing steps:                                                      */
   /*   1. Read load and run address.                                        */
   /*   2. Read one byte at load address, say idx.                           */
   /*   3. Get pointer to handler at handler_start[idx]                      */
   /*   4. call handler(load_addr + 1, run_addr)                             */
   /*------------------------------------------------------------------------*/
   if (__TI_Handler_Table_Base != __TI_Handler_Table_Limit)
   {
      unsigned long const *table_ptr   = (unsigned long const *)__TI_CINIT_Base;
      unsigned long const *table_limit = (unsigned long const *)__TI_CINIT_Limit;

      while (table_ptr != table_limit)
      {
        unsigned long load_addr   = *table_ptr++;
        unsigned long run_addr    = *table_ptr++;
        unsigned char handler_idx = __data20_read_char(load_addr++);

        handler_fn_t handler = __TI_Handler_Table_Base[handler_idx];
        handler(load_addr, run_addr);
      }
   }
#elif defined(__TI_EABI__) || defined(__ARM_EABI__)
   /*------------------------------------------------------------------------*/
   /* Process the compressed ELF cinit table. The format is as follows:      */
   /* |4-byte load addr|4-byte run addr|                                     */
   /* |4-byte load addr|4-byte run addr|                                     */
   /*                                                                        */
   /* Processing steps:                                                      */
   /*   1. Read load and run address.                                        */
   /*   2. Read one byte at load address, say idx.                           */
   /*   3. Get pointer to handler at handler_start[idx]                      */
   /*   4. call handler(load_addr + 1, run_addr)                             */
   /*------------------------------------------------------------------------*/
#if defined(__FROZEN__)
   /*------------------------------------------------------------------------*/
   /* For C7X, use _symval() to force absolute addressing on these symbols,  */
   /* otherwise we will end up with an incorrect value if we rely on         */
   /* position-independent, PC-relative addressing.  This is a temporary     */
   /* workaround. See Jira COMPILE-362 for more information.                 */
   /*------------------------------------------------------------------------*/
   if (_symval(__TI_Handler_Table_Base) != _symval(__TI_Handler_Table_Limit))
   {
      char *const *table_ptr   = (char *const *)_symval(__TI_CINIT_Base);
      char *const *table_limit = (char *const *)_symval(__TI_CINIT_Limit);
#else
   if (__TI_Handler_Table_Base != __TI_Handler_Table_Limit)
   {
      char *const *table_ptr   = __TI_CINIT_Base;
      char *const *table_limit = __TI_CINIT_Limit;
#endif

      while (table_ptr != table_limit)  // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<  BREAKPOINT_1
      {
        char const *load_addr   = *table_ptr++;
        char       *run_addr    = *table_ptr++;
        char        handler_idx = *load_addr++;

        handler_fn_t handler = __TI_Handler_Table_Base[handler_idx];
        handler(load_addr, run_addr);  // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< BREAKPOINT_2
      }
   }
#else
   /*------------------------------------------------------------------------*/
   /* Process Cinit table for COFF.                                          */
   /*------------------------------------------------------------------------*/

    #ifdef _TMS320C6X
        #define ALIGN_TYPE uintptr_t
        #define ALIGN_MASK 0x7
    #elif defined(__MSP430__)
        #ifdef __LARGE_DATA_MODEL__
            #define ALIGN_TYPE unsigned long
        #else
            #define ALIGN_TYPE unsigned
        #endif
        #define ALIGN_MASK 0x1
    #else
        #define ALIGN_TYPE uintptr_t
        #define ALIGN_MASK 0x3
    #endif

    #define ALIGN_PTR(ptr) \
       ((unsigned const *)(((ALIGN_TYPE)ptr + ALIGN_MASK) & ~ALIGN_MASK))

   unsigned const *recptr = (unsigned const *)__cinit__;
   int length;

   if (recptr != (unsigned *)-1)
      while ((length = *recptr++) != 0)
      {
#if defined(__MSP430__) && defined(__LARGE_DATA_MODEL__)
	 char *to = (void *)*(unsigned long const *)recptr;
	 recptr += 2;
#else
	 char *to = (void *)*recptr++;
#endif

	 char *from = (void *)recptr;

	 memcpy(to, from, length);

	 from += length;
	 recptr = ALIGN_PTR(from);
      }
#endif
}

  • Part Number: MSP430F5335

    On my MSP430, in most cases when I execute this code:

    WDTCTL = WDT_ARST_1000;
    while (1);

    the micro resets, but at times the micro does not reset but goes into loop described here ().  Why would it not reset every time?  In fact, in the same case, if the code above is replaced by:

    PMMCTL0 = PMMSBOR | PMMPW;

  • Hello Silver,

    Be default when the part starts up, it should have the WDT enabled for a 32ms timeout and long CINITs can actually cause the device to reset before starting your code. We usually recommend turning off the WDT during a long CINIT for these cases. Is there anyway you are turning off the WDT before this loop? Can you attach to running target when it is stuck to check the WDT registers?

    Is this situation forma cold boot or some sort of PUC?
  • WOW, if the ADC12 is working, the WDT reset or PMMCTL0 |= PMMSWBOR does NOT work. So I turn the WDT into timer and in ISR execute ADC12CTL0 = 0; than reset works fine. Is this a know issue? Making a system that is not able to reset in all conditions is bad. If the system boots up, it should be able to reset.
  • Jace, I pushed a wrong button, your commend actually did not resolve my issue. So this issue occurs only when the ADC is working and WDT times out or any PUC, like PMMCTL0|= PMMSWBOR.

  • Silver,

    Are you able to reproduce the issue with simplified code? Like just using an ADC example and try to reset? What ADC settings do you have with the error?
  • No, I did not attempt to build a simplified code, but I am able to reproduce the error with my code.  Regardless, the WDT soft reboot should not depend on my code, if the system can soft reboots in one case, it should work the same way every time, otherwise what is the point of the WDT? 

  • So, when I set `ADC12CTL0 = ADC12SHT02 + ADC12SHT12 + ADC12ON;` the reboot does not work.
  • Silver,

    the reason I'm trying to see if it happens with simplified code is two fold;
    1) Is turning on the ADC really the "trigger" that prevents the WDT in your case?
    2) you seem to be doing your own CINT file which could differ from what the compiler will do on its own. The WDT timer maybe accidentally turned off.

    Is this error happening with the debugger connected? Or is it stand alone or in free run mode? Sometimes having the debugger connected can cause or mask issues due to timing differences of the EEM module introduces. (It is an intrusive debug.) If you are seeing this while standalone or free running, then I would suggest doing a attach to running target to pause the MCU with the EEM, and check the status of the WDT registers to make sure they are set correctly.
  • Jace,

    I understand what you are saying, but I do not do my own CINIT file, the debugger takes me through TI CINIT file.  Setting the ADC12CTRL0 = 0; makes my resets predictable, otherwise the system gets stuck.  Everything is the same except value of ADC12CTRL0, why?  That does not make sense.  I do not have time to write the minimum code to isolate the issue.  Why is the CCS8 point to assert in ADC driverlib?

  • Silver,

    Are you able to attach to running target and check the register settings of the WDT when the issue occurs? I do not have any answers for you unless we can narrow down the issue.

    From your previous comment, it seems you are using driverlib. Is this the case? If so, are you using any functions that may reset the WDT when called?
  • Hello Silver,

    Have you been able to do the "attach to running target" test?
  • Jace,

    I did, right before soft resetting the unit, I verified that the WDT is set correctly. At this point, in my reset routine, I just disable ADC12A, and I have not seen this issue anymore. On the other hand, how does assert work, where does CCS8 get the information to show the following in the console:

    Assertion failed, (!((*((volatile uint16_t *)((uint16_t)baseAddress + (0x0000)))) & (0x0002))), file ../driverlib/adc12_a.c, line 1

  • Silver,

    CCS would be getting that assertion information from DriverLib. you would have to check the Driverlib details for more information about the assert. This maybe a part of the reason for your issue.

    Please see this other E2E thread about DriverLib assert. I think you were a part of this discussion. e2e.ti.com/.../309119

**Attention** This is a public forum