Replies: 6 comments 7 replies
-
|
Are you using the github version? I think I introduced a bug while working on something else. |
Beta Was this translation helpful? Give feedback.
-
|
No, I'm using the one from Arduino Boards Manager (1.5.8) |
Beta Was this translation helpful? Give feedback.
-
|
looks like the timeout was on the edge of working; I'd already noticed the issue on mTC and changed it there but not here. You get callback errors instead of a message saying it got no response back because I don't know how to do that, all I know how to do is attempt to index the response and watch it blow up. I don't know how to work with errors properly in python to handle them more gracefully. Hell, I don't know how to handle errors gracefully in ANY language, since here in AVRland we run with -fno-exceptions.
This is a nonsense error and I have been trying to figure out where it came up with that that outrageous pants-on-fire lie (it's stuff we inherited from microchip's pymcuprog). Obviously the port exists, and obviously a board is connected to it because we just read out the NVM programming version, the on chip debugging version, the frequency of the PDI oscillator, and the die rev and an internal die ID from it, at minimum. Now if either of the claims of that error were true - then where did that info come from? Did I miss a product release announcement for a Ouija board on a chip or something? That triggered the callstack dump. but then for reasons I don't understand it is followed with that garbage line I just noticed that the method I ported over is not rigorous enough, and am working on what I hope will be sufficient
|
Beta Was this translation helpful? Give feedback.
-
|
I love reading your replies! I should collect them in a book! :-D |
Beta Was this translation helpful? Give feedback.
-
|
Well, I don't think it was actually doing the timeout check loop correctly, period. Full stop. It looks like it would start the first passage through the loop 2 usb latency cycles later I think. The only thing that doesn't add up is that shouldn't be long enough. I know they usually highball the write delays, but not by that much - the datasheet "typical" of 70us for a word write is usually more like 60us. but 2 USB latency cycles is 4ms on a CH340, and it is supposed to take 11ms for a chip erase.....1/7th better than expected seems reasonable. 7/11ths better is implausible. So I still don't fully understand that, I'm not a good python programme - I missed CS201, Constrictor Snakes and Software Development To my profound dismay, searching the entire DxCore directory turned indicates that "the selected serial port does not exist or your board is not connected" isn't in there. (and searches for things like "your board") does not turn up any results either. You know what that means: that garbage is coming from the IDE, and Somehow we're causing the IDE to print that message, and as you can see when it tries to print the port name, it's instead printing Most likely, that variable is supposed to contain the name of the port, not a debug string. |
Beta Was this translation helpful? Give feedback.
-
|
Before I horribly mess up my Arduino environment (1.8.19 Win64): since I already have 1.5.8 (from Boards Manager) installed, is there a safe way to install the Github version instead (that is, without having to offer flesh sacrifices to some divinity and without screwing up badly everything)? |
Beta Was this translation helpful? Give feedback.
-
|
First off - Blood sacrifices to the dark gods are mandatory regardless of what embedded development tasks you are hope to achieve. (and it's blood sacrifice, not flesh sacrifice. "Blood is the currency of the spirit world", not flesh. (attributed to the esteemed count in his discourse with B. Stoker, one of the best known researchers in the field of )). So you're going to want to leave the altar and it's paraphenalia set up - yeah, i know it's kidna bulky, but it's one of the most important Unpack .zip package into a new location in someplace like the root of C, so you won't encounter windows permissions treating the directory wierd. Open that directory and create a folder inside called "portable". Open the IDE from that location (you now have two completely separate copies that are unaware of eachother. Then close it. You'll see that a bunch of shit was created inside portable. Then either: Or Instead of reopening and installing via board manager, do the full manual install. First update the default toolchain - open the board manager json file URL in browser, Search for Azduino7, and hit next until you get the the one place with several instaces of that string in rapid succession, each associated with a platform and a URL. Download and extract archive from this location (suggest to use the platform that matches your computer, else nothing will work). Being careful that you're not putting the directory one layer too deep or not deep enough, open arduiinodir/Hardware/Tools/avr (the result is impossible to unpick if you mess up, because there are multiple folders in that tangled mess with the same name. Like theres's avr/bin, avr/avr/bin, avr/include and avr/avr/include). You will replace thousands of files. Do so. Open the IDE and verify that you can compile blink for some Now open portable/sketchbook, create a folder named hardware in there, and sync the repo into that folder. Finally, you need to open that folder, navigate to megaavr/tools/ManualPython.md open in text editor and follow the instructions there to get the python package we use. Either way, you pick one path, and you stay the hell on it. Thou shalt not use board manager on any installation with an updated default toolchain. Thou shalt not install any cores but mTC, DxC, and ATTC 2.0.0-dev on this portable version (there are no concerns with libraries, just hardware packages). When there are new ATpacks, and there's an Azduino8, you can do the same thing to update the toolchain to that. We do not forsee a need to update the python package in the near future. That's the setup I use for core development, except for compiling bootloaders. Bootloader binaries are a rather different animal, but it can be done similar steps, actually, - in some ways - but different IDE version and you delete almost all but one branch of the directory tree. |
Beta Was this translation helpful? Give feedback.
-
|
WHOA! Not for the faint of heart... |
Beta Was this translation helpful? Give feedback.
-
|
Well, I dunno about a release. I found ways around this, cheap tricks, to make the AVR toolchain packages (do you think I ship any of the binaries I compiled? No way, they don't work! I use the ones from the last Arduino one, 3 years ago!), and I can only build for x64 linux anyway. Actually, I think the compiler works - it's the linker that's dead as a doornaill.That must be the case, since the build process precompiles a metric shitton of .o files that are used to make the compile time less of a nuisance - this is more than half of the compiler package size - 165 MB, about 6mb per part family that has it's own set of .a files. Oh, and maybe use the Azduino6 toolchain package and don't try to compile for Ex (it doesn't work anyway). Just realized the windows version is hosed :-/ Again. Same story as always, avr/subdirs vs avr/avr/subdirs. I just can't seem to get it right. But in any event, i'd like to see that I made #463 better before I move forward with a release. |
Beta Was this translation helpful? Give feedback.
-
|
Actually no, Azduino7 is fine. I was thrown off while checking directory stats on it. |
Beta Was this translation helpful? Give feedback.
-
|
Hello Spence, I did as instructed, but the new prog.py throws a syntax error: Update: fixing the .py (args.action == "read"), the upload went FINE by using a CH340. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, not even the updated prog.py works with the other USB-Serial cable: |
Beta Was this translation helpful? Give feedback.
-
|
@SpenceKonde should I convert this into an issue? |
Beta Was this translation helpful? Give feedback.
-
Hello,
after some time (about 1 year) I digged out my AVR128DB28 to do some testing, updated DxCore and... failed to upload a sketch.
OS: Windows 10 64 bit latest updates
IDE: Arduino 1.8.19
DxCore: 1.5.8 (updated from Boards Manager)
Serial-USB cable: CP2104 (works OK with ATTiny3224 and latest megaTinyCore)
Selected programmer: SerialUPDI (tried both "SLOW 57600" and 230400)
Problem:
I re-checked all wiring with my multimeter and everything seems fine; I had the test board stored away in a box and worked like a charm 1 year ago.
I know it could still have failed, maybe I will have to redo the board, but I cannot understand this part:
Pinging device...
pymcuprog.programmer - INFO - Reading device ID...
pymcuprog.serialupdi.application - INFO - SIB: 'AVR P:2D:1-3M2 (A5.KV00D.0)'
pymcuprog.serialupdi.application - INFO - Device family ID: 'AVR'
pymcuprog.serialupdi.application - INFO - NVM interface: 'P:2'
pymcuprog.serialupdi.application - INFO - Debug interface: 'D:1'
pymcuprog.serialupdi.application - INFO - PDI oscillator: '3M2'
pymcuprog.serialupdi.application - INFO - Extra info: '(A5.KV00D.0)'
Doesn't it mean it was able to communicate with the MCU?
Best,
Fernando
Beta Was this translation helpful? Give feedback.
All reactions