Bootloader slow to start up

Development Tools Uploading
1

Hi,

I have run into a peculiar problem on my custom boards and I was hoping someone had some insight to what is going on.

My setup is this:

I have a custom board using an ATmega328p with standard bootloader (the one that Arduino IDE gives). I'm using a USB FTDI cable to upload my application to the board through the bootloader. The board controls a device that needs to be very power efficient, so at sometimes the application turns off the MCU (the hardware is designed for this). The MCU is then again awoken by pressing a button, that will re-power the MCU.

Naturally, I want my application to be as responsive as possible and thus running very soon after the MCU has been powered up. At the same time I need the bootloader to be present as I will need trained operators to upload updates without having to use a programmer.

With the ATmega328p, and the FTDI cable disconnected, the boot time (time before my application runs) is ~50ms (well within target time). All is good
If I connect the FTDI cable to my PC and the board, all is still good. However if I connect the FTDI cable to the board but NOT to my PC (leaving the USB end out). The boot time is ~2 seconds!!

In production this is not a problem as no FTDI cable are connected so I have shrugged my shoulders so far and ignored this.

But alas, due to the scarcity of ATmega328p, I have been forced to change to the new ATmega328pb. But with this MCU, the ~2 seconds boot time seems to happen even with the cable completely out, which renders the device useless.

I have done a lot of tests and it seems to be a bootloader communication issue, where it "thinks" it needs to talk to something in the other end, and has to wait for a timeout to happen (~2 seconds).

If I connect the FTDI cable to both board and PC (and thus power the board from the FTDI cable), it boots in the expected 50ms, but this is the only way I can obtain the fast boot time.

I have tried stock bootloader and Minicore bootloader, but they both do this on the 328pb. On the 328p it is no problem...

Does anyone have any insight into what the bootloader is trying to communicate with and how I can get around it when no cable is connected and the UART?

I know this was a long one, but I'm practically bald from pulling my hair from this. Any suggestions are appreciated :slight_smile:

2

I don't have an answer as to why it's happening. But you can consider to remove the bootloader completely; code upload via ICSP.

3

Thank you for your reply. I already tried with a programmer and no bootloader. Then everything is good.

Unfortunately, it is no help as I do need bootloader functionality though.

4

The bootloader will try to detect the "reset cause" and only enter the bootloader (which times out in ~2s and starts the sketch) if the reset cause was "external reset." In particular, if the reset cause is "power on reset", the sketch should start immediately.

The thing is, I've seen chips come up from power-on with the "external reset" cause set; I think it depends on the exact circuitry of the power supply and whatever is connected to the RESET pin.

Try running the Optiboot Reset Cause Example program while monitoring the Serial port, and see what it thinks is happening...

(also, do you have any non-standard things connected to RESET, like a capacitor?)

5

Thank you for your reply, Bill, it is much appreciated. I will try "reset cause" example next week. Also, I will inquire about the RESET pin and it's electrical connection from the HW designer. Stay tuned :slight_smile:

Can you elaborate on what the bootloader is waiting for during the ~2 seconds delay before starting the sketch? I'm trying to understand the bootloader in order to be able to get around this.

What it looks like to me is that the bootloader tries to initiate some stk500 communication with the host, if it detects the cable is present. This explains the delay when the cable is not connected to the PC as there is "noone" in the other end. If the cable IS connected to the PC, there is no delay at all. My theory on this is that the USB somehow makes the bootloader understand that there is no point in waiting and thus the startup is instant.

Again, the actual problem is that the 328pb has this delay even with no cable connected, as opposed to the 328p, that seems to detect that the cable is not connected and thus skips the delay

6

It's looking for Serial traffic that is trying to upload a new sketch. There's 3 quick LED blinks, and a 1s Watchdog timeout that occurs if no appropriate traffic is seen.
More info (and the full source code) is available in the Optiboot Wiki.

Edit: add:

What it looks like to me is that the bootloader tries to initiate some stk500 communication with the host, if it detects the cable is present.

Nah. First of all, the bootloader does not attempt to "detect a cable." That might be almost possible, but there isn't really room to add the code. Second, the bootloader is intentionally completely silent until it receives stk500-like commands from the uart, so that it won't interfere with some other serial device that might have been connected.

7

Just following up on this in case anyone else has similar issues.

The problem was that the HW designer used the external reset PIN for some custom brown out detection. Hence external reset PIN got activated during every power up. As per the Optiboot Wiki (many thx to westfw), this will cause the bootloader to wait for STK500 commands on the serial line for 1 second. If nothing is received it will transfer control to the loaded application. This is only happening with the external reset, not with any of the other 3 reset types.

So for anyone wondering: If you want the bootloader to transfer control to your application as fast as possible, do not trigger the external reset hardware wise.

Bill, I cannot thank you enough. Your insight and helpfulness exceeded all expectations :slight_smile:

8

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