Mega4809 Curiosity Nano: "nEDBG disconnected" using 5V extern power supply

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

I'm using Mega4809 Curiosity Nano in circuit with extern power supply. VOFF is grounded.

Kit unchanged out of the box, all recent software updates are installed (AtmelStudio7, nEDBG).

After PowerOn I can program/debug using nEDBG via USB without problems. 

I plug the USB cable out and in a few times and everything works every time - but then suddenly

and permanently I get the message "nEDBG disconnected". Interestingly programming via

drag and drop to curiosity nano storage disk is still possible!

The nEDBG blockage can only be released by switching off/on the external supply voltage.

Tested with two kits.

Last Edited: Mon. Jul 20, 2020 - 04:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Go on.   If you are powered externally there is no USB cable.   There is no debugging.  No Serial.   No voltage control. ...

 

If God gave you an USB cable,   plug it in.   The Curiosity will work 100% e.g. programming, debugging,  Serial, virtual disk, ...

 

David.

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

david.prentice wrote:

If you are powered externally there is ... no debugging.

 

Go on. Sure there is.

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

How can you communicate with nEDBG without a USB connection ?

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

david.prentice wrote:

How can you communicate with nEDBG without a USB connection ?

 

Where I wrote without USB connection ?

By the way, do you know why I wrote "VOFF is grounded" ?

Last Edited: Mon. Jun 1, 2020 - 01:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GermanFranz wrote:

but then suddenly

and permanently I get the message "nEDBG disconnected". Interestingly programming via

drag and drop to curiosity nano storage disk is still possible!

It sounds like Studio is giving up on it somehow.

If you enable "backend logging" in the Studio options, the log might shed some light on why its rejecting the connection.

 

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

mraardvark wrote:

If you enable "backend logging" in the Studio options, the log might shed some light on why its rejecting the connection.

 

Okay thanks for the suggestion, but I don't believe the result makes anyone smart:

 

Preparations:

 

1) Enable Display threshold = INFO in Options/Status Management

2) Enable Diagnostic Logging = TRUE in Options/Tools

 

Looking to Output-Window "Backend Agent",

in case of a successful connection:

 

08 42 48 587: msg send(60):R 50 "gwAAByAgAAGBAAA="
08 42 48 701: msg recv(60):C 51 Tool cmd "AT_6" "gwEKAA=="
08 42 48 701: dap rddi_CMSIS_DAP_Commands nCmds=1 cmdSize0=4 msg=83 01 0A 00 
08 42 48 795: dap DAP_Commands replySize0=64 msg=83 00 00 08 0A ...
08 42 48 795: msg send(60):R 51 "gwAACAoBAQGBAAAB"
08 42 48 797: msg recv(60):C 52 Tool cmd "AT_6" "gwELAA=="
08 42 48 797: dap rddi_CMSIS_DAP_Commands nCmds=1 cmdSize0=4 msg=83 01 0B 00 
08 42 48 799: dap DAP_Commands replySize0=64 msg=83 00 00 08 0B ...
08 42 48 799: msg send(60):R 52 "gwAACAsBAACBAAAB"
08 42 48 810: msg recv(60):C 53 Tool tearDownTool "AT_6"
08 42 48 850: pro Mk3HouseKeepingProtocol::endSession()
08 42 48 850: pro JtagIce3 <<< 11 00 00
08 42 48 850: dap rddi_CMSIS_DAP_Commands nCmds=1 cmdSize0=12 msg=80 11 00 08 0E 00 0A 00 01 11 00 00 
08 42 48 852: dap DAP_Commands replySize0=64 msg=80 01 00 08 0B ...
08 42 48 852: dap rddi_CMSIS_DAP_Commands nCmds=1 cmdSize0=1 msg=81 
08 42 48 854: dap DAP_Commands replySize0=64 msg=81 11 00 06 0E ...
08 42 48 854: pro JtagIce3 >>> 80 00
08 42 48 859: msg send(60):R 53

 

Successful Disconnection:

08 45 15 383: msg send(60):E Tool attachedToolsChanged [{"ToolType":"com.atmel.avrdbg.tool.simulator","ConnectionType":"","ConnectionProperties":{}}]
 

Please don't ask me why they talk from JtagIce3 or Simulator here if connecting/disconnecting a nEDBG device frown

 

In case of unsuccessful connection nothing happens in output window.

Nothing in "Backend Agent", nothing in "General", nothing in "Tool".

 

Only this message comes delayed: 

08 01 17 467: msg recv(70):C 40 Tool pollForTools false
08 01 18 469: msg send(70):R 40
 

Three things stand out:

 

1) If nEDBG one time in locked status this never change (until power cycle).

2) It seems completely indefinite how often you have to connect the cable to get this locked status.

3) The USB connection is never affected as the drag and drop window opens every time the device is connected, even in locked status. Programming remains possible this way!

 

Can someone help further?

Last Edited: Wed. Jun 3, 2020 - 07:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GermanFranz wrote:
don't ask me why they talk from JtagIce3 or Simulator

 

Everything (Atmel) made since JTAGICE3 has the same protocol really.  nEDBG is one of these.  Simulator is merely reported as an "available tool".

 

GermanFranz wrote:
In case of unsuccessful connection nothing happens in output window.

 

I think this indicates that in fact the HID interface is simply unavailable to Studio, which is a clue in itself.  Does the device manager show up anything different in this state?

 

GermanFranz wrote:
Can someone help further?

 

It looks like an interesting observation - will see if I have the same results as a start.

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

mraardvark wrote:

I think this indicates that in fact the HID interface is simply unavailable to Studio, which is a clue in itself.  Does the device manager show up anything different in this state?

 

You're right.

An entry "HID Device defined by the manufacturer" in the Human Interface Devices list is missing.

An entry "USB Input Device" can't be started (Code 10).

 

Drive "MHCP Curiosity Nano USB Device" remains available as does the entry "Curiosity Data Gateway" (Microchip Tools) in any state.

 

mraardvark wrote:

It looks like an interesting observation

 

Oh, unfortunately this is more than an interesting observation for me as the unpleasant power cycle requirement I really don't need in my system frown

I can only hope for a bugfixed nEDBG firmware, correct?

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

There have been threads (one very recently) where it turned out that the user's keyboard was causing the problem; eg,

 

https://www.avrfreaks.net/commen...

 

So what keyboard do you have? and have you tried a different one?

 

EDIT

 

Found the recent one:

 

https://www.avrfreaks.net/commen...

 

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...
Last Edited: Thu. Jun 4, 2020 - 06:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GermanFranz wrote:
I can only hope for a bugfixed nEDBG firmware, correct?

 

Hopefully... 

 

I have tried a good few USB unplug-replug iterations and not able to get the device manager to show any trouble yet :|

 

Questions:

1. since this is/maybe related to external voltage - what voltage level are you providing the target?

2. you upgraded the nedbg in Studio, but Studio no longer ships much new firmware - which version are you running?  Might be worth upgrading from the version located in the latest pack release.  Go to  https://packs.download.microchip.com/  and download the pack for "PKOB Nano" - browse the .atpack with a zip browser and extract the nedbg_fw.zip which contains 1.16 (decimal) release.  You can install it using atfw.exe to save yourself installing MPLABX.

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

awneil wrote:

So what keyboard do you have?

 

For this purpose I use a battery powered Win10 notebook.

This avoids unnecessary electrical interference.

Your question gave me the idea to try another notebook with a different operating system (Win8.1).

Result: The same.

 

By the way, this last Studio-update also shows that there were already problems with the nEDBG connections.

 

Attachment(s): 

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

mraardvark wrote:

I have tried a good few USB unplug-replug iterations and not able to get the device manager to show any trouble yet :|

 

Thanks for your time.

 

mraardvark wrote:

since this is/maybe related to external voltage - what voltage level are you providing the target?

 

5 Volts. The supply is stable.

 

mraardvark wrote:

2. you upgraded the nedbg in Studio, but Studio no longer ships much new firmware - which version are you running? 

 

Version 1.0e

 

mraardvark wrote:

Might be worth upgrading from the version located in the latest pack release.  Go to  https://packs.download.microchip.com/  and download the pack for "PKOB Nano" - browse the .atpack with a zip browser and extract the nedbg_fw.zip which contains 1.16 (decimal) release.  You can install it using atfw.exe to save yourself installing MPLABX.

 

I will try this. Thanks so far.

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

mraardvark wrote:
nedbg_fw.zip which contains 1.16 (decimal) release

 

Ok, no problem, Studio7 now shows version 1.10.

To be brief, no change.

 

Same USB-Driver errors in Device-Manager, Win10 reports nEDBG CMSIS-DAP driver error.

I only needed two plug-in tries... sad

 

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

An interesting question that concerns me where the debugger is powered from when no usb cable is connected.

Because the Debugger Power/Status LED is switched on the first time it is plugged in and does not switch off when the cable is unplugged.

A direct connection to the external power supply cannot be seen, have look to circuit diagram cutout attached.

 

This contradicts the statement in the Curiosity Nano Hardware User guide:

 

"Programming, debugging, and data streaming is still possible while using external power: the debugger
and signal level shifters will be powered from the USB cable. Both regulators, the debugger, and the level
shifters are powered down when the USB cable is removed".

 

I also find the statement strange and incomprehensible

 

"LED is off. The onboard debugger is either in Sleep
mode or powered down. This can occur if the kit is
externally powered"

 

Why can occur?

It practically doesn't happen.

 

 

Attachment(s): 

Last Edited: Fri. Jun 5, 2020 - 02:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, I think you are definitely onto something there.

 

I suspect the debugger is powering itself via the target supply, which should not happen, but apparently does.

 

I also observe the LED stays on _sometimes_...

 

This means that the debugger is not doing a full boot when you plug it back in, which might lead to your USB issues...

 

Out of interest - are you able to reproduce the same symptoms if you power off a 3V external power?

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

mraardvark wrote:
This means that the debugger is not doing a full boot when you plug it back in, which might lead to your USB issues...

 

I can only repeat it:

 

GermanFranz wrote:

1) If nEDBG one time in locked status this never change (until power cycle).

2) It seems completely indefinite how often you have to connect the cable to get this locked status.

3) The USB connection is never affected as the drag and drop window opens every time the device is connected, even in locked status. Programming remains possible this way!

 

mraardvark wrote:
are you able to reproduce the same symptoms if you power off a 3V external power

 

I can't check that unfortunately.
The system is working and built in, there are only 5V.

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

Let's summarize:

Without USB connection debugger should be in power off mode every time - but not is.

With an USB connection, the debugger should provide all features every time - but it doesn't.

One can only assume a connection between the two malfunctions...

Last Edited: Fri. Jun 5, 2020 - 08:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, I experimented a little with a second kit today. Curiosity means to be curious wink

 

First I noticed that the level of the external power supply plays a role.

3V working (Debugger Power LED OFF). 5V not (LED remains ON) + same nEDBG problem.

But 5V I absolutely need.

 

Because no quick firmware help is expected I looked for a workaround. And I found:

There is a big cut-strap J101 (Rev.7 only) which can disconnect the Mega4809 power

supply from the debugger and the VTG pin. Cut it! Make a connection from J101

Mega4809 side to unused "NC" Pin near Debugger-LED.

Connect the 5V target voltage constantly to this pin -> Mega4809. 

Connect the original VTG pin switchably to the 5V target voltage.

 

And lo and behold, VTG OFF will force Debugger (LED) OFF- if needed.

Then of course switch ON again for nEDBG programming/debugging later.

There is no interruption in the program flow.

When connecting the usb cable again, debugger now starts normally and "disconnected" problem is solved yes

 

Update: nEDBG Firmware 1.20: No change.

Last Edited: Tue. Jun 23, 2020 - 09:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GermanFranz wrote:
Update: nEDBG Firmware 1.20: No change.

 

FYI: Pack version 1.5.210 on https://packs.download.microchip... has FW 1.21 - worth seeing if it improves things?