SAML21 Sleep Mode bricks the chip

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

Hi,

 

I'm currently working on a project with the SAML21E17B and I've found that putting the chip into Standby bricks it.

 

I've used the most simple code:

#include <asf.h>

int main (void)
{
	system_init();

        system_set_sleepmode(SYSTEM_SLEEPMODE_STANDBY);        

	while(1)
	{
		system_sleep();
	}
}

and after loading this on, the chip can no longer be accessed through Atmel Studio using the Atmel ICE:

Severity:		INFO
ComponentId:	20000
StatusCode:	0

No device detected. Error 4109

Unable to enter programming mode. Verify device selection, interface settings, target power, security bit, and connections to the target device.

This is on a custom PCB, however it's a second revision prototype and my first revision worked just fine.

 

Is there anything anyone can think of that would cause this, or had any experience themselves?

 

Cheers.

Last Edited: Mon. Jul 18, 2016 - 10:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Hi,

 

Yes, I've seen other SAM MCUs behave in the same way although I've not used the L21.

The Atmel ICE or the embedded debugger on evaluation boards cannot talk to an MCU that is in sleep mode.

The MCU is not 'bricked', just sleeping.

Even if you reset the MCU with your simple code it goes straight back to sleep.

Try adding a delay before sleeping to give the ICE a chance to get in or provide a means of waking up the MCU maybe by using a button.

 

Hope this helps.

Cheers

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

One thing I *always* do (at least during the initial stages of development) is to have the processor watch for a button press extremely early during the boot/initialization process.  The button press code is of the "while (button_is_pressed()) {}" variety, so that if the button is pressed, all further execution is stopped.

 

The point is that when bad things like this happen, all I do is press and hold the button, and then press 'reset', or start the debugger.  Since the program is hung in the button loop, it can't get to the bad part, the debugger can take over, and I can load new firmware.  If the button is not pressed, the system boots like you would expect.

 

I really can't tell you how many times this has saved my butt.

 

 

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

The same happened to me

Do you have any solution ?

Can I recover my sam L21 ?

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

CaglarG wrote:
Do you have any solution ?

Did you not read #2 & #3, then?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...