Error reading signature data for part "ATtiny1616" #1090
Comments
|
@cuiqingwei You may want to use |
|
I use the bootloader generated by the ATMEL（https://start.atmel.com/） wizard。
|
|
@cuiqingwei Or you can try the bootloader here. |
|
Close this for now. Please reopen if you have found potential issues with avrdude. |
|
Reference here: apparently the STK500 bootloader middleware is badly written and it is not a good example to follow. |
|
I have fixed the problem of stk500 bootloader middleware.
the phenomenon is as follows: |
|
I have re-opened the issue. I am not so sure why adding the |
modify void *BlockLoad(uint8_t buffer[], uint8_t mem, uint16_t size, native_pointer_t address) in bootloader.c After this modification, add a signature to modify avrdude.conf. After this operation, the application firmware downloaded to the target board can operate normally. |
|
My main problem is how to make avrdude not to verify the signature of ATtiny1616？ |
Which is done by But you have to fix your bootloader in the end. That is the right solution. You need to implement the bootloader function to be able to read the device signature. Your bootloader is broken without that function. You can refer to the following codes. |
|
I have captured the data of the whole communication process. What step is the signature reading performed? The whole process was not sent Cmnd_STK_READ_SIGN 0x75 command ~ |
Sorry I am not familiar with the inner working of avrdude to answer your question. Hopefully the others can answer your question. That being said, I am pretty sure your proposed fix to avrdude.conf is totally wrong. |
|
Maybe @dl8dtl or @stefanrueger can help answer your question about |
|
Thank you. I hope you can help me find the real cause of the problem as soon as possible. |
In the mean time, why not give the other bootloader a try. I am pretty sure your bootloader is broken. To me that is the root cause of the issue. |
|
With the code you provided, the same phenomenon occurs.
|
|
@cuiqingwei Can you try the avrdude version inside Arduino megaTinyCore (https://github.com/SpenceKonde/megaTinyCore)? Thanks. You may want to use his hex file. Please read the note carefully if you want to build the hex file by yourself. |
|
megaTinyCore Not provided avrdude.exe. |
|
In order to support ATtiny1616, I made two modifications, passed the compilation, and verified that the serial communication works normally. |
|
Sorry I am not able to help you much further as I do not have the necessary HW to carry out the test. And I am not familiar with the bootloader either. When I say avrdude version which comes with the megaTinyCore, basically that means the avrdude version which comes with Arduino (megaTinyCore is installed on top of Arduino). It is supposed to work together with the bootloader. If that does not wotk either, you can always create an issue for the megaTinyCore project if you think your bootloader build is good yet it does not work with avrdude (either official version or the Arduino version). |
|
Is it normal for ATtiny817 xplaned Mini evaluation board to use avrdude? |
The whole process was not sent Cmnd_STK_READ_SIGN 0x75 command，So this should be the problem of avrdude.exe itself with ATtiny1616. |
|
What platform is it verified on? |
|
I guess it's avrdude.exe there is a problem with the inherited configuration file. Otherwise, how can I explain that I manually modified the configuration file earlier? |
|
@mcuee Can anyone answer the above question? |
Sorry I am not able to help here. Hopefully someone else can help you. |
|
@mcuee Thank you for your reply. So, do you agree that this is a bug ？ |
No I do not agree. To me the bootloader is not working properly. But unfortunately I can not help to figure out where is the problem of the bootloader. That is why I suggested you getting help from megaTinyCore project.
|
Yes it is normal. But I do not use the bootloader. |
|
@MCUdude and @SpenceKonde Just wondering if you have ever tested the optiboot_x with ATtiny1616 (or other megaTinyCore supported ATtiny chips) using avrdude (either official version or Arduino version). Thanks. It seems to be a bit tricky to set up. |
|
@mcuee I don't think I have any ATtinyxx16 hardware, so I'm not able to test Optiboot on these devices. However, I highly doubt there is an Avrdude-related issue since @SpenceKonde would have caught this a long time ago.
If you compare the ATtiny1616 section in the"official" avrdude.conf file with the one shipped with megaTinyCore, you can see that they are practically identical except for some formatting. Try a different bootloader or use a dedicated UPDI programmer such as SerialUPDI or similar. |
If you can test the megaTinyCore optiboot_x bootloader using ATtiny817, that will be good. In that case, we are sure that avrdude is not the issue and the optiboot_x bootloader itself is also not the issue. Then I can close this issue. |
@MCUdude @cuiqingwei I will close the issue now and I will reopen if the issue is confirmed to be on avrdude side later. |
|
Optiboot works beautifully with avrdude 6.3, which is what should be getting used if you do a board manager install. Do not use 7.0 until it has been tested and qualified with megaTinyCore which will happen after we have a stable 2.6.x mTC and 1.5.x DxCore. As right now we have neither, so a high risk upgrade of a core tool which I cannot bypass the development team just isn't in the cards. The only people who should be running into this is perople who "updated" avrdude to an unsupported version of the tool that is apparently not backwards compatible. What did you expect to happen?
|
|
It turned out that the hardware I used when working on the JTAG3 HVUPDI implementation was using an ATtiny1616. I can confirm that there's an issue with the Attiny1616 bootloader (bundled with megaTinyCore), and the upstream Avrdude version. It works great with Avrdude 6.3 and 7.0 (tested with Arduino's fork), but not the upstream version: Arduino 6.3: Avrdude 7.0: Upstream version: |
|
@cuiqingwei And avrdude 7.0 should work as well, just git main does not work as of now. |
|
Fair enough for you to keep using the avrdude 6.3 version in current megaTinyCore as avrdude 7.0 is not ready and it apparently has issues with optiboot_x based on the testing results from @MCUdude. |
7.0 works just fine. It's the upstream version that's the problem. |
My bad, 7.0 works fine. git main does not work as of now. |
|
Not surprised this broke my forks of Optiboot when someone fiddled with it (was that change made to address a complaint?). Arguably the hardest part of porting optiboot to Dx-series parts was figuring out to get AVRdude to use the correct addressing modes. Everything else was relatively straightforward. But DA and DB can have 128k parts. AVRdude uses byte addresses talking to optiboot_x for the tinyAVR parts, while I used a weird trick to fool it into using word addressing for the AVR128Dx parts (see my avrdude.conf from DxCore). If there's a better way that will work with both 6.3 and future 7.x versions please let me know (based on experience, it must be backwards compatible - I can change what's in the avrdude.conf to make it work with whatever new version - or ideally both versions, but I can't say "Yeah from here on out you need a new bootloader binary", people make an unholy stink*) but shrug that was the trick I found to make it work on 6.3 (haven't tested 7.0 - I'm not allowed to look at that until both megaTinyCore and DxCore have stable releases)
|
Indeed that change 3d06457 is because of a long standing bug that typical optiboot implemnetation does not follow the stk500v1 exactly. There were three options to go as per @stefanrueger and in the end the team aligned and went with Option 1 as the Real STK500v1 is dead. Unfortunately your optiboot_x got affected because of the change.
|
|
@SpenceKonde we'll figure something out. I'm posting your answer in #1120, where we can continue the discussion. OP used a different stk500v1 bootloader implementation, so what we're discussing now is a separate issue.
I don't get why you hate Avrdude so much. Remember, Avrdude is one of the backbones of open-source AVR development and is a very important piece of software. Yes, the code base is quite old, and some of the code isn't "that good" either. But ever since Avrdude was moved over to Github, there have been TONS of improvements. Not only new features and bug fixes but also code style and formatting improvements. Avrdude is getting better every day, and we should all be happy about that. I find the Avrdude source code quite straightforward. It's easy to hop on the train and contribute by either helping out with testing, tracking down and fixing bugs, or by coming up with new features. |
xxx\avrdude-v7.0-windows-x64>avrdude.exe -cstk500v1 -PCOM3 -b9600 -pATtiny1616 -e -v
avrdude.exe: Version 7.0
Copyright (c) Brian Dean, http://www.bdmicro.com/
Copyright (c) Joerg Wunsch
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | | 0% 0.00savr_read(): error reading address 0x0000
read operation not supported for memory "signature"
avrdude.exe: error reading signature data for part "ATtiny1616", rc=-2
avrdude.exe: error reading signature data, rc=-2
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe done. Thank you.
The text was updated successfully, but these errors were encountered: