From feb340d1dc051f3dad7b8402ca1fcf3d2def6f4f Mon Sep 17 00:00:00 2001 From: Spence Konde Date: Wed, 19 Jan 2022 01:54:07 -0500 Subject: [PATCH] Fix critical bug impacting non-windows platforms with non-SerialUPDI programmers https://github.com/SpenceKonde/megaTinyCore/discussions/620 --- ChangeLog.md | 6 ++++++ megaavr/platform.txt | 4 ++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/ChangeLog.md b/ChangeLog.md index 06704ba2..da531dfd 100644 --- a/ChangeLog.md +++ b/ChangeLog.md @@ -8,6 +8,12 @@ Changes listed here are checked in to GitHub ("master" branch unless specificall * Port enhanced documentation from DxCore. ## Released Versions + +### 2.5.8 +* Respond more gracefully when data that doesn't fit in Wire buffer is "written". +* CRITICAL BUGFIX - correct uploads through avrdude on non-windows platforms. +* Correct avrdude tool version to use version 17 of avrdude on 32-bit x86 linux. and version 18 everywhere else, instead of not installing on that platform because avrdude 18 isn't available for it. + ### 2.5.7 * Different (better) fix for the wire library issue fixed in 2.5.6, from @MX682X (#593), we no longer use the ring buffer, simplifying the code and saving flash * A bug in SerialUPDI which had been present since it's introduction but went unnoticed has been fixed. One of the last changes that went into Serial UPDI after almost all testing was done, was a "read chunking" option to work around an issue found in a serial adapter that was very flaky (it was a D11C programmed for serial adapter operation, with bugs). That particular buggy serial adapter however is used in the curiculum of a professor who had been driving the push to improve SerialUPDI, and getting uploads to work using that as a UPDI adapter was the entire reason for his and Quentin's involvement in this, so when we discovered that the issue was still there, -rc was added and we then confirmed that it could now upload and verify code successfully (note that the bug in the D11C serial firmware was corrected a few days later - there was a specific amount of data that when sent or received would crash it due to a bug in the USB library, which eventually was corrected) However, the standalone read functionality was not retested. Turns out it was TOTALLY BUSTED whether or not read chunks were requested. There were two issues here: First, the variable was called max_read_chunk in some places, and max_chunk_size in others. Second, when it finally filtered down to the read function, if read-chunk was specified, it only worked up to 256 bytes, because it would only ever use words if read-chunking was not requested, which imposed an unnecessary and incoherent limit, since not specifying it would use the maximum of 512b. diff --git a/megaavr/platform.txt b/megaavr/platform.txt index dce7829d..dd91ec0f 100644 --- a/megaavr/platform.txt +++ b/megaavr/platform.txt @@ -7,7 +7,7 @@ name=megaTinyCore versionnum.major=2 versionnum.minor=5 -versionnum.patch=7 +versionnum.patch=8 versionnum.postfix= versionnum.released=1 @@ -178,7 +178,7 @@ tools.avrdude.network_cmd={runtime.tools.arduinoOTA.path}/bin/arduinoOTA tools.avrdude.program.params.verbose=-v tools.avrdude.program.params.quiet=-q -q tools.avrdude.program.params.noverify=-V -tools.avrdude.program.pattern.windows={upload.prog_interlock}"{cmd.path}" "-C{config.path}" {program.verbose} {program.verify} -p{build.mcu}{upload.workaround} -c{protocol} {program.extra_params} "-Ufuse2:w:{bootloader.OSCCFG}:m" "-Ufuse6:w:{bootloader.SYSCFG1}:m" "-Ufuse8:w:{bootloader.BOOTEND}:m" "-Uflash:w:{build.path}/{build.project_name}.hex:i" +tools.avrdude.program.pattern={upload.prog_interlock}"{cmd.path}" "-C{config.path}" {program.verbose} {program.verify} -p{build.mcu}{upload.workaround} -c{protocol} {program.extra_params} "-Ufuse2:w:{bootloader.OSCCFG}:m" "-Ufuse6:w:{bootloader.SYSCFG1}:m" "-Ufuse8:w:{bootloader.BOOTEND}:m" "-Uflash:w:{build.path}/{build.project_name}.hex:i" ## Used for "upload" through bootloader tools.avrdude.upload.params.verbose=-v