izaya/collapseos
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity

avr: improve docs

Browse Source 
The batch mode thing seems to have been caused by bad timing on my
prototype. Now that I've corrected it, live interaction seems to
work fine.
This commit is contained in:
Virgil Dupras 2020-09-05 16:52:46 -04:00
parent 5b4917dbe9
commit 350b7c5939
1 changed files with 14 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
doc/avr.txt
View File

@ -35,26 +35,27 @@ with "(spid)".
Then, you initiate programming mode with "asp$", and then issue your commands. Then, you initiate programming mode with "asp$", and then issue your commands.
At this time, only fuse commands are implemented. You get/set they values with
"aspfx@/aspfx!", x being one of "l" (low fuse), "h" (high fuse), "e" (extended
fuse).
Each command will verify that it's in sync, that is, that its 3rd exchange Each command will verify that it's in sync, that is, that its 3rd exchange
echoes the byte that was sent in the 2nd exchange. If it doesn't, the command echoes the byte that was sent in the 2nd exchange. If it doesn't, the command
aborts with "AVR err". aborts with "AVR err".
At the time of this writing, it is recommended that you perform your commands in # Access fuses
batch, that is, running your commands right after the "asp$" command, ending
your batch with "(spid)" so that the next batch works. In my tests, interacting
with the chip "live" in a single "asp$" session sometimes resulted in unreliable
data that didn't properly detect sync errors. TODO: investigate further.
# Writing data to Flash You get/set they values with "aspfx@/aspfx!", x being one of "l" (low fuse),
"h" (high fuse), "e" (extended fuse).
# Access flash
Writing to AVR's flash is done in batch mode, page by page. To this end, the Writing to AVR's flash is done in batch mode, page by page. To this end, the
chip has a buffer which is writable byte-by-byte. To write to the flash, you chip has a buffer which is writable byte-by-byte.
begin by writing to that buffer using aspfb! and then write to a page using
aspfp!. Writing to the flash begins with a call to asperase, which erases the whole
chip. It seems possible to erase flash page-by-page through parallel
programming, but the SPI protocol doesn't expose it, we have to erase the whole
chip. Then, you write to the buffer using aspfb! and then write to a page using
aspfp!. Example to write 0x1234 to the first byte of the first page:
asperase 0x1234 0 aspfb! 0 aspfp!
Please note that aspfb! deals with *words*, not bytes. If, for example, you want Please note that aspfb! deals with *words*, not bytes. If, for example, you want
to hook it to A!*, make sure you use AMOVEW instead of AMOVE. You will need to to hook it to A!*, make sure you use AMOVEW instead of AMOVE. You will need to
@ -62,8 +63,3 @@ create a wrapper word around aspfb! that divides dst addr by 2 because AMOVEW
use byte-based addresses but aspfb! uses word-based ones. You also have to make use byte-based addresses but aspfb! uses word-based ones. You also have to make
sure that A@* points to @ (or another word-based fetcher) instead of its default sure that A@* points to @ (or another word-based fetcher) instead of its default
value of C@. value of C@.
Beware of bootloader sections! By default, AVR chips have a bootloader using the
first few pages (by default, the ATMega328P uses 4 pages for its bootloader).
Check (or modify) the BOOTSZ fuses to confirm where you whould start writing
your program.