SPC56EL Watchdog Timer Interrupt (IVOR12) triggering, but WDT not enabled?

[Matthew Richardson]

Posted on March 23, 2018 at 09:21

I don't think I have a timer enabled.  I don't see the WDT setting in the outline, but in the configuration.xml it is disabled.  Most importantly clock_cfg.h is  generated as '#define SPC5_DISABLE_WATCHDOG               TRUE'.

However, almost randomly, I am getting an IVOR12 interrupt:

PC 0x00000380

CR 0x44000004

LR 0x00002D78

CTR 0x0

That said, the system runs for ten minutes, one minute, or five, then hangs up in IVOR12.  The only driver I am using is the serial drivers, and may there is an issue there?  It even triggers the ivor when degugging, which I thought the WDT was disabled for debugging as well.  

[Erwan YVIN]

Posted on March 23, 2018 at 09:56

Hello Matthew ,

The watchdog is disabled on SWT IP but not in e200 Core (HW WD)

#if SPC5_DISABLE_WATCHDOG
 /* SWT disabled.*/
 SWT.SR.R = 0xC520;
 SWT.SR.R = 0xD928;
 SWT.CR.R = 0xFF00000AU;
#endif
�?�?�?�?�?�?

About IVOR12,

the HW Watchdog is enabled by mtMSR (cf boot.s)

/*
 * MSR default settings.
 */
#define MSR_DEFAULT (MSR_SPE | MSR_WE | MSR_CE | MSR_ME)
�?�?�?�?�?

(cf chapter e200z4 document)

Best regards

Erwan

[Matthew Richardson]

Posted on March 25, 2018 at 08:33

This one took me a while to troubleshoot.  The unit will literally run for hours without crashing, then sometimes only five minutes and crash without changing any code.  

I think the issue has something to do with serial_dll.  Our program has a PIT that runs at 50Hz.  The PIT handler is used as an interrupt that periodically loads data onto an RS-232 port.  I've boiled down a program that runs, verse one that eventually crashes.

NOTE: I feel like this is *not* a IVOR12 issue, as sometimes the IVOR4 and IVOR1 are

triggered.  I think this issue is related to interrupts, most notably -

osalEnterCritical(); which is called in sd_lld_write();

This program crashes periodically (very simplified version for investigation purposes):

<<<

int main(void)

{

   componentsInit();

   irqIsrEnable();

   sd_lld_start(&SD1, NULL);  // baud 19277

   pit_lld_start(&PITD, pit_config);  // 50Hz

   pit_lld_channel_start(&PITD, 2U);

   for ( ; ; )

   {

   }

}

uint8_t message[]= 'Hello World!\r\n';

// PIT

@

50Hz 

void low_speed_PIT(void)

{

  

sd_lld_write(&SD1,message,(uint16_t)(sizeof(message)/sizeof(message[0])));

}

>>>

This program runs perfectly

(note that sd_lld is not called within PIT):

<<<

int main(void)

{

   componentsInit();

   irqIsrEnable();

   sd_lld_start(&SD1, NULL);

// baud 

19277

   for ( ; ; )

   {

      sd_lld_write(&SD1,message,(uint16_t)(sizeof(message)/sizeof(message[0])));

      osalThreadDelayMilliseconds(19);

   }

}

>>>

The issue seems (not obviously) related to putting serial data inside a PIT.  I am guessing that this is a

priority issue.  Is this an uncommon practice?  I think it is corrupting the interrupt scheme somehow.

Cheers, 

~Matt

[Erwan YVIN]

Posted on March 27, 2018 at 10:26

Hello Matthew ,

According to your description,

Your issue seems to be a coredump issue or a stack overflow issue.

A stack overflow could generate a watchdog or a memory corruption

could you check the state of your stack (cf memory windows) during the IVOR1 ?

it should be located between __process_stack_base__ and __process_stack_end__

.core0_stacks : ALIGN(16) SUBALIGN(16)
 {
 . = ALIGN(8);
 __irq_stack_base__ = .;
 . += __irq_stack_size__;
 . = ALIGN(8);
 __irq_stack_end__ = .;
 __process_stack_base__ = .;
 __main_thread_stack_base__ = .;
 . += __process_stack_size__;
 . = ALIGN(8);
 __process_stack_end__ = .;
 __main_thread_stack_end__ = .;
 } > ram�?�?�?�?�?�?�?�?�?�?�?�?�?�?

Could you increase the Core 0 Process Stack size in order to check the issue is happennign again ?

Best regards

Erwan