Urboot with extended WDT delay?

Development Tools Uploading
1

In this conversation about programming Pro Mini AtMega328P 16MHz on Arduino IDE without DRT (use of RST button press and release upon start of download) @stefanrueger mentions the possibility to use urboot bootloader with a 1 or with a 2 second WDT.

I assume that this WDT time is the timewindow for releasing the RST button after the Arduino IDE indicates compilation is ready and download will start?

McDude's Minicore uses the standard urboot bootloader but that only allows for a 200ms window within which to release the RST button.

But since he has no plans to incorporate urboot versions with 1 or more seconds of WDT I intend on doing this myself.

Now when looking at the various options - for atmega328P - in the urboot Github, and reducing the choice to what @stefanrueger indicates as a possibility ( urboot_atmega328p_pr_ee_ce.hex ) in his post #16 in the above Arduino Forum topic, I find six alternatives:
urboot_atmega328p.hex
urboot_atmega328p_pr.hex
urboot_atmega328p_pr_ce.hex
urboot_atmega328p_pr_ee.hex
urboot_atmega328p_pr_ee_ce.hex
urboot_atmega328p_ee_ce_hw.hex

What is the difference between these? And where is the processor speed being specified?

Or to make it tangible: what urboot bootloader(s) should best be used for an atmega328P externally clocked at 16MHz, that give a RST-button release timewindow of at least one second?

2

It is described here:

https://github.com/stefanrueger/urboot.hex/tree/main/cores/minicore/atmega328p/watchdog_1_s/autobaud/uart0_rxd0_txd1/led%2Bb5#:~:text=feature%20not%20present-,Hex%20file,-%3A%20often%20qualified

  • Hex file: often qualified by the MCU name and/or configuration
    • pr vector bootloader protecting the reset vector
    • ee bootloader supports EEPROM read/write
    • ce bootloader provides a chip erase command
    • hw hardware supported bootloader: set fuses to jump to the HW boot section, not to addr 0

I believe the bootloader's "autobaud" feature allows it to work with any speed.

1 Like
3

@ptillisch thank oyu! Exactly what I looked for.

Now this: urboot gives the option to use WDT time as 1 or 2 seconds. Such as here for the atmega328P. Does this WDT refer to the timewindow for releasing the reset button on the Pro Mini?

And secondly: I program bootloaders using USBtiny as a programmer and AVRDUDESS as GUI. What are the Arduino IDE possibilities to program a sketch when the atmega328P has an urboot bootloader? Besides using MCdude's Minicore..

4

Yes. The bootloader is activated by resetting the microcontroller. After being activated, the bootloader runs for a short time, waiting for the computer to start an upload. If an upload doesn't start in that time, the bootloader exits and the sketch program starts running.

The bootloader must be activated when the upload process starts. So you must time the reset close to the time when the upload process starts.

I don't know. Maybe one of the other forum helpers can provide an answer.

Is there a reason why you don't want to use the excellent MiniCore?

1 Like
5

@ptillisch I do have Minicore installed, but with version 3 comes the change from Optiboot to urboot. I use the RST button on Pro Mini and discovered that with Minicore the WDT window had narrowed to 200ms. In this thread @westfw told us he raised an issue with MCUdude's Minicore to request for a larger WDT. MCUdude declined because of the large number of extra bootloader versions required.

So I reverted back to a pre-3.0 Minicore version (Optiboot) for the time being.

Now I am looking for a way to use Minicore v3.0 but that make use of urboot bootloaders for atmega328p with pre-compiled versions for WDT = 1 or 2 seconds.

What would be the best way forward?

6

I would look for the 2 second bootloader version that you need in the URBOOT repository and burn that hexfile to your processor. But that's what Stefan recommended already to you about a year ago

So is this a different problem?

1 Like
7

@hmeijdam thank you for your reply Hans, to be honest it is the same issue except that I had not delved further into the subject until a week ago, I am sorry for that!

If I understand correctly I can open a .txt file, look up in the urboot.hex repository for the file I want to use (WDT=2s), open that folder and copy the hex contents in the .txt file and save it as .hex,

..and then burn it with (in my case) USBtiny programmer.

And then this controller can be programmed using MiniCore v3.0 (with a RST button press-and-release)?

8

Yes, that's the idea. Minicore will not replace the special bootloader you put on it as long as you upload via serial and not via your USBtiny ISP.

Not all bootloader are the same size, though I assume the WDT time variation makes no size difference. So when you see the IDE calculating the space available for your program that may differ a few bytes from what you actually have if the bootloader size is different.
Maybe that someone with more knowledge about bootloaders can comment on that, but the fact that Stefan recommended this approach, makes me believe it won't be a problem.

1 Like
9

@hmeijdam thanks Hans, I will keep you posted in this thread. The next week I will be doing trials.

10

Presumably, you could also make a small Makefile change and compile your own copy of urboot with an up-to 8s timeout.

If you want to use "burn bootloader" instead of messing around with a CLI programmer, just figure out which .hex file it is "burning" (via the verbose log) and replace that with the one you want.

1 Like
11

@westfw great help, thanks! Your second idea I think I can implement, I will try that out the coming days and let you know here.
Your first idea (makefile): I never did that, can you point me to a "how-to" page (url?) please?

12

Hmm. It looks like urboot is trickier to compile yourself than many projects, so perhaps it's not such a great idea. (the urboot repository says stuff like "use a linux system with perl and a somewhat older version of avr-gcc installed.")

13

@westfw ah ok, thanks for letting me know. The I will use a WDT = 2s precompiled bootloader in the urboot.hex repository.
Is it true that i can copy the hex content in any of these procompiled files, paste it in a .txt file an save as .hex?

14

Yes. the .hex format is pure text (from an age when that was all you could count on being able to move from one system to another.)

I'm not sure why you would want to do that, rather than just copying/renaming the file, though...

15

I am sorry, you are right, I forgot your earlier advice:
"If you want to use "burn bootloader" instead of messing around with a CLI programmer, just figure out which .hex file it is "burning" (via the verbose log) and replace that with the one you want.".

16

I replaced the urboot bootloader file originally used by MiniCore (v3.0.2) during "Burn bootloader" (which uses the watchdog_1_s) by the same urboot from the urboot wachdog_2_s folder.
This is the line from the verbose Burn Bootloader showing where MiniCore gets its bootloader:

avrdude: reading input file C:\Users\xxxyyy\AppData\Local\Arduino15\packages\MiniCore\hardware\avr\3.0.2/bootloaders/urboot/atmega328p/watchdog_1_s/autobaud/uart0_rxd0_txd1/led+b5/urboot_atmega328p_pr_ee_ce.hex for flash

However when attempting to download a sketch using the RST button on the Pro Mini I still have barely the time to release the button right after compiling is finished and when download must start.

Still not as with the Optiboot or with the original old Pro Mini bootloader where there is at least a one second window to release the RST Pro Mini button after compile is finished and download must start.

What does the WDT 1 or 2 second refer to? Is that really this timewindow for the timely release of the RST button?

17

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.