fixes

Author: SpenceKonde

README.md

@@ -1,6 +1,6 @@
+# DxCore - Arduino support for the AVR DA, DB, and DD-series
 Use the Table of Contents button! Why was I making a ToC manually? (especially since I apparently did it wrong..)
 
-# DxCore - Arduino support for the AVR DA, DB, and DD-series
 
 This is an Arduino core to support the AVR DA, DB, DD, EA, EB, and DU-series microcontrollers from Microchip. These parts are the latest and highest spec 8-bit AVRs available, and take the AVR architecture to a whole new level with up to 128k flash, 16k SRAM, 55 I/O pins, 6 UART ports, 2 SPI and I2C ports, type A/B/D timers, and enhanced pin interrupts.
 

megaavr/cores/dxcore/core_devices.h

@@ -2355,7 +2355,7 @@ has once worked for the same thing as meaning that thing */
   #endif
 
   #if defined(__AVR_EA__) || defined(__AVR_EB__)
-    #define  ADC_MUXPOS_VDDDIV10_gc  ADC_MUXPOS_VDD10_gc // So I guess they're getting rid of excessive verbosity?
+    #define ADC_MUXPOS_VDDDIV10_gc  ADC_MUXPOS_VDD10_gc // So I guess they're getting rid of excessive verbosity?
     #define BOD_ACTIVE_ENWAKE_gc BOD_ACTIVE_ENABLEWAKE_gc
     #define BOD_SLEEP_ENABLED_gc BOD_SLEEP_ENABLE_gc
     #define BOD_SLEEP_SAMPLED_gc BOD_SLEEP_SAMPLE_gc

megaavr/cores/dxcore/timers.h

@@ -16,7 +16,7 @@
   #define MILLIS_USE_TIMERRTC
 #elif (defined(MILLIS_USE_TIMERA0) || defined(MILLIS_USE_TIMERA1))
   #define MILLIS_USE_TCA
-#elif (defined(MILLIS_USE_TIMERB0) || defined(MILLIS_USE_TIMERB1) || defined(MILLIS_USE_TIMERB2) || defined(MILLIS_USE_TIMERB3) || defined(MILLIS_USE_TIMERB4) || defined(MILLIS_USE_TIMERB5)) || defined(MILLIS_USE_TIMERB6)) || defined(MILLIS_USE_TIMERB7))
+#elif (defined(MILLIS_USE_TIMERB0) || defined(MILLIS_USE_TIMERB1) || defined(MILLIS_USE_TIMERB2) || defined(MILLIS_USE_TIMERB3) || defined(MILLIS_USE_TIMERB4) || defined(MILLIS_USE_TIMERB5) || defined(MILLIS_USE_TIMERB6) || defined(MILLIS_USE_TIMERB7))
   #define MILLIS_USE_TCB
 #else
   #warning "No millis timer selected, millis not disabled. Grabbing a timer. If seen outside of automated testing, report as bug immediately."
@@ -33,7 +33,7 @@
 #endif
 */
 
-#if (defined(MILLIS_USE_TIMERB0) || defined(MILLIS_USE_TIMERB1) || defined(MILLIS_USE_TIMERB2) || defined(MILLIS_USE_TIMERB3) || defined(MILLIS_USE_TIMERB4) || defined(MILLIS_USE_TIMERB5)) || defined(MILLIS_USE_TIMERB6)) || defined(MILLIS_USE_TIMERB7))
+#if (defined(MILLIS_USE_TIMERB0) || defined(MILLIS_USE_TIMERB1) || defined(MILLIS_USE_TIMERB2) || defined(MILLIS_USE_TIMERB3) || defined(MILLIS_USE_TIMERB4) || defined(MILLIS_USE_TIMERB5) || defined(MILLIS_USE_TIMERB6) || defined(MILLIS_USE_TIMERB7))
   #if (F_CPU == 1000000UL)
     #define TIME_TRACKING_TIMER_DIVIDER   (1)
     #define TIME_TRACKING_TIMER_PERIOD    ((F_CPU/500)-1)

megaavr/extras/Errata.md

@@ -127,7 +127,7 @@ Read-While-Write Feature Non-Functional
 
 Seems they've gotten most of the problems worked out, finally, other than the Dx-write endurance. 1000 rewrites is still enough though, and supposedly, the Dx-series parts meet the original (10k) spec at room temperature, just not over the whole temperature range (explaining why the problem had not been noticed for over a year)
 
-### Issues that we expected to see in errata, but have not yet seen:
+### Issues that we expected to see in errata, but have not yet seen
 
 #### The Vector Table was Wrong on very early AVR32DA, some of which escaped into the wild; these are not usable.
 Microchip recalled them, but some disties had already shipped some out.
@@ -165,7 +165,7 @@ Despite the datasheet saying otherwise *(and saying so very explicitly)*, the lo
 My only thought here is "If SPM instruction requires word aligned access, why not just require writes to be word addressed, and then you could forget about rampz except for the sole case of ELPM, and everone's life would be simpler". I would have no objection to losing ST/STS writes to the flash if it meant that I could take RAMPZ out of the equation while writing to the flash. Hell, imagine if ELPM assumed RAMPZ = 1 and LPM to assume RAMPZ = 0, and all the headaches caused by RAMPZ would be gone!
 
 ### UPDI programming issue with 16-bit STS after 24-bit STptr (Datasheet should be clarrified)
-On parts which use 24-bit addressing, 16-bit addressing should not be used for STS operations. The results are profoundly baffling - the long and short of it is: See the table in the UPDI chapter, titled `Figure xx-10: STS Instruction Operation`? Cross out the top two lines. If STptr has been used with a 24-bit pointer (which you normally do to write the flash), if a subsequent STS doesn't use the 24-bit address, it will use the high byte from ptr!
+On parts which use 24-bit addressing, 16-bit addressing should not be used for STS operations. The results are profoundly baffling - the long and short of it is: See the table in the UPDI chapter, titled `Figure xx-10: STS Instruction Operation`? Cross out the top two lines. If STptr has been used with a 24-bit pointer (which you normally do to write the flash), if a subsequent STS doesn't use the 24-bit address, it will use the high byte from ptr! This behavior is apparently intended and expected, but that isn't communicated to the reader of the datasheet.
 
 ## Errata and Datasheets
 Get the most up to date information from Microchip's website. They keep moving files around, so I'm just going to link their product pages.
@@ -217,4 +217,4 @@ This is once more listed on the AVR DD and EA-series headers, so it looks like t
 Finally, the USART had the two RS485 modes listed, like tinyAVR 0/1-series, instead of just the one. The second mode raised all sorts of questions about how the chip ought to behave - and was one of those terse-and-useless sections that answers little. If I correctly understand the intent - it was meant to listen to XDIR and only output data when XDIR was in the correct state. So what does it do when the pin transitioned to "no sending" state while it was in the middle of a byte? Is there any answer to that that will result in correct behavior in all applicable use-cases? I think they thought about that one, realized the answer was "probably not" after they re-read what they'd said about it in the datasheets of the parts that had been released a few times, and figured that they'd be better off not supporting that. It is unclear whether the feature is still present in the silicon. On the DA-series I suspect it is, and likely DB as well, as they don't appear to have touched the USART.
 
 ## Ex-series
-Much less interesting... only one thing that wasn't supposed to be there was apparently left in, a section of NVMCTRL that configures the EEPROM writes. Oddly, the initial silicon's NVMCTRL was badly broken.
+Much less interesting... only one thing that wasn't supposed to be there was apparently left in, a section of NVMCTRL that configures the EEPROM writes. Oddly, the initial silicon's NVMCTRL was badly broken - but the EEPROM worked fine, it was the flash that was busted.

megaavr/libraries/EEPROM/README.md

@@ -255,7 +255,7 @@ The return values on Dx/Ex are:
 In the event of errors, we clear the errors.
 
 If the low error bit is set, (indicative of a problem with the command used), in order to return the NVMCTRL module to a usable state, this function will, in addition to clearing the error flags, reset CTRLA to 0/NOOP/None
-#### Outputs, described differently:
+#### Outputs, described differently
 
 ##### tinyAVR
 ```text