Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How long does the reset-Pin triggered? #560

Open
Albert245 opened this issue Dec 27, 2022 · 3 comments
Open

How long does the reset-Pin triggered? #560

Albert245 opened this issue Dec 27, 2022 · 3 comments

Comments

@Albert245
Copy link

Hi, I'm wonder how long does the reset-Pin triggered to jump in the programming session of the bootloader. I've tried 1ms and start sending Cmd-get-Sync (0x30 0x20) but seem like it doesn't jump in the flash session. I'm I missing something ?

I've stuck with this problem for a while

Sorry for post this issue here but I hope someone can guild me about how to jump in flashing-mode via UART like esp-link. I want to make one esp-link on my own.

@JDP-Maker
Copy link

Looks like 2ms, it was simply to find in the code. If you really want to code your own, you should learn how to search, and understand others code.

serbridgeReset()
{
if (mcu_reset_pin >= 0) {
#ifdef SERBR_DBG
os_printf("MCU reset gpio%d\n", mcu_reset_pin);
#endif
GPIO_OUTPUT_SET(mcu_reset_pin, 0);
os_delay_us(2000L); // esp8266 needs at least 1ms reset pulse, it seems...
GPIO_DIS_OUTPUT(mcu_reset_pin);
}
#ifdef SERBR_DBG
else { os_printf("MCU reset: no pin\n"); }
#endif
}

@Albert245
Copy link
Author

I've known for a while that the Lock bit is the problem.

Naturally, I examined the code and tested it, as well as the code for the bootloader. Just curious about why it doesn't jump into the UART programming session.

It may function even with 1 ms or less of trigger time. Make sure the Atmega has a bootloader and that the lock bit didn't go wrong.

The lock bit may be set during bootloader burning and removed if an SPI programmer is used.

Read others code is not the way to solve the problem, must know why they did that.

@JDP-Maker
Copy link

The timing for the bootloader to be ready to acknowledge sync after reboot, I suspect is different for each board. The approach seems to be, start sending sync immediately after reboot and REPEAT until sync reply or to a count of 10 tries and then fail. The same thing happens happens with boards directly connected to usb. Arduino IDE tries 10 times. There is some delay between repeated sync attempts I would guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants