Comments (11)
Thanks for the input - logged as DSG-4313
We will have to take a closer look at this suggestion. Many users feel its most valuable to receive early feedback when the device is not what is expected, so the default behaviour should remain as-is.
The option of a "auto" device could be explored - usually the challenges in such tricks revolve around the order in which the stack is built, since an auto-detect either involves starting an session prematurely (not fully configured) or a re-configuring and re-starting a session if a default/guess is wrong.
from pymcuprog.
This is the way Atmel did the things since the first AVR, although there always have been the signature bytes ready to be used. You must say what chip do you want, then the tool reads the signature and tells you: OK, or, Wrong. It's just a way to do the things. The other way is not to ask the user about the chip, the chip is what it is, discovered from the real world. There are other important things to ask the user, like the file name, memory type, offsets, etc.
But we are not doing politics here. What I'm trying to show is a real usage of the new family of chips, the UPDI one, in real life. Having the same board stuffed with different chips (like 1609 and 3209) can be a real nightmare for a field technician.
Until now, you could say: don't do that, just use only one type (1609 for example) but we live in a different world now.
from pymcuprog.
Indeed - you are right about the history, but its not political.
It's just not a simple thing to change in the stack the way its constructed
(its also the kind of thing I would look closer at around cake-time on fridays...)
from pymcuprog.
I have a similar issuer - I am using pymcuprog API to write simple tool to check serial number, read fuses, etc... And the first step should be to check the DeviceID and branch accordingly. But I need to specify the device type beforehand.
Would it be possible to at least read the DeviceID without the knowledge of the actual device?
from pymcuprog.
Hi @Kedarius
I did have a look into this once on a fun-friday and found that it was quite a can-of-worms. pymcuprog started its life (and still is) a CICD test system for the curiosity nano debugger - and we always know up front what we are testing. More relevant here is that the debugger needs a comprehensive "device context" to be sent to it before it will allow a session to start (see the edbg debugger protocol). So the only way to do this (for the debugger protocol) is to select some device, try 'ping' it, examine the output, adjust accordingly and retry.
For serialupdi this is hardly relevant since the debugger is not of concern... but the same mechanism could be used.
from pymcuprog.
Hi @xedbg , thanks for prompt answer.
Thanks for the insight. I would not mind to set some sort of device, ping and reconfigure. The only issue I have is that the code:
backend.start_session(sessionconfig)
throws an exception and therefore I can not get the actual deviceID - apart from parsing the exception string. And that is a thing I really would like to avoid. Is there any other way to get the deviceID or am I doomed to parse the exception string?
from pymcuprog.
Indeed - i see your problem...
A fairly "cheap" solution might be to sub-class that exception and add a new member which contains the ID which is detected. It would still mean catching and retrying, but no parsing.
in a quick test with avriot connected and tiny1607 specified
from pymcuprog.pymcuprog_errors import PymcuprogSessionError
logging.basicConfig(format="%(levelname)s: %(message)s", level=logging.WARNING)
from pymcuprog.backend import SessionConfig
sessionconfig = SessionConfig("attiny1607")
from pymcuprog.toolconnection import ToolUsbHidConnection
transport = ToolUsbHidConnection()
from pymcuprog.backend import Backend
backend = Backend()
backend.connect_to_tool(transport)
try:
backend.start_session(sessionconfig)
# Read the target device_id
device_id = backend.read_device_id()
print ("Device ID is {0:06X}".format(int.from_bytes(device_id, byteorder="little")))
except PymcuprogSessionError as e:
print("It looks like you have a device with ID: {0:06X}".format(e.id))
>>> It looks like you have a device with ID: 1E9650
However - there is another caveat in that the Dx/Ex families have an additional configuration requirement, so they will fail in a different way... so perhaps its not that foolproof...
(?) are you using serialUPDI or an actual hardware debugger?
from pymcuprog.
I am using a serialUPDI as it seems to be the simplest way for now. I also have a Curiosity Nano and I am thinking about "converting it to a generic programmer" but that is for another time.
For now I am working on a simple tool to see some basic info about the device and to parse the fuses, so the output would be something like this:
# ./get_info.py
Device ID is 1E970E
Signature Row is 1E970EFFA3036C0DFFFFFFFFFFFFFFFF42128189900065130133015700000000
Device ID is 1E970E
Device Serial is 42128189900065130133015700000000
Fuses are FFFFC0080000
Lockbits are 5CC5C55C
WDTCFG: 00000000
WINDOW 0000 Watchdog Window Time-out Period
PERIOD 0000 Watchdog Time-out Period
BODCFG: 00000000
LVL 000 BODLEVEL0 (1.9V)
SAMPFREQ 0 128HZ
ACTIVE 00 DISABLE (BOD disabled)
SLEEP 00 DISABLE (BOD disabled)
OSCCFG: 00000000
CLKSEL 0000 OSCHF
SYSCFG0: 11000000
CRCSRC 11 NOCRC
CRCSEL 0 CRC16
RSTPINCFG 00 Input
EESAVE 0 EEPROM erased during Chip Erase
SYSCFG1: 00000000
MVSYSCFG 01 DUAL
SUT 000 0 ms
CODESIZE: 00000000
CODESIZE 00000000 entire Flash is the Boot Code section
BOOTSIZE: 00000000
BOOTSIZE 00000000 entire Flash as Boot Code section
Done
The goal is to practice python and create tool to see the status of the chip and possibly change single fuse field. And I plan to publish it here on github once it is at least a little presentable :-)
I am focusing on DA/DB family only - at least for now
from pymcuprog.
OK, got it.
Since your goal is also to practise Python, it might be worth looking at importing parts of pymcuprog that you can use rather than the entire backend. At least it should be possible to make a "probe" function which can read the device SIB or ID - for example:
from pymcuprog.serialupdi.application import UpdiApplication
and build your own stack.
Also: pymcuprog includes only basic device info - if you want to start decoding fuses, for example, I hope you make it data-driven using the data in the .ATDF files in the DFPs!
(I think the correct mechanism would be to read the family ID from the SIB first (tiny, mega or AVR), then the device ID)
I was looking at making a quick patch release before vacation here (just to fix a dependency issue), but I won't be able to include any new development work anyway. (Not many developers around to review pull-requests at the moment anyway ;)
from pymcuprog.
Thanks for the response. I will look more into backend internals :-)
For now I've created simple JSON file with fuses description. Parsing .ATDF files seems like a bit overkill but I may look into it.
from pymcuprog.
Correction: When I dug a little bit deeper into my code, I noticed that the exception is being thrown by backend.read_device_id() not the backend.start_session(). So I can start the session with wrong device and then execute the code found in the read_device_id() minus the deviceId check:
detection_updi=detection_backend.programmer.get_device_model()
signatures_base = detection_updi.dut.sigrow_address
# Read 3 bytes
detected_deviceId = detection_updi.avr.read_data(signatures_base, 3)
from pymcuprog.
Related Issues (20)
- MCP2221 HOT 1
- Where is the source code? HOT 3
- pymcuprog cannot write to attiny414 HOT 2
- NO CMIS-DAP devices found HOT 3
- Add support for attiny841 HOT 2
- pymcuprog reports upload success but is not uploading code HOT 10
- Feature request: ability to set serial timeout when using serial UPDI HOT 3
- Return value 0 on error HOT 2
- No connection to ATmega4809 HOT 3
- Read, Verify broken for ATtiny402 HOT 8
- Program write not working for AVR128DA MCU HOT 3
- Linux UART left in unknown state after first use flashing UPDI HOT 8
- Commandline option to explicitly set the DTR-line HOT 6
- Feature request: make info logging more concise HOT 2
- Feature request: PIC18 HOT 1
- Error return code when --verify fails HOT 2
- Error using chip erase HOT 1
- No communication on linux UPDI with attiny 1616
- nEDBG custom PIC18LF27K40 invalid device ID HOT 2
- Prevent MCU from booting between pymcuprog commands? HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pymcuprog.