CM0 sometimes hardfaults after SW reset.

Kernel
1

megazap wrote on Tuesday, August 26, 2014:

I’m having trouble tracking down a rare hardfault that sometimes happens after doing a SW reset of an Cortex M0 (Atmel SAMD20).

The restored PC=0x00001a70 points to the vPortSVCHandler:
__asm volatile (
1a6c: 4b08 ldr r3, [pc, #32] ; (1a90 )
1a6e: 6819 ldr r1, [r3, #0]
1a70: 6808 ldr r0, [r1, #0]

r0 = 0x20001308
r1 = 0x20200980
r3 = 0x20000de4

I cant figure out whats corrupted or rather why because everything is reset. To try to isolate things i disable everything from my normal application and only kept a task that waits for 100ms and then do a SW resets. It takes everything from a few hours to a couple days to reproduce with this minimal application.

I have also verified that no other interrupts are enabled other than SVC(prio 0), SV(prio 255) and systick(prio 255, every 1ms).

All help or ideas are welcome.

FreeRTOS version 7.4.2

/Johan

2

rtel wrote on Wednesday, August 27, 2014:

What is the difference to the SAMD20 between a hard reset and a soft reset? Is it possible that peripherals are still generating interrupts, or that the RAM is not being initialised correctly (or that interrupts are being generated while the RAM is being initialised) after a soft reset?

Regards.

3

megazap wrote on Wednesday, August 27, 2014:

With a SW reset i refer to a call to NVIC_SystemReset(), a hard reset is done using the external reset pin. The external pin is not affected when doing a SW reset.

The test application never enables any peripheral interrups neither before or after the scheduler is started.

What do u mean with the RAM not being initialized correctly?

r1 = 0x20200980 is way of because the MCU(SAMD20G16) only have 16k RAM.