D21 stuck in clock init after reboot. Occurs exactly 50% of the time - caused from USB

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

Hi team!

I am currently working with the ATSAMD21J18 operating as a usb host for a usb memory stick using the asf FatFS service. Everything seems to be running with my general configuration working etc. My only issue if I was to use my USB, wait a few seconds after a few transactions, everything finishes up and then I pull out the USB. Reboot my unit and it gets stuck in the following line:

 

​(new post coding tags appear to be broken...I hope this works...)

</p>
<p>void system_gclk_init(void)</p>
<p>{</p>
<p>/* Turn on the digital interface clock */</p>
<p>system_apb_clock_set_mask(SYSTEM_CLOCK_APB_APBA, PM_APBAMASK_GCLK);</p>
<p> </p>
<p>/* Software reset the module to ensure it is re-initialized correctly */</p>
<p>GCLK->CTRL.reg = GCLK_CTRL_SWRST;</p>
<p>while (GCLK->CTRL.reg & GCLK_CTRL_SWRST) {</p>
<p>/* Wait for reset to complete */</p>
<p>}</p>
<p>}

From the FatFS example app I copied their code and everything works generally speaking... Though the error as I describe seems to be associated with "f_open" somehow. Such that if I was to comment it out I don't get the issue on reboot.

My app gets stuck on the while statement waiting for the clock to reset (I am assuming).Though never does. If I do a software reset at this point, the app begins to work once more. The error only occurs after rebooting, power cycling works fine.

It also only happens if a usb was plugged in at any point in time, even if it was removed before the reboot...safely. If the usb was never inserted, the app can reboot with no issues what so ever.

Looking at the errata of my device, assuming Die Variant A - rev D, I can see that it has had issues with the XOSC32K, that if an error was to occur, a power cycle is require to fix it, though mine is fixed with a reboot. Since this is the crystal I am using for my operation, its entirely possible that this could be happening. The datasheet also lists one other issue:

– If APB clock is stopped and GCLK clock is running, APB read
access to read-synchronized registers will freeze the system. The CPU
and the DAP AHB-AP are stalled, as a consequence debug operation is
impossible.

 

Though it doesn't quite match what I am seeing, I am not 100% what other symptoms I have...

Looking forward to some help!
​Ryan.

This topic has a solution.
Last Edited: Fri. Oct 27, 2017 - 06:16 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Turns out my USB was sharing the same clk generator as the RTC and the source was defined as the 48MHz DFLL. The RTC didn;t like this...