[rasyoung]

Thank you, will do.

[rasyoung]

Just confirming, Atmel Studio 4.18 sp3, runs this program perfectly, debugs, and automates like a champ via the serial JTAGICE (mk I). So even from an Oracle Virtual Box VM, this code auto steps perfectly, and the hardware LED blinks precisely as you would expect.

https://www.ebay.com/itm/1PCS-AVR-JTAG-AVR-USB-Emulator-Simulator-Debugger-Programmer-JTAG-ICE-for-Atmel/272191095130?hash=item3f5fda815a:g:LfgAAOSwdqRXiJGT

 

 

Attachments:

You must be logged in to view attached files.

[rasyoung]

OK, was able to affect some change, by deleting the VERIFY step, and setting a breakpoint in the code.

I do get the previous error message about the stackframe, but it will step through the code very slowly.

Take 5 or 6 seconds for each step to execute.

The flash step prior to debug does load the updated firmware to the chip.

 

 

 

 

Attachments:

You must be logged in to view attached files.

[rasyoung]

Hello!,

So back to my original approach I setup as before but skip the verify step.

C:\SysGCC\avr\bin\avarice.exe –file “C:\Codetest\AVR\VsualGDB\Atmega32a\VisualGDB\Debug\Atmega32a” -1 -B 250K –erase –program -j /dev/com11 :2000
AVaRICE version 2.13, Apr  1 2016 17:36:26

JTAG config starting.
Hardware Version: 0xc3
Software Version: 0x80
Reported JTAG device ID: 0x9403
Configured for device ID: 0x9403 atmega16
JTAG config complete.
Erasing program memory.
Erase complete.
Preparing the target device for On Chip Debugging.
Downloading FLASH image to target….

at least I see a change, the connection is no longer refused.

Cannot resolve the address of _estack or __StackLimit. Skipping stack pointer validity check.

 

Please advise. Thanks!!!

Randy

[rasyoung]

Tried quite a number of different options, as the custom gdb was easy to implement after I decided to create a new example, but never got any material change in behavior.

I guess I need to clarify exactly what series of arguments should be give to avarice to get it in the correct state to talk to openocd, in the way that works properly with VisualGDB? Exacting all the possible options, by trial and error, is not very efficient.

Not sure if I know this critical piece of information…

 

 

• This reply was modified 7 years ago by rasyoung.

[rasyoung]

Did my best to evaluate permissions, and potential issues with Windows Defender firewall. Of course Visual Studio 2017 is run as admin.

I ran the avarice from the command line… to insure it was up and waiting and forced VisualDBG to execute… notice the termination at the end of the session.

C:\Codetest\AVR\VsualGDB\Atmega32a\Atmega32a>C:\SysGCC\avr\bin\avarice.exe  -1 -B 250K -j /dev/com11  :2000
AVaRICE version 2.13, Apr  1 2016 17:36:26

JTAG config starting.
Hardware Version: 0xc3
Software Version: 0x80
Reported JTAG device ID: 0x9403
Configured for device ID: 0x9403 atmega16
JTAG config complete.
Preparing the target device for On Chip Debugging.
Waiting for connection on port 2000.
Connection opened by host 127.0.0.1, port 50587.
gdb exited.

[rasyoung]

Finally, this hardware setup work perfectly under Atmel Studio 4, sp2 418.

Thanks in advance for the consideration of your reply.

[rasyoung]

The relevant error message I believe is :

“No connection could be made because the target machine actively refused it”

Attachments:

You must be logged in to view attached files.

[rasyoung]

Here’s the log …

C:\SysGCC\avr\bin\avarice.exe –file “C:\Codetest\AVR\VsualGDB\Atmega32a\VisualGDB\Debug\Atmega32a” -1 -B 125K –erase –program –verify -j /dev/com9 :2000
AVaRICE version 2.13, Apr  1 2016 17:36:26

JTAG config starting.
Hardware Version: 0xc3
Software Version: 0x80
Reported JTAG device ID: 0x9403
Configured for device ID: 0x9403 atmega16
JTAG config complete.
Erasing program memory.
Erase complete.
Preparing the target device for On Chip Debugging.
Downloading FLASH image to target….

Verifying FLASH

[Author]

Posts