RSP_NO_TARGET_POWER after burning bootloader

[mayurharge]

Hello, I am using latest core release and these are the settings I am using while burning the bootloader, I am using burn bootloader option to do it. Core version 2.4.2

After succesfully burning the bootloader and trying to upload the sketch again I get this error (I am able to successfully run my sketch before so no issue from HW design )

avrdude: jtagmkII_initialize(): Cannot locate "flash" and "boot" memories in description avrdude: jtagmkII_program_enable(): bad response to enter progmode command: RSP_NO_TARGET_POWER avrdude: jtagmkII_program_enable(): bad response to enter progmode command: RSP_NO_TARGET_POWER avrdude: jtagmkII_read_byte(): bad response to read memory command: RSP_NO_TARGET_POWER avr_read(): error reading address 0x0000 read operation not supported for memory "signature" avrdude: error reading signature data for part "ATtiny827", rc=-2 avrdude: error reading signature data, rc=-2 avrdude: error reading signature data for part "ATtiny827", rc=-2

My main goal is to enable external reset using UPDI or PB4 option. Please help me to enable external reset by any means.

[SpenceKonde]

Bad connections, bad cable, bad part, bad soldering or a bad version of the jtag2updi firmware. It's a very non-sepecific error, like most programming failures. That's the error we I made it send when it knew it had been waiting so long it was never going to get a response. But in practice the error means "something went wrong" (I had to pick from ones defined by the jtagice protocol, , which was made for a different situation and different parts(

There were some broken versions of the code that were up on the repo for months that had a bug that had a dependance on floating pins and would output that error when it shouldn't havel , so make sure you're using latest version. I merged in a change without understandign it (I hate reading that codebase, I cannot follow anything)

jtag2updi was a nonstop disaster, it is a supported programmer , but it is not our recommended programmer - it is slow and depends on unmaintained (and unmaintainable) mess of codeset, the producrt of a kiitchensinkist design mentality in the extreme. There is essentially no part of that system that is sound. Not the flaky code onthe '328p, not the protocol that it borrowed from a different device meant for programming very diferent devicesm it puts out spuruious warnings, it can't do full page reads because of a harcoded cap.

SerialUPDI is more reliable and the upload speed is 1.5-3x what jtag2updi could do. I do not provide further support for jtag2updi - My solution is that I put my jtagu2pdi boards in the junk box and modified a bunch of serial adapters. I am STILL not happy with the reliability, but now it's 100% purely hardware - the dupont connectors degrade. IOF dupont line i made in a "factory" with a dierrt floor and no furituer orehrthan cable crimping machines, where they crimp the lowest quality connectors made oonto "30 AWG" ribbon cable made 2with 22--34 AWG wire, and they don't even crimp it as tight as they should, probably because the manufacturer wants to limit wear to his crimp machine. And that was a problem with jtag2updi too, I had to repin the wires coming out of mine several times.

And of course, as it almost always is, you get that same error.

[SpenceKonde]

No response after nearly a week to what amounts to a tech support inquiry for a programmer we do not provide technical support for. We do not provide technical support for it because we don't know what causes it to work or not work either, sometimes it behaves oddly. We know at one point there was a busted version in my github for months because I didn't understand what I'd merged in, but that was fixed. It'sthat or a wiring problem. No UPDI perogramming will work with anything connected between the programming data line and the target's UPDI pin except a small value resistor (470 is our recommendation), and it can't have anything like an autoreset circuit connected, and the pin must not have been set to act as a reset or I/O pin,

[mayurharge]

First of all extremly sorry for no reply, After using serial to updi for burning bootloder my controller is getting locked.

[arihantdaga]

@SpenceKonde thank you for this project. I am facing a similar problem and trying to find a solution. I used serialUPDI programmer as you described. Made connections like this.

following your repository https://github.com/SpenceKonde/AVR-Guidance/blob/master/UPDI/jtag2updi.md

I kept resistor on updi to 470 Ohm also.

But you mentioned this

and the pin must not have been set to act as a reset or I/O pin,

My use case is that i want to upload the bootloader and set this as reset pin, so in case of unresponsiveness, attiny reset could be triggered by a separate MCU.

Do you mean that if i set the pin to reset pin, i cannot upload the code again ?

Right now, with the serial updi i made, i am able to upload program to the device, but not able to burn bootloader.

Would be very thankful for your help.

[arihantdaga]

Also, are the fuses value set by the script is right ? Could they be problem ? This comes when i try to upload bootloader. Set fuses: ['0:0x00', '1:0x00', '2:0x02', '4:0x00', '5:0b11001101', '6:0x04', '7:0x00', '8:0x00']. I am wondering if fuse 4 and 5 are right ? I did fuse_print and the fuse values on the existing chip(Which i have uploaded my sketch into) is 0x001284: FF, 0x001285: F6

1. According to the docs, fuse 3 and 4 are reserved, why we are setting fuse 4 here then.
2. Previous fuse value is F6 - i.e - 11110110 and now we are setting 11001101 the 4th bit is for NVM lock enable/disable, could that be a reason why the mcu would lock and appear to not respond to anything once we try to upload bootloader.

[SpenceKonde]

If the pin is set to act as reset, then it is not acting as UPDI. You cannot program the part through the reset pin, you need the updi pin. An HV UPDI programmer must be used to enable the HV override and turn that pin back into a UPDI pin. Such programmers are exotic; I have never used one - I just have a slowly growing pile of bricked boards in by dogpile that I may some day attempt to revive. Apparently with most parts you can briefly touch 12v (through a resistor) to the UPDI pin and then program them normally.

On the 2-series parts you can use the updi with alternate reset pin option to get reset on PB4 while retaining UPDI functionality on PA0, which is obviously greatly preferable to disabling UPDI on that pin.

Fuse 4 defaults to 0x00 on the parts where it is not reserved. I've never had any problems with it being set but it probably should not be set at all on 0 and 2 series parts. (on 1-series parts, it lets you control the startup configuration of the TCD0.FAULTCTRL register, because they are apparently convinced that that it will have dire consequences if that is ever misconfigured (at runtime it's enable-locked and protected, too - turning pwm on a TCD-controlled pin on or off requires a _PROTECTED_WRITE sequence, which which is normally reserved for things like reconfiguring the clock configuration, )

Yes, fuse 5 is being set incorrectly on the 2-series, that setting was carried over from the 0/1-series whee the 4th bit's factory configuration was 0 and was unused, thanks for reporting.

Which parts are you programming? I see an excerpt from the 2-series datasheet, but your schematic shows a 0-series part.

[arihantdaga]

I am using 2 series part only. Ohk, understood. Thank you very much. :) I would like to do a PR and fix this. Can we also enroll this repo for hacktoberfest ? 😅😅 I am not sure, but is hacktoberfest tag required for a repo to be eligible ?

[SpenceKonde]

I don't know what hacktoberfest is o_o

[SpenceKonde]

Wow, getting rid of the TCD0CFG write is a a bitch - because we can't do any sort of logic in the platform.txt recipes,- there's no way to be like "If bootloader.TCD0CFG is defined, replace this with 4:{bootloader.TCD0CFG}" in the SerialUPDI recipe, and "if bootloader.TCD0CFG is defined, replace this with -Ufuse4:w:{bootloader.TCD0CFG}:m" in the avrdude recipe.

[SpenceKonde]

Okay, I think the new boards.txt and platform.txt should work.

I absolutely despise the boards.txt format. You have to copy-paste lines here there and everywhere, and then remember to change 1 character in 3 locations on each line you copy-pasted, And because there's both a board.menu.optionname.enable=Option Enabled; that;'s it;s display name, but there are also a bunch of sub-variables under it like board.menu.optionname.enable.fuse=0x69 - so it's also hard to write a parser for if I wanted to automate it, which i very badly want to, since there are basically no differences between the parts other than how many of the connection points on the die have a bond wire connected to them and what they wrote in the chip's signature row during factory cal (this is speculation, but I am pretty sure that at the same time as the factory cal, that's also when they tell the chip what it's going to be - it's clear from the extent of the similarities and the . And the sigrow would make sense for where that would be written, since there are a bunch of mysterious values constant for all devices of a given part number, but not across different part numbers., values with striking patterns - they strike me as very low entropy, as if they're formatted so that a computer requires no manipulation to make use of them... and we know they already write to the rest of the sigrow at that time....)

[SpenceKonde]

For the record, I do not believe that either of those fuse issues have anything to do with the difficulty you were having.

[arihantdaga]

I'll check again with latest files.

[DominikRzecki]

Hello, I have a very similar problem with the ATtiny1624. Did you manage to solve that, or did you just buy a new chip?

[SpenceKonde]

Just fix the bad wirining or whatever else is causing the problem. at error most often indicattes a problem with the network or device configuration