pollForTools times out after USB usage between MCU and computer

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

Hi,

 

x256a3buXplained and atmel-ice are connected together and both of them to computer via USB.

using atmel studio 7.0 on windows 10.

As Atmel-ICE is not detected by atmel studio, I use avrdude to program the device.

 

Everything's fine until I flash code which sends data from MCU to computer and I open COM PORT to visualise data coming from MCU (note that this works fine).

 

But the following suggests that I broke something at this point : after this step, I regularly receives this msg from atmel studio :

 

 

I think I identified two cases in which this happens.

First case : as soon as I start to flash code while there is already code using USB on MCU

Second case : no special rule, just pops from time to time

 

Any idea ?

 

Thanks

Yvon

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

Hi -

I understand that this question was posted about a year ago, with no response.

Just recently, while testing one of the LUFA USB stack demo apps, this same issue is occurring on my Win 10 machine. Studio will 'freeze' report this same message.

Does anyone have an answer as to reasons for this issue?

 

Thanks

Jim

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

I get this all the time. No idea what causes it. I just "stop waiting" and carry on.

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

In my case, I discovered that, since the LUFA demos use the Atmel VID #, the backend agent appears to 'hang' as described during its polling operation. The agent must think that the demo is a 'tool' and attempting to communicate with it.  Each time I initiate Studio(and every few minutes or so afterward), the software hangs as described.  Should I click 'Wait another minute', the polling will succeed.  So, I've been building the LUFA app with a dummy VID to prevent this from happening. I tried changing the timeout value from the default 20 sec to 32 sec (MAX) and had no success.

 

...just another puzzle to be solved that likely never will be.

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

Any VID that is on the Atmel VID (03EB) will cause a USB enumeration to trigger. This involves reading the serial number, and if it is a HID device, the iProduct string. If the firmware you have does not respond to these, Studio might hang.

 

2 ways to avoid this, either use another VID, or there is an internal hidden switch to turn off USB enumeration that I can dig up if you want. This means that Studio will enumerate USB devices once, on startup, but not listen to any device change notifications from Windows.

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

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

I got the same problem.

if run studio as admin, it is gone, but it is there if run normally.

 

is there any solution? meolsen's picture

 

thanks

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

tom62 wrote:
if run studio as admin, it is gone, but it is there if run normally.
Local admin it is.

Installation | Microchip Studio

[bottom]

  • If you choose to open, note that Microchip Studio will launch with administrative privileges since the installer was either launched as an administrator or with elevated privileges.

 

"Dare to be naïve." - Buckminster Fuller