Inquiry on UART-Based Bootloader Development for ADuC7061

Hi Karl,

Thanks for pointing me to AN-724, it was very helpful.

I’d like to clarify my understanding and make sure I’m interpreting the capabilities correctly for a real product use case.

From AN-724, it seems that the ADuC7061’s built-in serial download (ROM loader) can load firmware over UART, but it requires the device to enter serial download mode by pulling the BM pin low during reset or power-up.

My questions:

1. Is it correct that the built-in UART downloader cannot be invoked purely by software (e.g., via a command from a running application), and always requires BM + reset?

2. In a typical product where BM and RESET pins are not accessible to the end user, is the recommended approach to:
 - implement a custom bootloader in flash, and
 - use the UART protocol defined in AN-724 (or a custom protocol) to update firmware?

3. Is there any documented or recommended method to:
 - trigger entry into the ROM loader from firmware (e.g., via watchdog/reset tricks or special registers), or
 - is hardware control of BM during reset strictly required?

4. For production systems that support field firmware updates over UART (via USB-to-UART converters), what is the recommended architecture from ADI’s perspective?
 - Use the ROM loader with external hardware control of BM/RESET?
 - Or implement a custom bootloader?

5. Are there any example projects or reference designs (even for other ADuC70xx devices) that demonstrate a customer-facing firmware update mechanism?

I just want to make sure I choose the right approach early; especially since our end users will not have physical access to BM/RESET pins.

Thanks again for your guidance.

Hi Karl,

Thanks for pointing me to AN-724, it was very helpful.

I’d like to clarify my understanding and make sure I’m interpreting the capabilities correctly for a real product use case.

From AN-724, it seems that the ADuC7061’s built-in serial download (ROM loader) can load firmware over UART, but it requires the device to enter serial download mode by pulling the BM pin low during reset or power-up.

My questions:

1. Is it correct that the built-in UART downloader cannot be invoked purely by software (e.g., via a command from a running application), and always requires BM + reset?

2. In a typical product where BM and RESET pins are not accessible to the end user, is the recommended approach to:
 - implement a custom bootloader in flash, and
 - use the UART protocol defined in AN-724 (or a custom protocol) to update firmware?

3. Is there any documented or recommended method to:
 - trigger entry into the ROM loader from firmware (e.g., via watchdog/reset tricks or special registers), or
 - is hardware control of BM during reset strictly required?

4. For production systems that support field firmware updates over UART (via USB-to-UART converters), what is the recommended architecture from ADI’s perspective?
 - Use the ROM loader with external hardware control of BM/RESET?
 - Or implement a custom bootloader?

5. Are there any example projects or reference designs (even for other ADuC70xx devices) that demonstrate a customer-facing firmware update mechanism?

I just want to make sure I choose the right approach early; especially since our end users will not have physical access to BM/RESET pins.

Thanks again for your guidance.

Response to Question 1: Yes, the serial download protocol would require the BM + reset.

Response to Question 2-5: 

It's possible to implement In-Application Programming (IAP), if the BM and reset pins are not accessible.
Please refer to link: Implementing In-Application Programming on the ADuC702x | Analog Devices

The link is referencing ADuC702x, but ADuC7060 should still work.
There is also an example at the end of the page.
Take note that flash of ADuC7060 is smaller than ADuC7020.

If the JTAG pins are exposed, this is another possible approach.

Thank you, Karl, for sharing the information. I was able to develop a custom IAP along with a Python GUI to load the firmware. I appreciate your support.

I'm glad I was able to help.

Regards,

Karl