ADC enable leading to a hard fault on Atmel SAMD20G16 (ASF)

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi folks,

 

I noticed that the ISR shows hard fault whenever I try to enable the ADC. I've attached a screen shot with the various registers and call stack.

Also, I've noticed that the fuses get overwritten whenever I am programming/flashing the uC via SWD-Atmel-ICE! Please find attached main.c and conf_clocks.h 

 

Any help would be much appreciated.

 

With regards,
Jenson

 

 

Attachment(s): 

This topic has a solution.

Newbie to the world of Atmel SAM D microcontrollers.

Last Edited: Mon. Dec 18, 2017 - 11:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is what the registers of the Device Programming - Fuses hold:

ADC_LINEARITY_0 = 0x1F
ADC_LINEARITY_1 = 0x07
ADC_BIASCAL = 0x07
OSC32KCAL = 0x7F
DFLL48M_COARSE_CAL = 0x3F
DFLL48M_FINE_CAL = 0x3FF
NVMCTRL_ROOM_TEMP_VAL_INT = 0xFF
NVMCTRL_ROOM_TEMP_VAL_DEC = 0x0F
NVMCTRL_HOT_TEMP_VAL_INT = 0xFB
NVMCTRL_HOT_TEMP_VAL_DEC = 0x0F
NVMCTRL_ROOM_INT1V_VAL = 0xFF
NVMCTRL_HOT_INT1V_VAL = 0xFF
NVMCTRL_ROOM_ADC_VAL = 0xFFF
NVMCTRL_HOT_ADC_VAL = 0xF77
NVMCTRL_BOOTPROT = 0x07
NVMCTRL_EEPROM_SIZE = 0x07
BOD33USERLEVEL = 0x3F
BOD33_EN = [ ]
BOD33_ACTION = 0x01
WDT_ENABLE = [X]
WDT_ALWAYSON = [X]
WDT_PER = 0x0F
WDT_WINDOW_0 = [X]
WDT_WINDOW_1 = 0x07
WDT_EWOFFSET = 0x0D
WDT_WEN = [X]
BOD33_HYST = [X]
NVMCTRL_REGION_LOCKS = 0xFE7F

OTP4_WORD_0 = 0xFFFFFFFF (valid)
OTP4_WORD_1 = 0xFFFFFFFF (valid)
OTP4_WORD_2 = 0xFFFFFFFF (valid)
TEMP_LOG_WORD_0 = 0xFFFFBFFF (valid)
TEMP_LOG_WORD_1 = 0xF77FFFFF (valid)
USER_WORD_0 = 0xFFFEBFFF (valid)
USER_WORD_1 = 0xFE7FFFEF (valid)

I don't understand why the WDT is getting enabled while I am programming!!?

Newbie to the world of Atmel SAM D microcontrollers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks like adc_is_syncing is causing a hard fault. I'd be stepping through the code to find out what is wrong.
My guesses:
Adc pwr not enabled
Adc clk not enabled
Null pointer.

Can you observe the adc registers in the debugger? If not that suggests no pwr or clk to the adc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Looks like adc_is_syncing is causing a hard fault. I'd be stepping through the code to find out what is wrong. My guesses: Adc pwr not enabled Adc clk not enabled Null pointer. Can you observe the adc registers in the debugger? If not that suggests no pwr or clk to the adc.

 

Hi Kartman,

Thanks for the heads up. I'm single stepping through the code right now. 
Correct me if I'm wrong, the ADC registers are the one on the right of the screenshot I posted? ADC pwr and clk are to be enabled in config or through hardware? 

Regards,

Jenson

Newbie to the world of Atmel SAM D microcontrollers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PWR and the clock are both setup by ASF in adc.c

	/* Turn on the digital interface clock */
	system_apb_clock_set_mask(SYSTEM_CLOCK_APB_APBC, PM_APBCMASK_ADC);
	.
        .
        .
	/* Configure GCLK channel and enable clock */
	struct system_gclk_chan_config gclk_chan_conf;
	system_gclk_chan_get_config_defaults(&gclk_chan_conf);
	gclk_chan_conf.source_generator = config->clock_source;
	system_gclk_chan_set_config(ADC_GCLK_ID, &gclk_chan_conf);
	system_gclk_chan_enable(ADC_GCLK_ID);

Your attached main.c and conf_clocks.h work for me with D21.
/Lars

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Lars,

So it's either the hardware having issues or my fuse settings then? I'm attaching the full project, maybe you can find out what ASF component I've failed to add.

Regards,
Jenson

Attachment(s): 

Newbie to the world of Atmel SAM D microcontrollers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Replaced the microcontroller with a new one and the issue persists. Not sure if it's clocks being wrongly configured or the watchdog being enabled and always being wrong is the culprit!?!

Newbie to the world of Atmel SAM D microcontrollers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Looks like adc_is_syncing is causing a hard fault. I'd be stepping through the code to find out what is wrong. My guesses: Adc pwr not enabled Adc clk not enabled Null pointer. Can you observe the adc registers in the debugger? If not that suggests no pwr or clk to the adc.

Hi Russell,

The registers in the I/O section, right? I can see them. The weird thing is that the fuses get changed when adc is syncing hard faults. The fuses don't change with USART or I2C which has me confused. 

Regards,

Jenson

Newbie to the world of Atmel SAM D microcontrollers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the line of code that is causing the hard fault - it has to be a memory access. What is the address it is trying to access?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Russel,

 

static inline bool adc_is_syncing(

struct adc_module *const module_inst)

{

/* Sanity check arguments */

Assert(module_inst);

Adc *const adc_module = module_inst->hw;

if (adc_module->STATUS.reg & ADC_STATUS_SYNCBUSY) {

return true;

}

return false;

}

This piece of code used to cause a hard fault "Adc *const adc_module = module_inst->hw;" but now it's the if condition right after that statement. 

Newbie to the world of Atmel SAM D microcontrollers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You need to trace the assembler code. That way you can see precisely which instruction and check the address value it is using. How do you do this in Atmel Studio? Not sure as i rarely use it, but there is a disasm window methinks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry Russel, I decided to get the USART and I2C modules working before I returned back to the ADC issue. Here is the screenshot of the disassembly:

 

I have noticed the fuses get changed when I'm running the ADC module. Doesn't happen while I'm running the I2C and USART modules !!! Any ideas about this?

 

Regard,
Jenson

Newbie to the world of Atmel SAM D microcontrollers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

R3 is loaded with 0xffffffff
That's going to give a hardfault. Adc_module doesn't seem to have the correct address in it. Look at module_inst
Interesting that R2 seems to have a sensible value.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Russell,

Cheers for that bit of input will help me find a solution, hopefully. 

So the ADC module init/initialization might be an issue? Lars seems to get this same code working on his SAMD21 module. Very weird that it works for him while it doesn't work on my custom board. This is why I was thinking maybe the fuse settings might have something to do with this issue. 

With regards,

Jenson

Newbie to the world of Atmel SAM D microcontrollers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
R3 is loaded with 0xffffffff That's going to give a hardfault. Adc_module doesn't seem to have the correct address in it. Look at module_inst Interesting that R2 seems to have a sensible value.

Russell,

 

Register R3 gets loaded with 0xffffffff. I am using ASF code, so is it something in my initial parameters that is causing this issue? Or is something related to the clock setting?

 

Regards,

Jenson

Newbie to the world of Atmel SAM D microcontrollers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyone else wants to take a shot at finding the issue. I have gotten tired looking for the issue in the software. Could there be an issue with the hardware setup? I also want to know why the fuses get reprogrammed whenever I flash the ADC module code. 

p.s. New NICs will be interfaced with SAMD20G18s instead of SAMD20G16. So more RAM to play around with. 

 

Regards,

Jenson

Newbie to the world of Atmel SAM D microcontrollers.

Last Edited: Tue. Sep 19, 2017 - 12:54 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Never got to the bottom of this issue, so closing the investigation as an unsolved mystery (Bermuda triangle, anyone). Probably had an issue with the IDE as Mark Roszko of Borked Labs blog said or my old hardware had issues. Lars had no issues with the code I had written when he ran it on his dev board. Also, working fine on my current hardware. 

 

Newbie to the world of Atmel SAM D microcontrollers.

Last Edited: Fri. Feb 2, 2018 - 05:44 AM