Unlock Bootloader Without Mi Unlock Tool
Nella Mcnairy
I've been having a lot of issues programming my Arduino UNO of late, with failure to connect issues from avrdude. I suspect a USB problem on the computer side. In the meanwhile, I was wondering if I can use an ISP to program the board.
Not without combining the bootloader and sketch hex files, then writing that manually using avrdude. Only being able to do a whole chip erase is part of their security model - that's also the only way to clear the lock bits (which can be set to keep people from reading the flash).
Why are you so afraid of just doing a Tools > Burn Bootloader when you want to go back to using the bootloader again? It's just as easy as doing an Upload Using Programmer; you just need to select the correct board from the Tools > Board menu first.
Mostly because I've not done it before, and was looking for a quick fix to the USB problem. I'm sure I can burn the bootloader, but that becomes a new thing to do. I don't need another thing to do right now
I wouldn't be so sure. avrdude has an issue with libusb and due to the way avrduded is coded, atmel ISP programmers like AVR dragon, and AVR ISP MK II, can't be used with the IDE to burn a bootloader.
I'm not sure if this affects the atmel ICE as well, but it is likely.
I've been trying to get this fixed for MANY years.
I even provided the patch to avrdude to fix it (it is less than 5 lines of code) but the main author refuses to pull it in claiming it is a libusb issue, when in fact it is avrdude that creates the issue.
What causes it is doing two back to back avrdude commands. The second avrdude command will fail as it won't be able to locate the USB ISP device because avrdude reset the USB on the fist command and when the second avrdude command runs, the USB ISP device has not enumerated yet so the device doesn't exist at that point in time as far as the OS is concerned.
The fix in avrdude and the work around in the IDE are both really small and simple and don't affect anything else
but so far after many years, it remains an open issue in both savanna for avrdude and on github for the arduino IDE.
While the Atmel USB ISP devices definitely can program a bootloader using avrdude, as far as I've seen
it still cannot be done using the Arduino IDE and this has been an issue for many years.
Actually, it has never worked.
I now mostly use a USBasp device with my custom f/w which is much faster than the Dragon,
I occasionally use my dragon as well, but not with the arduino IDE using the avrdude it comes with.
To use the Arduino IDE requires using a custom version of avrdude with a fix.
The low level USB code in avrdude for the jtagMKII devices (which includes the dragon and MK II) resets the USB just before it exits for AVR dragon and MK II devices.
The result is that on back to back commands the 2nd command will fail.
Here is the full output from IDE version 1.8.5 attempting to burn a bootloader into an UNO type device that shows the issue and error on the 2nd avrdude command.
(The first avrdude command worked just fine)
If it wasn't so late, I'd pull out some bits and show the results of a successful bootload. Everyboard I make, I bootload with the Atmel AVR ISP MKii and then load Blink with an FTDI Basic clone to demo basic functionality, all using the IDE.
I haven't seen the error you demonstrated. Is it because I am running the 2 programming steps manually from the IDE and there is more time between steps than what you are doing running from avrdude directly?
CrossRoads:
I haven't seen the error you demonstrated. Is it because I am running the 2 programming steps manually from the IDE and there is more time between steps than what you are doing running from avrdude directly?
Not sure what you mean by "I am running the 2 programming steps manually from the IDE"
When you click on [Tools]->Burn Bootloader
The IDE does it all under the hood and will use two avrdude commands to burn a bootloader.
One command to set the fuses
And a 2nd command to actually burn the bootloader.
The problem is that avrdude resets the USB which resets the Dragon and I'm assuming the MK II as well.
The device then has to startup again and re-enumerate with the OS.
If the 2nd command comes in before all that has happened, then the current avrdude code will not see the device.
(The patch I created simply looks for a few seconds rather than just once before giving up)
It appears that at least on the Dragon that Atmel was really dumb and resets the actual processor when a USB bus reset happens. This is really really dumb. There is no need to reset the device's processor just because the USB bus reset. The power up code on the Dragon takes a few seconds.
Now if the USB host is really slow, then the device might have enough time to come up and be ready by the time the 2nd avrdude command runs.
But it is many seconds so this is normally not really a possibility.
I can reproduce the problem bperrybap mentioned using AVRDUDE 6.0.1 with the libusb-win32 driver. However, if I use AVRDUDE 6.0.1 with the libusbK driver or AVRDUDE 6.3.0 with either driver it works correctly. The results are the same for me across 3 different computers, Windows 7 (32 bit and 64 bit) and Windows 10.
I don't do windows.... or mac so I can't speak for what is happening there.
The avrdude that comes with the linux package doesn't work and still has the issue.
Here is the original issue from back in 2011.
usb_reset() resets the USB and causes the device to disappear.
The fix is that if the avrdude code is going to call usb_reset() to reset the USB bus, it also needs poll for a few seconds when looking for a device to give it time to recover.
Joerg didn't like this solution as he uses avrdude in an undocumented way to locate and print out all the devices on his network and this added polling time would effectively break what he likes to do since he scans for many devices that may not be there or turned on.
I believe that it was an oversight and that there was a lack of understanding that it could be done in a single command.
They didn't read the documentation to understand how avrdude works.
The fuses need to get set one way, then a burn has to be done then the fuses need to be set another way.
So they simply used multiple commands to do it.
The documentation is very clear if you specify multiple things on the command line, they happen in the order you specify, so you can do multiple things in one avrdude command.
I even had trouble convincing westfw to modify his optiboot makefile for the single command work around over this very point even when I showed that it worked by actually doing it all in a single avrdude command.
My assumption:
The issue, was only seen by such a relatively few number of people, literally probably only a handful, particularly in more recent avrdude versions with newer libusb libraries on Windows.
So the issue has been allowed to languish.
I also think that some of the developers are afraid to go in an touch any of the IDE java code which is where this stuff is being done.
There are many things in Arduino that are done or not done out of ignorance and lack of understanding.
And along that same line, the developers are sometimes very reluctant to fix things or modify any code when they don't understand the issue or don't have lots of complaints over it.
(like the atomicity issue in digitalWrite())
Sometimes there is no technical reason not to fix things and it is just plain obstinacy
(like the single tab vs whitespace (multiple tab or multiple spaces) separator in the keywords.txt file)
It has been be very frustrating at times to get things fixed.
In recent years things have gotten much much better, but it often comes down to the individual developer.
Now Windows 7 does give this option and I might also edit the BCD store to make changes in the boot menu of Windows 7, or I could use EasyBCD. I don't want to use these options as I need to customize hiding/unhiding of partitions at the time of booting etc. I search and found GRUB; it might be the tool I am looking for.
I want to use GRUB loader without any version of Linux installed on the system. Can someone guide me on how I can install the GRUB on the hard disk MBR and configure the boot menu? I searched Internet and mostly I came across commands which search the GRUB on the hard disk (because of an existing Linux installation) and then try to repair it. In my case there is no Linux at all.
Hello Jitendra Gupta and thanks for your answer, but I can't really see how these scripts can help me because my goal is to send data using the bootloader not just flash the device. thanks
If that is the case you better refer above mentioned python script which is equivalent implementation but instead of external MCU, that script is running on PC and communicating to AWR1843 over UART interface to send the binary file byte data to finally flash it.
so in this example, I am trying to send just 4 bytes as shown here with the write to flash command and this is the sequence of commands I am using : get version cmd, a buffer containing CC, open cmd, get status cmd, CC buffer, write to flash cmd, get status cd, CC buffer, close cmd, get status cmd and lastly another CC buffer as shown here
and I have been getting an ACK response 0xCC from all commands except the close command which gives me a NACK response 0x33 so do you have any idea why is that? PS: I verified with the logic analyzer that the commands sent by the Uniflash tool while loading an image to the radar are the same as the commands that I've been sending to the radar using an external MCU and also with the same order.
The Open command does not look correct for SFLASH storage. For SFLASH you should be using 2 while it looks you are using 4 which is for RAM. Can you once again check your open command buffer and let us know your results/observations.
where 0x2B is the checksum value, and after the 0x21 byte we put the file size ( we write on 4 bytes), and since I am sending 4 bytes in my write to flash command: so that should be 0x00 0x00 0x00 0x04. After that, there is the storage type ( 4 bytes as well ) as you said SFLASH should be then 0x00 0x00 0x00 0x02 and at last, the file type I used META IMAGE 1 which is 0x00 0x00 0x00 0x04 and I added 4 reserved bytes in the end as stated in document 0x00 0x00 0x00 0x00. So I believe my command is correct. Thanks
c80f0f1006