avr/avrdude
2
0
Fork 0
mirror of https://github.com/mariusgreuel/avrdude.git synced 2025-09-28 15:05:27 +00:00
Code Issues Projects Releases Wiki Activity

Merge pull request #1139 from steelman/isp-clock-error-message

Browse Source 
Mention -B in the error message and document -F better
This commit is contained in:
Stefan Rueger
2022-10-23 21:59:21 +01:00
committed by GitHub
parent 4f6bab6303 c890ff90eb
commit 2c7083f001
3 changed files with 14 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
src/doc/avrdude.texi
View File

@@ -598,6 +598,8 @@ Also, for programmers like the Atmel STK500 and STK600 which can
adjust parameters local to the programming tool (independent of an
actual connection to a target controller), this option can be used
together with @option{-t} to continue in terminal mode.
Moreover, the option allows to continue despite failed initialization
of connection between a programmer and a target.
@item -i @var{delay}
For bitbang-type programmers, delay for approximately
@@ -3047,14 +3049,15 @@ See also: @url{http://www.libusb.org/ticket/6}
@item
Problem: after flashing a firmware that reduces the target's clock
speed (e.g. through the @code{CLKPR} register), further ISP connection
attempts fail.
attempts fail. Or a programmer cannot initialize communication with
a brand new chip.
Solution: Even though ISP starts with pulling @var{/RESET} low, the
target continues to run at the internal clock speed as defined by the
firmware running before. Therefore, the ISP clock speed must be
reduced appropriately (to less than 1/4 of the internal clock speed)
using the -B option before the ISP initialization sequence will
succeed.
target continues to run at the internal clock speed either as defined by
the firmware running before or as set by the factory. Therefore, the
ISP clock speed must be reduced appropriately (to less than 1/4 of the
internal clock speed) using the -B option before the ISP initialization
sequence will succeed.
As that slows down the entire subsequent ISP session, it might make
sense to just issue a @emph{chip erase} using the slow ISP clock