Closed minimism closed 3 years ago
The issue with bootloading 416 is - I think - fixed by 2.2.7 which should be available in board manager (and working) now (as of like 10 minutes ago, though there was a broken version listed earlier in the morning). Luckily I botched the binary packaging, so the bad 2.2.7 was never available on board manager, and before I realized that, I checked the CI logs and realized I'd also screwed up the core itself.
Problem uploading implies is consistent with wrong serial port selected or... almost any other problem (first thing I'd check is that if you reset the board, does the LED blink? If not, does an LED + resistor put from PA7 to ground flash when you reset the board? (if no for on-board LED, but yes for PA7 that suggests that the bootloader is getting built as a "normal" 416 bootloader (though I don't know, off-hand, what's different about 416 xplaineed boards - I don't have any!)
Thanks for the speedy response :)
I just tried updating and get an error with the JSON file:
Skipping contributed index file /Users/namke/Library/Arduino15/package_drazzy.com_index.json, parsing error occured:
com.fasterxml.jackson.databind.JsonMappingException: Unexpected character ('{' (code 123)): was expecting comma to separate Array entries
at [Source: (FileInputStream); line: 3704, column: 10]
at [Source: (FileInputStream); line: 3703, column: 9] (through reference chain: cc.arduino.contributions.packages.ContributionsIndex["packages"]->java.util.ArrayList[2]->cc.arduino.contributions.packages.ContributedPackage["platforms"])
Skipping contributed index file /Users/namke/Library/Arduino15/package_drazzy.com_index.json, parsing error occured:
com.fasterxml.jackson.databind.JsonMappingException: Unexpected character ('{' (code 123)): was expecting comma to separate Array entries
at [Source: (FileInputStream); line: 3704, column: 10]
at [Source: (FileInputStream); line: 3703, column: 9] (through reference chain: cc.arduino.contributions.packages.ContributionsIndex["packages"]->java.util.ArrayList[2]->cc.arduino.contributions.packages.ContributedPackage["platforms"])
I also noticed that the bootloader upload works when the mEDBG LED is off, but not when it is on. Uploading a sketch still fails on the second/subsequent attempts. Current workaround is: unplug USB; replug USB; burn bootloader; burn sketch. Repeat :) I'm just playing with these at the moment but I am very excited at the prospect of moving a bunch of ATTiny85 code over to the new parts, so your efforts are well appreciated!
This may be fixed now, just pressed backspace one time too many while deleting the bogus entry.
@SpenceKonde it looks like my Blink is toggling pin A7 when using LED_BUILTIN
on this board. The user LED is attached to pin PB5 on this particular XPLained board.
This may be fixed now, just pressed backspace one time too many while deleting the bogus entry.
:sad face:
Error downloading https://SpenceKonde.github.io/megaTinyCore/megaTinyCore-2.2.7.tar.bz2
java.lang.RuntimeException: java.lang.Exception: Error downloading https://SpenceKonde.github.io/megaTinyCore/megaTinyCore-2.2.7.tar.bz2
at cc.arduino.contributions.packages.ui.ContributionManagerUI.lambda$onInstallPressed$2(ContributionManagerUI.java:175)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.Exception: Error downloading https://SpenceKonde.github.io/megaTinyCore/megaTinyCore-2.2.7.tar.bz2
at cc.arduino.contributions.DownloadableContributionsDownloader.download(DownloadableContributionsDownloader.java:149)
at cc.arduino.contributions.DownloadableContributionsDownloader.download(DownloadableContributionsDownloader.java:83)
at cc.arduino.contributions.DownloadableContributionsDownloader.download(DownloadableContributionsDownloader.java:60)
at cc.arduino.contributions.packages.ContributionInstaller.install(ContributionInstaller.java:105)
at cc.arduino.contributions.packages.ui.ContributionManagerUI.lambda$onInstallPressed$2(ContributionManagerUI.java:172)
... 1 more
Caused by: java.io.IOException: Received invalid http status code from server: 404
at cc.arduino.utils.network.FileDownloader.openConnectionAndFillTheFile(FileDownloader.java:239)
at cc.arduino.utils.network.FileDownloader.downloadFile(FileDownloader.java:182)
at cc.arduino.utils.network.FileDownloader.download(FileDownloader.java:129)
at cc.arduino.contributions.DownloadableContributionsDownloader.download(DownloadableContributionsDownloader.java:147)
... 5 more
I might need to wait for it to propogate through some intermediate network caches…
euuurrghhhh more stiupid bullshit from the bunged release... it's there now (always was, but the filename was wrong, because I'd forgotten to correct it the second time around for the different name that got used because github doesn't let you reuse a version number.
@SpenceKonde it looks like my Blink is toggling pin A7 when using
LED_BUILTIN
on this board. The user LED is attached to pin PB5 on this particular XPLained board.
Blink will use PA7 (I'll make a new issue for that, as this should be handled way better on official Microchip boards). the question is what the bootloader uses (assuming you even want to use the bootloader with it)
@SpenceKonde it looks like my Blink is toggling pin A7 when using
LED_BUILTIN
on this board. The user LED is attached to pin PB5 on this particular XPLained board.Blink will use PA7 (I'll make a new issue for that, as this should be handled way better on official Microchip boards). the question is what the bootloader uses (assuming you even want to use the bootloader with it)
Well, with my previous Tiny projects I've not used a bootloader, so I'm not 100% sure what benefits I would gain. I don't honestly know what happens in the Mega32 which is performing the UPDI comms. Happy to help if this is a more widely-encountered issue otherwise I'll just rig up a separate UPDI programmer and use a bare Tiny.
I mean, I wouldn't use the bootloader under most circumstances (and I'd sooner hit myself with a hammer than do it on a 4k part :-P) - but the second error you posted was a bootloader upload error, and you're using the Optiboot board definition, so I figured that was your plan (using optiboot, I mean, not hitting yourself with a hammer - I don't recommend it, but if that's your thing - knock yourself out ;-) ).
Some people like having one serial port to upload and get serial console on? (you also are sort of forced to use one if you can't get up close to it easily to connect a programmer, eg, the board is at the far end of an RS485 cable, so you'd better be able to program it through that (we do have people doing this with both this and the classic core)). I used to like that, but since I now avoid the arduino serial console like the plague anyway, it's way better for me to just have the IDE pointed at the UPDI programming pins, and serial adapter on the UART pins. (and then I leave the console open the whole time, and I don't have to race the sketch's startup time to open a serial window without missing stuff)
Oh - the other good reason to use bootloader is if you need to write flash from application; On DxCore I was able to get this to work both with and without bootloader, but the flash write protect on the 0/1/2-series is a bit pickier it seems, and so the solution for it is more work. Flash write from app is actually in for Optiboot board def's with the bootloader properly installed and working... but I couldn't figure out the interface for it at first glance, and there wasnt an intelligible example either. so I went and did more important things.
I suppose that I was only using the Optiboot option as it was the only one mentioning the Xplained 416 board … I probably should read some stuff before diving in. My ATTiny85 debugging is usually via i/o pins and oscilloscope (audio stuff, so there's no time to spit out characters over serial), and I was expecting to do the same with these new parts too. The only bootloader I would be using would be TinyAudioBoot, and that's only for one particular scenario (and with the larger parts for sure).
My thinking was that since the board is mentioned by name, then the programming interface stuff would already be sorted for me; however that may very well have been a false assumption and I should just dig out the serial converter and a resistor…
At the risk of polluting this issue-thread, I'm still getting a file-not-found on the 2.2.7 update tar file (no underscore in the filename?? Error downloading https://SpenceKonde.github.io/megaTinyCore/megaTinyCore-2.2.7.tar.bz2
).
Okay NOW you are in cache hell, I think. You should see that https://spencekonde.github.io/megaTinyCore/megaTinyCore-2.2.7.tar.bz2 does come up in a browser now (there is not supposed to be an underscore - the underscore shouldn't have been there on anything, ever.
Reboot should fix it,assuming the file is accessible tro you.
Sounds like I should do a bit more to clarify the correct board option to choose, heh...
Right - great, thank you :) After a cup of tea everything works of course. I'm now on 2.2.7.
Putting aside the bootloader; it appears that I can still only upload once per power-cycle to the board. After a successful upload I see:
avrdude: verifying ...
avrdude: 1182 bytes of flash verified
avrdude: jtag3_edbg_signoff(): unexpected response 0x03, 0x80
avrdude done. Thank you.
so I wonder whether the jtag signoff is failing somehow and the connection remains, making it unavailable for subsequent programming cycles. I only have a vague idea about how the debug connection works (I use JTAG on a day-to-day basis without really worrying how it works, just that it does!)
Huh. Weird. I don't know what to say then x_x Is the f/w on the debug/programming chip updated?
Huh. Weird. I don't know what to say then x_x Is the f/w on the debug/programming chip updated?
Good question. I have so far been avoiding installing MPLAB etc. but I may have to to verify that using my old windows laptop. Alternatively I'll just solder the various Tinys that arrived today onto the SOIC-DIP adapters and play with those!
Well, I just updated the firmare on the board using the freshest download of Microchip Studio, but no change to behaviour :(
/Users/namke/Library/Arduino15/packages/arduino/tools/avrdude/6.3.0-arduino18/bin/avrdude -C/Users/namke/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.2.7/avrdude.conf -v -pattiny416 -cxplainedmini_updi -Pusb -Ufuse2:w:0x02:m -Ufuse6:w:0x07:m -Ufuse8:w:0x2:m -Uflash:w:/var/folders/tp/79kkq_6x6g71t06rvmw23q400000gp/T/arduino_build_231164/Blink.ino.hex:i
avrdude: Version 6.3-20201216
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/Users/namke/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.2.7/avrdude.conf"
User configuration file is "/Users/namke/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : usb
Using Programmer : xplainedmini_updi
avrdude: Found CMSIS-DAP compliant device, using EDBG protocol
avrdude: jtag3_edbg_recv(): Inconsistent fragment number; expect 1, got 0
avrdude done. Thank you.
An error occurred while uploading the sketch
I'll move on to using a bare device and a separate UPDI programmer.
closing as my care package from microchip didn't include any of these and even if I had some on hand, it looks like it would need a fix in avrdude, which is not a road I am going to go down,.
The isue is with Arduino's avrdude 6.3 fork. It has issues and it will make the FW in a bad state.
Using vanilla avrdude 7.0 is fine.
Ref: https://github.com/avrdudes/avrdude/issues/741#issuecomment-1233599607
Avrdude 7.0 will be used in some future version of the core. It categorically will not be going into 2.6.2 or DxC 1.5.0 and isn't going into anything until the basic stuff works. Microchip boards based on substandard (small flash when larger flash is available, plus it's below the magic threshold that gets you a second whole adc, 2 more analog comparator, a full 2k of ram etc.etc..... since this is not a regression, it will be deferred until the immediate crisis is solved, which is that ther3 are issues with mTC impacting all users, and we still don't hVe a bloody dxcore with dd support out.
Spence Konde Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: @.***
On Thu, Oct 6, 2022, 07:42 mcuee @.***> wrote:
The isue is with Arduino's avrdude 6.3 fork. It has issues and it will make the FW in a bad state.
Using vanilla avrdude 7.0 is fine.
Ref: avrdudes/avrdude#741 (comment) https://github.com/avrdudes/avrdude/issues/741#issuecomment-1233599607
— Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/megaTinyCore/issues/312#issuecomment-1269876939, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW7O33VHHQ2UU466EA3WB23JTANCNFSM4XNEOCQQ . You are receiving this because you modified the open/close state.Message ID: @.***>
(Using megaTinyCore 2.2.6; Arduino 1.8.13; MacOS 10.15.7)
I only got the Xplained 416 Nano board a few hours ago but I'm having trouble with flashing not always working. It seems that sometimes I can upload code if I first burn the bootloader, but subsequent attempts at flashing fail. Also, successive attempts at burning the bootloader fail.
I am using the onboard ATMEL mEDBG programmer as the nEDBG doesn't work at all (although I suspect that should be the 'right' one?)
Successful bootloader flash:
Unsuccessful bootloader flash:
Unsuccessful upload of
blink