urboot or a new bootloader for modern UPDI parts

[mcuee]

From @askn37

• issue #1600 Bootloader enhancements #1614 (comment)

The problem is that using the urboot protocol doesn't seem to take advantage of the performance of the hardware you have. In particular, we do not believe that the following hardware UART features will be supported:

• Full hardware automatic baud rate adjustment feature uses 0x55 for the sync character. The UPDI protocol is actually implemented based on this.
  • As a side note, TPI/PDI/UPDI can share the same UART frame 8E2, except for the synchronization method and the presence or absence of the CLK pin. Not SPI based.
• By expanding the frame to 9 bits, multi-CPU communication function of up to 256 nodes can be used. This is probably a required feature for ISO 26262 compliance. Unfortunately, there are no known implementations of this open source protocol, but it may already be popular in the automotive industry. (Like UPDI-OCD and QT-Touch, as a private specification)

My personal challenge will ultimately involve designing a new open source protocol. This effort is very important, but if AVR-DU can be used as expected (protocol conversion from AVRISP/JTAGmkII becomes easier, etc.), the difficulty will be significantly reduced. We're still halfway through.

[mcuee]

@askn37

Just wondering why you think the Full hardware automatic baud rate adjustment feature uses 0x55 for the sync character can not be implemented in urboot protocol? And why expanding the frame to 9 bits will be a challenge?

@stefanrueger

Maybe you can provide your inputs as well. Thanks.

[mcuee]

@askn37

This is probably a required feature for ISO 26262 compliance. Unfortunately, there are no known implementations of this open source protocol, but it may already be popular in the automotive industry. (Like UPDI-OCD and QT-Touch, as a private specification).

Maybe you can explain a bit more here. I am not in the Automotive industry so I do not know much about ISO 26262. But I know quite a bit of general IEC61508 Function Safety from my day job (mainly on the HW side but also a bit on the firmware side).

[askn37]

Just wondering why you think the Full hardware automatic baud rate adjustment feature uses 0x55 for the sync character can not be implemented in urboot protocol? And why expanding the frame to 9 bits will be a challenge?

I don't know much about the urboot protocol. But I can guess that he is first using his GET_SYNC (0x10) as a sync character and sending it at several different baud rates to check the bootloader's response.

Hardware-based baud rate adjustment using 0x55 characters counts his LOW-HIGH at least 4 times (6 times depending on configuration) based on the CPU clock and dynamically sets the frequency generator with the result. If the measured frequency is within the supported range, one character completes the synchronization. Simple, right? Furthermore, by applying this to the beginning of each packet, speed changes and errors due to temperature can be actively absorbed. Therefore, these designs are mutually exclusive at the hardware level.

Would it be practical to add a boot option to urboot to differentiate between the two? These are independent of his SPI-derived 4-byte instruction system and since his memory map is different, subsequent communication are also different. Don't expect too much source code sharing. This also applies when extending new memory types such as BOOTROW.

9-bit frames can easily coexist with things like 8N2 and 8E2. The 9th bit is just a flag to distinguish between data and address, but it is easy to ignore it as a STOP bit or replace it with parity. Large also serves as small. However, using 8N1 as a base is difficult because different frame lengths coexist. In this respect as well, the value of forcibly integrating the two is questionable.

[stefanrueger]

using his GET_SYNC (0x10) as a sync character and sending it at several different baud rates

AVRDUDE sends 0x30 as first character; the urboot autobaud bootloaders know they expect 0x30 as first character which are 5 zeros (start bit and the 4 lsb of 0x30, note UARTs send the lsb first), measures the time it takes for the first zero rx period and computes the baud divisor from these (classic parts). Could do something similar for UART comms of modern parts.