Wrong / static target showing up in MP Lab X

[platima]

Great work - purchased from your Tindie store, and using for my DeepSleepr project!

Oddly though, in MP Lab X the kit comes up as having a ATmega4809 connected - it's actually on an Attiny414.

Having dug through https://github.com/MCUdude/microUPDIcore I cannot find reason for this.

When I try to use it as a tool, overriding the device detection, it just loops forever trying to update the mEDBG firmware;

Currently loaded versions:
Application version...........1.19.57 (0x01.0x13.0x39)
Tool pack version .............1.2.438
Entering firmware upgrade mode

Any ideas? Cheers

[MCUdude]

The mEDBG firmware is actually designed to be used with a ready-made kit. The firmware the MicroUPDI programmer uses was pulled from a board that used an ATmega4809. If you want to change this you can connect an ISP programmer to it and inspect it's EEPROM content. I'm the EE memory somewhere the 3-byte ATmega4809 signature that's in there can be replaced with the ATtiny414 if you like.

[platima]

Ah yep excellent - will look for that signature.

Any idea about MP Lab IDE X trying to upgrade the mEDBG firmware in loop? I am thinking I might just try to find that hex version info and match it.

[MCUdude]

I don't think it will try to update the firmware, as it is the latest. And the Micro UPDI uses a different bootloader, (avr109 instead of DFU), so it won't succeed anyways.

[platima]

That's what I would have thought too! Long story short microUPDI appears to boot fine, shows up as 'miniUPDI' in the X IDE kits. I enable Tools -> Options -> Embedded -> "Exclude device checks for kits" else it complains about it being a 4809.

Then when I try to flash my 414 with it, it compiles the code, then pops up with a new window. The microUPDI reboots into bootloader mode (all LEDs on) and the window repeats the following forever:

Currently loaded versions:
Application version...........1.19.57 (0x01.0x13.0x39)
Tool pack version .............1.2.438
Entering firmware upgrade mode

Checking MCC Content Manager, 1.2.438 is the version of the mEDBG Support Kit installed, so it appears to be trying to up/downgrade 1.19.57 as it detects on the programmer to what it has. The only other kit version available are 1.1.105 or 1.0.11.

Absolutely stumped! Using my jtag2updi instead again, but obviously I'd prefer to use this - hence paying for it hah. Also on that note, just let me know if you want me to stock it at https://shop.plati.ma 😊

Welcoming any input, and thanks again!

[mraardvark]

One thing you could try to do to prevent MPLAB from updating the firmware: set an environment variable: _JAVA_OPTIONS to -Dgen4.disable.updates=true No idea if it works for mEDBG, but worth a try

[platima]

Could not find any option for that!

Worked on the hex files for a while, managed to get it to see an "ATmega4149" haha, but could not get the version string changed to match. Then instead tried the other option; made an mEDBG Pack for MPLABX that matched the version strings and didn't include upgrade files. That ALMOST worked, but; Failed to get Device ID. Please make sure the target device is attached and try the operation again.

Full log debugtool.txt

And I'm stumped again. Confirmed it's definitely set to UPDI mode, 0.5MHz, no high voltage.

EDIT: Scrap that, it actually works! The target just couldn't draw enough current from the 5V programming connection and crashed. When I powered the target using a 2nd USB cable, it worked.

Want me to issue a PR with a copy of the MP Lab X IDE 6.20 pack so others can use your wonderful little tool with it?

[MCUdude]

If you want to study the mEDBG/microUPDI EEPROM content, the developers revealed a few secrets here: https://www.avrfreaks.net/s/topic/a5C3l000000UkjBEAS/t192342?comment=P-1635680

Want me to issue a PR with a copy of the MP Lab X IDE 6.20 pack so others can use your wonderful little tool with it?

Thanks, but I'm already working on updating the firmware. I also need to modify the hex file so so you won't have to physically connect the AREF pin to VCC.

[MCUdude]

I just pushed a new firmware version. Try installing microUPDIcore manually, force-enter bootloader mode on your microUPDI programmer and see if it does the trick. Works fine here with MPLAB X!

[platima]

Hey thanks for that link - just modified the EEP file to show a 414. Attached if ever needed.

Is it just your firmware that's updated, or the EEPROM too?[ mEDBG_UPDI_1.13_ATtiny414.eep.zip

[MCUdude]

I've also modified the EEPROM too, but that's just cometic changes. For some reason, the programmer identified itself as a "miniUPDI" programmer in MPLAB X. I changed this to "microUPDI programmer". Apart from this, everything is the same in the EEPROM.

[platima]

Yep okay board name shows up as "microUPDI programmer" after flashing with new FW.

Any notable changes? Your commit just said version update 😅

[platima]

Confirmed works perfectly IN MPLAB X IDE 6.20 without requiring custom pack (default of 'use latest' works fine).

Thank you kindly good sir

[MCUdude]

I did write a short summary of which changes where done in this commit.

https://github.com/MCUdude/microUPDIcore/commit/cf361357a9963a89c9a26753d5d09b104e91119b

The new firmware probably doesn't matter all that much, other than making MPLAB X happy. I'll do a proper boards manager release soon

[platima]

I did write a short summary of which changes where done in this commit.

Somehow I completely missed that hah

Great stuff, that's hugely appreciated.

As mentioned, if you want to stock your programmer in my shop just let me know. Seems like a lot of people make good use of it!

Either way, back to working on DeepSleepr with better debugging now 😊 Cheers!

[platima]

Found a new issue, but I don't think it's on your end - build and program for production; works fine. Build and program for debug, and it never completes programming. Hangs forever. Both this new and the previous hex & EEPROM seem to do it though, so probably something in MPLAB X I need to address

[MCUdude]

As mentioned, if you want to stock your programmer in my shop just let me know. Seems like a lot of people make good use of it!

Thanks for the offer, but I'm quite happy with Tindie. I don't make and sell boards to make a whole lot of money, I do it because I enjoy tinkering in the evenings. And at the moment I'm fine with the current "pace" where I ship a programmer or two every now and then.

Found a new issue, but I don't think it's on your end - build and program for production; works fine. Build and program for debug, and it never completes programming. Hangs forever. Both this new and the previous hex & EEPROM seem to do it though, so probably something in MPLAB X I need to address

Sounds like an MPLAB X problem indeed! And if there was a bug in the mEDBG firmware, it would be next to impossible to fix it, because the firmware is closed source.

[platima]

I don't make and sell boards to make a whole lot of money, I do it because I enjoy tinkering in the evenings

I fully get that - that's why I started the shop (excess goods hah) and make the YouTube videos. Still yet to take any money back out of it, but enjoying it and building up a broader range of products.

Okay yeah fair - time to headbutt MPLAB X for a while hah.

EDIT: I'm a spud. My code goes straight into a sleep mode. Of course that does not debug 😅

[MCUdude]

EDIT: I'm a spud. My code goes straight into a sleep mode. Of course that does not debug 😅

Great to hear you figured it out! A new release of microUPDIcore is now available through boards manager (v1.0.3), so I'm closing this. I've also added documentation regarding the EEPROM content and how to modify it.

[platima]

Nice one! Take care and keep up the great work