Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

not an issue but a question #3

Open
mcsmark opened this issue May 11, 2022 · 16 comments
Open

not an issue but a question #3

mcsmark opened this issue May 11, 2022 · 16 comments

Comments

@mcsmark
Copy link

mcsmark commented May 11, 2022

i wonder what the best way is to ask a question? I do not have an issue but more some questions about API usage.
i would like to use the debug functions from avr8protocol.
like step,run, etc. but i have no idea how to setup a session so i can use these commands.

@xedbg
Copy link

xedbg commented May 11, 2022

Hi @mcsmark,
An interesting and relevant question! First point is a matter of scope - this library contains a set of protocol definitions, and avr8protocol can be used for a set of AVR device/interfaces - so its a matter of knowing not only what functions to call to setup a session, but also what content must be sent to the debugger to configure a session for a given device. Since this library is the raw set of protocols, you have to start to look one layer up: pymcuprog.

However, pymcuprog is primarily targeted towards AVR UPDI devices, and the other device families are only partially supported for experimental/test purposes - are you planning to use an UPDI device?

If so - you can install the latest beta pymcuprog from the test.pypi.org, and use the newly-added debug functions, for example: (note - this does not program the flash)

from pyedbglib.hidtransport.hidtransportfactory import hid_transport
from pymcuprog.avrdebugger import AvrDebugger
logging.basicConfig(format="%(levelname)s: %(message)s", level=logging.INFO)

transport = hid_transport()
transport.connect()

avr = AvrDebugger(transport)

avr.setup_session("ATmega4808")
avr.start_debugging()
pc = avr.program_counter_read()
avr.step()
pc = avr.program_counter_read()
avr.stop_debugging()

@mcsmark
Copy link
Author

mcsmark commented May 12, 2022

ha, that is great news. first of all, thank you for taking the time to reply. i first wanted to use pymcuprog but i see i need the beta. i do use updi interface and i understand it will only work for that. i just tried with the beta but there seems to be some problem.
first of all i use avr128da28. here is the output from the info log :

INFO: Manufacturer: Microchip Technology Incorporated
INFO: Product: MPLAB Snap ICD CMSIS-DAP
INFO: Serial Number: BUR190972701
INFO: Setting up avr128da28 for debugging
INFO: Looking for device avr128da28
INFO: UPDI baud rate: 900000bps
INFO: Starting debug session
INFO: UPDI-specific initialiser
INFO: SIB: ' AVR P:2D:1-3M2 (A7.KV001.0)

so that works well. but the avr.start_debugging() hangs in this code :
flush_events(self):
the poll_events always returns this : bytearray(b'\x82\x00\x00\x08\x0e\x10\x00\x12\x84\x00\x17\x00\n\x00AVR P:2D:1-3M2 (A7.KV001.0)\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
and thus keeps looping for ever.

@xedbg
Copy link

xedbg commented May 12, 2022

Oh... I can try to replicate a similar session here - which Snap debugger FW version are you using?
(reported easily by "pymcuprog ping")

@mcsmark
Copy link
Author

mcsmark commented May 12, 2022

Connecting to anything possible
Connected to MPLAB Snap ICD CMSIS-DAP from Microchip Technology Incorpora
serial number BUR190972701)
Debugger firmware version 1.9.223
Debugger hardware revision 1
Pinging device...
Ping response: 1E970A

it should be the latest since it was updated with firmware just few days ago using mplax-x

@xedbg
Copy link

xedbg commented May 12, 2022

OK, that should be fine. Two things to try next:

  • update to latest pyedbglib (2.20) from test.pypi: pip install -i https://test.pypi.org/simple/ pyedbglib
  • instantiate the debugger in an alternative polling mode: avr = AvrDebugger(transport, use_events_for_run_stop_state=True)

@mcsmark
Copy link
Author

mcsmark commented May 12, 2022

ok, thanks, i will try that.

@mcsmark
Copy link
Author

mcsmark commented May 12, 2022

ok, that fixed the problem. i see some errors when i use stop_debuggin

INFO: Stop debugging session
Exception ignored in: <function HidTransportBase.del at 0x00000000037F1AF0>
Traceback (most recent call last):
File "pyedbglib\hidtransport\hidtransportbase.py", line 60, in del
File "pyedbglib\hidtransport\hidtransportbase.py", line 161, in disconnect
File "pyedbglib\hidtransport\cyhidapi.py", line 116, in hid_disconnect
File "D:\Python38\lib\logging_init_.py", line 1433, in debug
File "D:\Python38\lib\logging_init_.py", line 1699, in isEnabledFor
TypeError: 'NoneType' object is not callable

dont know if that is normal or not. but it works. i am really happy with this 👍
thanks for your help and support.

@xedbg
Copy link

xedbg commented May 12, 2022

Well, thanks for the feedback - we will take a look to see what might cause this.
We hope to release this package update in the next sprint (2 weeks) - of course this module is 'alpha'.

@mcsmark
Copy link
Author

mcsmark commented May 12, 2022

ok, great. i will test all functions, if i find a problem i share it here.

@mcsmark
Copy link
Author

mcsmark commented Sep 2, 2024

ok so the good news it all works perfect. that is using HID transport. But now there is a new SNAP V2 which does not have a HID driver anymore. A real pity since HID does not need users to install drivers.
I wonder how it will work now? all code examples with hid will not function. V2 uses a bulk transport driver according to microchip. Is the existing code able to deal with that? or are any changes planned?
The SNAP v1 identifies as an atmel device with HID. But the V2 identifies as microchip device with a different VID and PID.
On avrfreaks i noticed users are using atmel studio to put in the old firmware so it works in HID mode again.

@xedbg
Copy link

xedbg commented Sep 2, 2024

The Snap firmware you are referring to is the same Snap firmware that has been used to program PIC devices for many years already - now it also has support for AVR devices, so MPLAB no longer switches to an "AVR mode". To access the HID mode and continue to use pyedbglib, use Studio to switch the tool into that mode.

@mcsmark
Copy link
Author

mcsmark commented Sep 2, 2024

Aha, so there is no mode anymore and an entire new protocol that can do all. So pymcuprog can also not use this new protocol.
It is a pity that one has to download an install AS7 just to put the programmer into the HID mode.
Or is there some other more simpler way? Also when you put the SNAP into V1 mode, how long will that be usable? I mean it makes sense that microchip only supports the new V2 protocol and all bugs and enhancements will be in that firmware. The older firmware will probably not be updated. I realize that i ask the wrong person since this is the section for EDBG.
But you probably have more insights. It is a pity since it worked so well in HID mode. All EDBG using HID worked without changing any code which is a great benefit. Anyway thanks for the info.

@xedbg
Copy link

xedbg commented Sep 2, 2024

The "V2" protocol put device support details on the outside of the firmware (ie: data driven from the host) so its very different and in no useful way compatible with EDBG. This means that the Snap firmware remains unchanged when new devices are released. (FYI avrdude has reverse-engineered this protocol if you are interested in the details.)
nEDBG firmware will continue to be updated with future devices at least for now.

@mcsmark
Copy link
Author

mcsmark commented Sep 2, 2024

thanks for this info. I found some info about switching from PIC to AVR and vice versa. But that works only with V1. When i understand you, the V2 bulk driver is also supported in AVRDUDE and does not need to switch into HID mode. It will switch modes but without going into HID mode.
I will have a new look at that.

@xedbg
Copy link

xedbg commented Sep 2, 2024

Yes, V2 does not have a mode switch (no longer dual-boot) and also has nothing to do with pyedbglib.

@mcsmark
Copy link
Author

mcsmark commented Sep 2, 2024

thanks, it is clear to me now :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants