SAMD10 - I broke the clock?!

Log in or register to post comments
Go To Last Post
5 posts / 0 new
Author
Message
MalphasWats
MalphasWats's picture
Level: Hangaround
Joined: Mon. Apr 30, 2018
Posts: 117 View posts
#1
Posted by MalphasWats: Fri. Oct 25, 2019 - 07:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

  I have a little SAMD10 board that I made to learn how to do ARM stuff with. I had it working fine but was struggling with getting SPI fast enough. As I was tinkering with some of the code for the internal clock, I made a mistake and it seems the clock is now in an invalid state and I can't seem to connect to it with my programmer. I'm using an ST-Link V2 clone programmer with OpenOCD and everything was working fine until I made a change to the GENDIV register:

 

GCLK->GENDIV.reg =
        GCLK_GENDIV_ID(3) | // Select generator 3
        GCLK_GENDIV_DIV(64);

I changed the 64 to 1 and it stopped working, so I set it back to 64 in the code but now I can't upload any more code to it. I get:

 

Error: init mode failed (unable to connect to the target)

from OpenOCD now :(

Is there a way I can recover the microcontroller?

 

Thanks

-Mike

Tags:

Atmel SMART ARM-based MCUs and MPUs, Atmel Cortex-M MCUs
Top
Kartman
Kartman's picture
Level: 10k+ Postman
Joined: Thu. Dec 30, 2004
Posts: 22639 View posts
Location: Melbourne,Australia
Posted by Kartman: Fri. Oct 25, 2019 - 09:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had no direct experience with the samd10, but with most other Cortex based chips they power up using the internal clock. Then when they execute your code, the clocks get initialised. So the trick is to get the debugger to take control right after reset before your code upsets the clocks. This can be easier said than done.

Top
MalphasWats
MalphasWats's picture
Level: Hangaround
Joined: Mon. Apr 30, 2018
Posts: 117 View posts
Posted by MalphasWats: Fri. Oct 25, 2019 - 09:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
I had no direct experience with the samd10, but with most other Cortex based chips they power up using the internal clock. Then when they execute your code, the clocks get initialised. So the trick is to get the debugger to take control right after reset before your code upsets the clocks. This can be easier said than done.

That's how I understood it to work. I'm not sure why my debugger isn't resetting it and catching it right away 🙄

Thanks Kartman

Top
frobozz
frobozz's picture
Level: New Member
Joined: Thu. Sep 26, 2019
Posts: 12 View posts
Posted by frobozz: Fri. Nov 1, 2019 - 12:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I got in a state where my errant watchdog code was resetting the processor quickly, before the download could start, I went into the tools->device programming->memories and did an "erase now" on the chip.  Poof!  Now it's no executing any code when it powers up and the Ice will connect right up. 

 

Duncan

Top
MalphasWats
MalphasWats's picture
Level: Hangaround
Joined: Mon. Apr 30, 2018
Posts: 117 View posts
Posted by MalphasWats: Fri. Nov 1, 2019 - 08:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

frobozz wrote:

When I got in a state where my errant watchdog code was resetting the processor quickly, before the download could start, I went into the tools->device programming->memories and did an "erase now" on the chip.  Poof!  Now it's no executing any code when it powers up and the Ice will connect right up. 

 

Duncan

Yeah, I'm sure it's recoverable, but I don't use either AS7 or an ICE. I desoldered it and put a fresh one on 🙄

Top