-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Xplained Mini ATtiny817, unable to upload due to baudrate -b{upload.speed} [edit] + workaround #1030
Comments
I thought this was fixed in the most recent release... |
And you aresure it's not a 328p? I don't have much to suggest - though I don't know why tyou are specifying -P for the port twice, it should only be specified once, in this case USB. |
Yes, this target does not look like a 328P to me :-) The programmer chip is the Atmega32U4 I am not specifying -P twice. MegaTinyCore is generating -P twice as part of the upload command, and not parsing the {upload.speed}. This is what MTC generates that I then have to tweak into this to make the upload work: I can then only upload once. I first need to unplug and replug the Xplained Mini to upload again via a tweaked upload commandline. Without powercycle any subsequent upload fails. Here is the upload logging after I first powercycle
Here is the failed upload logging if I do not powercycle first
|
Mystery about the Xplained Mini showing up as Atmega328 in my Github version of MTC I think I have solved. While I selct the MTC board I also have another boards package for the legacy Xplained mini's (328P). After I removed that boards package via the boards manager. I only see "COM3" in my serial ports list. No more name behind it, so I think that's fine for me. |
Could you link me to that package? I would love to see how they made the xplained mini present as such in the menus. The problem is that -b{upload.speed} is being generated at all. It shouldn't be in your working command either, it's just getting ignored because it's irrelevant to non-serial ports. I think it's using the upload via a bootloader recipe to create that command, rather than the no bootloader please upload using a programmer recipe like it's supposed to be using... and of course there is no upload.speed if it's not uploading over a serial port; the programmer devices from Microchip are composite USB devices that present as a serial port and a programmer. The programmer is what it should be using for non-bootloader board selections. |
The Atmel 328p Xplained package was this one. Present in the default board manager Github link to their webpage As soon as install it, I get the name of the 328P Xplained mini behind my COM3. It must be the name in their boards.txt file, because if I change that name I get this. In their boards.txt changed this I would be careful with copying their idea, as it is flawed in my case. The name from a different core's boards.txt get's activated, while I am selecting a board from another core. Maybe it has to do that I am working with a:
|
Because you said "It should be using the programmer of the composite USB device" I tried "upload using programmer" It fails with a different JTAG error after connecting successfully and after that I have to power-cycle or It fails to connect to the programmer completely.
Second attempt (before power-cycle fails even earlier in the upload process
|
inconsistent fragment number error - that is either the same error, or the reverse of the error (the 0 and 1 swapped) that you would get trying to upload to a Dx via a pre-Dx *EDBG. I will investigate what is up with the boards.txt for those boards. I would suggest making sure there wasn't a required firmware update for the on-board debugger. That would be consistent with the Microchip MO (which at times has appeared to be "move slow and break stuff". I have two snap programmers that I wasted three days trying to make work with microchip studio before giving up. ) |
I'm sure that would mean something to a Microchip Support employee. I suggest you ask one of them. You got WAY farther with microchiop studio and an official programmer than I ever did. I was never able to make microchip studio detect that I had a programmer connected at all with days of work. You've managed to detect it and read out the firmware version! I'm a certified incompetent at making Microchip's programming tools work. Like I said, I could never make any of the programming tools from microchip except curiosity nanos work. After the snap debacle though, it wa hard to motivate myself to work. Why waste more time farting around to get a slower programmer to work on an IDE I detest? Unless you're a dark sorcerer who can do hardware debugging. And if you can do that, wtf are you asking me questions for? I should be asking you questions in that case. |
Well, this was more like a monkey pressing some buttons and reading what I saw on the screen. |
Well, at least when you pressed buttons on the IDE, you got a banana.... I couldn't even pull off that. (IE, as a monkey, you're outperforming me) USB to me is a dark art. See that's why I'm starting on mTC instead of dXC ;-) |
IDE: 1.8.13
mTC: Github version
Board: Xplained Mini ATtiny817
Windows 11 64bit
I think I saw a similar issue here for the Attiny1604
When I want to upload something to the Xplained via the Atmega32U4 the below command line gets generated for Avrdude and fails because
-b{upload.speed}
does not get parsed in a real baudrate.When I change it to 115200 as per the other issue, the error goes away. Unfortunately only to be replaced by another error, but that may be caused by me as I first changed the USB drivers with Zadig in my attempts to make the first error go away.
so this:
E:\Arduino\arduino-1.8.13-megatinycore\hardware\tools\avr/bin/avrdude -CE:\Arduino\arduino-1.8.13-megatinycore\portable\sketchbook\hardware\megaTinyCore\megaavr/avrdude.conf -v -pattiny817 -cxplainedmini_updi -Pusb -PCOM6 -b115200 -Uflash:w:C:\Users\Hans\AppData\Local\Temp\arduino_build_360913/Blink.ino.hex:i
then results into this error
[EDIT] found a workaround
Ok, I deleted all the USB drivers and let windows install them again and then I just tried something.... and that worked.
When I change
-Pusb -PCOM9
into-PusbCOM9
and change{upload.speed}
into115200
The sketch get's uploaded
The text was updated successfully, but these errors were encountered: