Open MCUdude opened 1 month ago
Have you checked whether the m640 actually externalises the pins for USART2/3? Newer ATDFs might have removed the USART2/3 seeing that the corresponding pins don't exist? The .hex generation is pretty much data driven from the ATDF description...
I find lots of traces of USART2 and USART3 in the latest ATDF files for the 640/1280/2560:
Fom Microchip.ATmega_DFP.3.2.269.atpack
:
<module name="USART">
<instance name="USART0" caption="USART">
<register-group name="USART0" name-in-module="USART0" offset="0x00" address-space="data" caption="USART"/>
<signals>
<signal group="TXD" function="default" pad="PE1"/>
<signal group="RXD" function="default" pad="PE0"/>
<signal group="XCK" function="default" pad="PE2"/>
</signals>
</instance>
<instance name="USART1" caption="USART">
<register-group name="USART1" name-in-module="USART1" offset="0x00" address-space="data" caption="USART"/>
<signals>
<signal group="TXD" function="default" pad="PD3"/>
<signal group="RXD" function="default" pad="PD2"/>
<signal group="XCK" function="default" pad="PD5"/>
</signals>
</instance>
<instance name="USART2" caption="USART">
<register-group name="USART2" name-in-module="USART2" offset="0x00" address-space="data" caption="USART"/>
<signals>
<signal group="XCK" pad="PH2" function="default"/>
<signal group="TXD" pad="PH1" function="default"/>
<signal group="RXD" pad="PH0" function="default"/>
</signals>
</instance>
<instance name="USART3" caption="USART">
<register-group name="USART3" name-in-module="USART3" offset="0x00" address-space="data" caption="USART"/>
<signals>
<signal group="XCK" pad="PJ2" function="default"/>
<signal group="TXD" pad="PJ1" function="default"/>
<signal group="RXD" pad="PJ0" function="default"/>
</signals>
</instance>
</module>
``
USART2/3 reside on ports H and J, which are not suitable for either autobaud or software I/O. The latter is normally used for internal oscillators as SW I/O typically has a lower quantisation error than HW I/O, and thus compensates for the notoriously bad individual deviation that internal oscillators exhibit.
Ports H and J cannot be used for urboot SW I/O as these routines use bit-addressable opcodes (eg, sbic) for which the port needs to reside in low I/O memory.
However, all this would always have been the case, and there should not be a difference between urboot 7.7 and 8.0.
There is a difference between the 7.7 and 8.0 files, for external oscillator options as well.
In this 7.7 folder, there are bootloader options for all four UARTs: https://github.com/stefanrueger/urboot.hex/tree/main/u7.7/cores/megacore/atmega2560/watchdog_1_s/external_oscillator/16000000_hz/1000000_baud
However, on the same 8.0 path, UART2 and UART3 are missing: https://github.com/stefanrueger/urboot.hex/tree/main/cores/megacore/atmega2560/watchdog_1_s/external_oscillator/16000000_hz/1000000_baud
Interesting find. Are there many of these examples? I am hoping this is limited to some edge cases.
There is not much I can currently do; away with just a phone...
I've updated most of my cores, and I've only seen this on ATmega640/1280/2560. The 324PB has three serial ports, and there are pre-compiled bootloaders for all three.
I'm working on migrating from Urboot v7.7 to v8.0, and I just realized that for MegaCore, there are very few pre-compiled binaries for the ATmega640/1280/2560 for UART2 and UART3.
See here as an example. This bootloader option previously contained bootloaders for UART2 and UART3 as well.
https://github.com/stefanrueger/urboot.hex/tree/main/cores/megacore/atmega640/watchdog_1_s/internal_oscillator/8000000_hz/38400_baud
Any idea why these are missing when they were there in v7.7?