Unlock Bootloader Lg G7 Thinq

[Meinard Hartmann]

Theproblem seems to center around the IDE, and programming via USB. I can program happily via ISP, with my Atmel charger code working well. (I'm switching the code over to Arduino for the ability to do USB firmware updates in the field without having to muck about with Atmel's oddly unsophisticated bootloader, or going down the LUFA rabbithole. There are only so many hours I can bill to my employer for learning new tricks )

I can set the fuses to the values I read in the Micro (low 0xFF, high 0xDB, ext 0xCB). But when I Read them again, the extended fuses Read 0xFF (no HWBE, 2.6V brownout). That's the same settings as the Micro, but the Micro's extended fuses Read as 0xCB. Weird?!

I believe you need to compile your (application) code with the Arduino IDE in order for the transfer to the bootloader to work. Also if you use the IDE to install the bootloader the fuses will be set correctly during the installation.

There's a good clue. I can load in the bootloader with AtmelICE via ARM ISP, and the contents read the same as the Micro, which I erased, then loaded the same bootloader into (and still works as expected). But when I try to use the IDE to load the bootloader, I get

Could it be a problem with the IDE somehow not seeing the programmer? It's definitely looking for it, and the VID and PID are correct in Device Manager. But "Burn Bootloader" doesn't work with either the Atmel-ICE or and JTAGice3. Similar failure report:

Am I missing something basic in the Burn Bootloader thing? I chose the board (Genuino Micro), the tool (AtmelICE-ARM or JTAG-ICE3(ISP), and yes, they're connected properly with a tag-connect that is confirmed working with AS7), and then I click Burn Bootloader. Only to fail every time, on all three boards.

Now I'm trying to swap the original Arduino 32u4 with mine, to see if that magical mystery extended fuse business is the culprit for the programming failure to my boards. As for the Burn Bootloader failure... annoyed and stymied by that one.

Okay, I successfully put the 32u4 from my board onto the Arduino Micro. It exhibits the same failure as my board did before, when loading the Blink sketch -- it can't find the board and eventually drops it from the Device Manager.

Since it's on the Arduino board now, I'm satisfied that it's not a hardware issue on my board. I think it has to do with the extended fuse that I can't set to 0xCB. With Atmel Studio, I can try to set it to 0xCB, but when I read it, it comes back up as 0xFB. However, the datasheet doesn't have any functions listed for bits 4&5 of extended fuses. But if they're not used, why are they set on the Arduino???

Is the Arduino IDE somehow able to set mystery fuses that AS is not able to? Bootloader pointer? Or something similar that is not allowing it to program my chip?

The extended fuse upper four bits are fixed in hardware and cannot be altered. What you see is a difference in how the software is reporting things -- avrdude is wrong, studio is correct. There has been a long term problem with the way avrdude reports unchangeable fuse settings. Just believe the data sheet.

It certainly looks like the non-Arduino chips are entering bootloader, but not coming back up on a virtual port like the chips off the Arduino do. The mystery to me is why the Arduino chips are not doing the same thing, as I erased them (confirmed) and loaded the same bootloader hex into them fresh.

I guess I could get a ton of cheap Micro ripoffs and take the chips off. The new production style!

Fuses: I have only read fuses with Studio. On the Arduino chips the extended fuses are 0xCB. On the fresh Atmel chips, 0xFB for the same settings, even if I try to write them to 0xCB.

(And don't always trust the datasheet. I've had too many FAEs tell me, "Oh yeah, ignore that, it doesn't work like that." :))

My experiance is that the upper efuse bits cannot be changed by writing a different value to them. Trying to change the efuse upper bits just gets a verification error from avrdude. So if the efuse is the problem how are you going to change the value??

Why would boards.txt even have 0xCB as a value? And if the upper bits can't be written to, how can I read it as 0xCB? We have us a bona fide mystery!

As some point I'll keep it as an option to change the boards.txt for my boards, so that avrdude is expecting 0xFB instead of 0xCB.

Anyway, I did have some success with the bootloader burning. It seems that avrdude and Atmel tools (jtagice3, etc.) have had some recent difficulties. Newer avrdude versions are looking for the tool to be using a libusbk driver. I changed that, and was able to burn the bootloader sometimes with ArduinoISP. Still some digging to do there, but a step forward is a good step. At least the IDE sees the tools now.

Which indicates it reads back the fuse value from the chip but does not set the unused ones. I figured this out when I was trying to program a 328pb, and the new fuse bit it has was reading wrong, but I was not able to clear it with avrdude.

The culprit, mostly, was tools. I still can't get the ICE or JTAGICE3 to work with the IDE. Changing drivers got the IDE to see the tool finally, but those tools could never see the target.

And loading the hex file with Studio always had a bug, where the device would look good (hex file read from chip was the same as bootloader hex file), but when you try to upload a sketch, the target would disappear, seemingly unable to come back up on a new, virtual COM like expected.

Arduino as ISP finally worked for me, after some trials. (By the way, as I'm sure you all know, even though the sketch is called ArduinoISP, you don't use the ArduinoISP tool to burn the bootloader. I mean, why would you do that, right? You use the 'Arduino as ISP' tool :))

I also ran into extra problems with Uno -> jumpers -> adapter board -> tag connect cable -> target, where I'm thinking my issue may have been total wire length. Doubtful? Maybe. I tested continuity on the wires. But chopping a tag connect cable and splicing it to the UNO worked. Oh, and uncommenting line 81.

Ok I just had my headset go into bootloader mode and had the same problem. I was also getting the same results as the guys above me. I would follow the instructions posted and go to fimware up date and try to update my headset and it would just sit there and do nothing.

Apparently I fell asleep and left the headset on my table while music was on loop and the buttons where faced towards the table, so im guessing they have been constantly pressed throughout the night, at least there is no other way i would explain how it got stuck in bootloader mode.

I followed the instructions step by step, repeated them a few times and when it still didnt work i kept reading. I tried pressing the mute button while plugging in the usb cable to my computer a few times but that didnt work either.

I was playing wow last night, and when I wake up, I try to turn on the headphones and they do not work. Lights does not light or flash. I try everything you said here, I update the CUE to the latest version, but my headset is still show disconnected, any help here?.

I had my Void Pro yellow headset working for one day and then it apparently had gone into bootloader mode the next time I tried to charge/use it. I couldn't get them to charge or work and I had the asterick/exclamation mark showing in the headset icon in iCue. I found this forum and updated the iCue to 3.10. I tried to force the update firmware, but it just sat on 0%. Then I saw about letting the batteries on everything go flat. So I unplugged the headset and the wireless dongle and left them for four or five days.

I decided to try the firmware again this morning. I plugged in the headset lead to the computer. I then held the mute button and plugged in the lead to the headset. Then I opened iCUE and then plugged in the dongle and the headset was recognised, but the asterick/exclamation mark was still present.......but, the headset was charging! I then tried the forced firmware update and success it worked this time and the asterick/exclamation mark has gone form the iCUE icon! I'm just waiting for the headset to fully charge and then I'll try them again, but fingers crossed they seem to be working. I think the key is to fully discharge both the headset and dongle. Good luck to those of you with the same problem.

I took the dang thing back to Best Buy and exchanged it. I told my son this thing is junk and it may happen yet again that I see tons of people struggling with this problematic headset on a website forum but he really wants this one.

After doing an investigation we have found out that what may be causing VOID Wireless to go into bootloader mode when charging. When plugging VOID wireless in for charging, while holding onto any button - the headset will go into bootloader mode (thanks @Nicklez for identifying this). Please refrain from pressing any buttons while plugging the headset in. be careful with finger placement when plugging headset in! If any button is press and held while inserting the USB cable in, your headset will be in bootloader mode!!!!

As of now, bootloader mode will not have any indication if it is in this mode except it will not appear to power on, generate audio, or have the lights turn on. In other words, it'll look like the headset has stopped working. Bootloader mode is implemented as a fail safe, so that headset can still be recovered in case of "bricking" or a bad firmware update, etc.

Our next steps to how we're dealing with bootloader mode... we're looking into having a visual indicator if the headset is in bootloader mode so that users will be able to identify what's going on with their headsets right away. We are also looking into different sequences to enter bootloader mode. (So instead of pressing the mute button and plugging it in, users have to press multiple buttons and plug it in). We're also exploring the idea of having bootloader mode only available when plugged in via USB.

3a8082e126