Before logging an issue, please update to the latest release of Visual Micro from the Downloads Page.

When Logging a Support Issue in the Forum, please ensure you have also:-

  • Enabled vMicro > Compiler > Show Build Properties
  • Re-Compile your program with these settings enabled
 
Save the new Output to a Text File and....
  • Click the Reply button and attach as .txt file OR
  • Click here to Email us with the file attached, and a link to your post
Support requests without the output above may be impossible to answer, so please help us to help you
 
Page Index Toggle Pages: 1 Send TopicPrint
Normal Topic relaunch debugWire debugging sessions without power cycling target in Microchip Studio (Read 2222 times)
Tammybai
Ex Member


relaunch debugWire debugging sessions without power cycling target in Microchip Studio
Jul 14th, 2023 at 3:31pm
Print Post  
I have also posted about this here: https://www.avrfreaks.net/s/topic/a5C3l000000BpxfEAC/t391305

Equipment/Toolchain:

IDE: Microchip Studio 7.0.2594

Extensions: Visual Micro 2023.0507.1

Target Chip: ATmega328PB

Debugger: Atmel-ICE debugger using 6-pin ISP/debugWire header

Background:

I can successfully start a hardware debugging session, where Microchip studio informs me that it needs to program the DWEN fuse using SPI, and then it prompts me to power cycle the board and click OK.

I notice that after power-cycling the board, Microchip studio then uploads the new firmware to the ATmega.

So, presumably, the upload is happening using debugWire interface, right?

Once the debug session is initialized, things work as expected (step debugging, run to cursor, watch window etc etc).

If I end the debug session using the stop button (instead of using the "Disable debugWire and Close" option, then susequent attempt to launch debug session results in uploader fail because the uploader is trying to do an SPI upload (instead of debugWire)

I do notice however, that after the power cycle (when the debugWire interface has been activated), there appears to be a secondary upload happening via the debugWire interface.

So it seems that you can upload a new firmware image using only debugWire interface without needing to drop back to SPI first.

Here is a video that demonstrates as much:

https://youtu.be/roRYEvCutBo

Now then:

The Question:

While I am stopped on a breakpoint in the middle of a debugWire debug session, how can I make a change, and recompile/relaunch the debug session without disabling the debugWire interface?

It seems that there is a project called Bloom which has features like this. I'm not sure how I can mangle Bloom into the current setup I have though.

See the following quote from the Bloom Debugging AVR microcontrollers via debugWire page

Edited:
Bloom can program debugWire targets via the debugWire interface. This removes the need to switch to the ISP interface when uploading any code changes.

Users are advised to use GDB's load command to update the target's program memory with the latest binary. See Programming the AVR target for more.


Does anyone know if Mircochip Studio or Visual Micro have this ability?
« Last Edit: Jul 14th, 2023 at 3:34pm by »  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12191
Location: United Kingdom
Joined: Apr 10th, 2010
Re: relaunch debugWire debugging sessions without power cycling target in Microchip Studio
Reply #1 - Jul 15th, 2023 at 6:09pm
Print Post  
Thanks for the info. When you have the vMicro>Debugger set to hardware we entirely handover to native Microchip Studio and play no part in the debug session or how it starts.

One item of note that might or might not help. If you set the vMicro>Uploader to Atmel Studio Device Programming then we also pass the upload control entirely to native Microchip Studio Device Programming. You video appears to show using a standard vMicro/Arduino uploader as opposed to Microchip Studio.

Does this make sense?
  
Back to top
IP Logged
 
Tammybai
Ex Member


Re: relaunch debugWire debugging sessions without power cycling target in Microchip Studio
Reply #2 - Jul 18th, 2023 at 6:50pm
Print Post  
I think this person has the correct answer over on the avr freaks forum:

https://www.avrfreaks.net/s/topic/a5C3l000000BpxfEAC/t391305?comment=P-2923092



Basically, Microchip studio automatically does the upload using debugWire when the debug session gets launched.

The problem is that the visual micro extension is attempting to do the upload first using ISP, instead of just launch the debug session.

So I need to figure out how to get visual micro to "skip" the upload phase when I click "start debugging and break".

I tried to take a look through the both the "visual micro project properties" and the "JP2App.cppproj" project properties but I couldn't see anywhere to specify/modify the behavior of the upload process.

I'm guessing the upload step is being invoked from the makefile?  Am I way off?

If so, where is the makefile located?

  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12191
Location: United Kingdom
Joined: Apr 10th, 2010
Re: relaunch debugWire debugging sessions without power cycling target in Microchip Studio
Reply #3 - Jul 18th, 2023 at 7:57pm
Print Post  
Thanks for the info. If you don't need to compile and upload then you should simply be able to click "Debug>Attach to Process"
  
Back to top
IP Logged
 
Tammybai
Ex Member


Re: relaunch debugWire debugging sessions without power cycling target in Microchip Studio
Reply #4 - Jul 18th, 2023 at 8:41pm
Print Post  
When I click "Debug-Attach to Target" ( after having previously enabled debugWire via power cycle), Microchip studio simply initiates a debug session assuming that the modified source code has already been uploaded to the target (it does not initiate the debugWire programming of the target).



Another thing I tried was changing the debugger chosen in the dropdown from "Atmel Studio Atmel-ICE(ISP)" to "Atmel-ICE(ISP)".

When I did this, the avrdude process that go kicked off for the upload didn't simply fail like the other one when debugWire was active, instead it appears to have used a debugWire command to get the chip to drop back out of debugWire mode first, and then program it using ISP.

After that, I get prompted to power cycle the chip again by Microchip studio and see the mysterious "Uploading.." message in the status bar after I click "OK" following the power cycle.


What I would like to know is:

Is there is any way to get visual micro to skip the upload phase of its magic and simply invoke whatever command it is using to hand over the debug session to Microchip Studio?





  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12191
Location: United Kingdom
Joined: Apr 10th, 2010
Re: relaunch debugWire debugging sessions without power cycling target in Microchip Studio
Reply #5 - Jul 18th, 2023 at 8:45pm
Print Post  
I previously mentioned setting the visual micro programmer to "Atmel Studio Device Programming". Did you read that? and do you understand what it does?
« Last Edit: Jul 18th, 2023 at 8:46pm by Tim@Visual Micro »  
Back to top
IP Logged
 
Tammybai
Ex Member


Re: relaunch debugWire debugging sessions without power cycling target in Microchip Studio
Reply #6 - Jul 19th, 2023 at 12:00pm
Print Post  
Quote:
I previously mentioned setting the visual micro programmer to "Atmel Studio Device Programming". Did you read that? and do you understand what it does?


Cheesy  !  That did the trick!   

I previously tried this and observed that after I clicked the "close" button in the device programming window, that the debugWire session simply "attached to target" because I didn't notice any "Uploading" message in the status bar while the debugWire session was launching.

But I re-tried it today and sure enough there is a little "Uploading" message in the status bar when the debugWire session auto-launches after closing the Device Programming window.

Here is a video that shows this in action:  https://www.youtube.com/watch?v=Al4Oote4TS0

Thanks for the help!



  
Back to top
 
IP Logged
 
Page Index Toggle Pages: 1
Send TopicPrint