AVR109 byte by byte programming?

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Trying to write a console app in pelles c that will send the cmds and data to an AVR109 bootloader to burn a page into flash. I think the cmd sequence is: A hi lo of word addr, then 128 loops of c lobyte C hibyte to put data in the mysterious invisible page buffer, then an m cmd to write the page buffer at previous A cmd word addr. Repeat for 124 pages. If this is right, I cant make it work. If its wrong and you know how to make it right, please tell me.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

 

 

 

Last Edited: Tue. Jun 20, 2017 - 02:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should look at the source code.

 

Here are the commands I use for my AVR911 bootloader.  It might be useful.   I guess most bootloaders use the same commands.

 

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A hi lo of word addr, then 128 loops of c lobyte C hibyte to put data in the mysterious invisible page buffer, then an m cmd to write the page buffer at previous A cmd word addr.

For what chip?   The page size is variable between chips, and most have less than 256bytes in a page...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Bill. Its an AT90can32, 32k flash, 128word/256byte page size. I cant grok what the pagebuffer is. A 256 byte hunk of ram in the flash? So its not in the avr ram? If I send A 0 0, does that set the page buffer index to 0? So after 128 c lo C hi its filled? Then I do A hibyte lobyte of the word address of where to write it? But I want to write it to word addr 0! Somewhat confusing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I cant grok what the pagebuffer is. A 256 byte hunk of ram in the flash? So its not in the avr ram? If I send A 0 0, does that set the page buffer index to 0?

Yes, apparently.  At least, that's the way the hardware inside the chip works (and from the hardware perspective, your sequence looks right.)  Atmel and various programmers have gotten very ...  particular about having programming commands match hardware commands (which I think is silly, especially for a bootloader.)  (incidentally, this is also how much high-density external flash/eeprom chips work as well.  They have a RAM buffer that you load up with a page of data, and then write all at once.)

 

My actual experience is with STK500v1 rather than avr109...

 

If you can successfully program your chip with avrdude, you should be able to turn on very very very verbose debugging ("-vvvv") and see the actual bytes that go back and forth.

 

Did you do a "Start Programming" command and chip erase first (I don't see a page erase in the 109 spec.  In fact, the whole DOC1644.pdf looks more like an app note "example" of how to do things, rather than a detailed (or even usable) specification. :-(  Do you need to turn on "autoincrement"? (WTF does Autoincrement even do?)

 

You're waiting for responses, right?  Especially after the "page write" command, which can take pretty significant milliseconds?

 

Are you using a particular bootloader?  Those can impose additional restrictions, and operate in unexpected ways.  For example, I see that there also a "B" "Start Block Flash Load" command; in the Arduino world, it wouldn't be unusual for a bootloader to implement ONLY the block mode (to save space)...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The PC program just sends flash addresses followed by data.  It doesn't know anything about pages or about how to write to flash memory.  The bootloader on the AVR handles that.

 

The PC program does ask the bootloader the maximum amount of data it can send with one write command.  It has nothing to do with pages, but of course it can't be greater than the amount of RAM available.

 

The bootloader could set the max write data to be the same as the flash page to make it a bit simpler for the bootloader.  But the page size of EEPROM would probably be less so the bootloader still has to chop up the data it receives when doing EEPROM.

 

The bootloader has to set the max data size of a write command before receiving data.  It won't know if the PC will send flash or EEPROM data.  It could send both.  Each write command contains an E or F to indicate what the data is.  At least that's how AVR911 works. 

Last Edited: Tue. Jun 20, 2017 - 10:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks folks. I'm still working on it, and it helps to know that its still a somewhat mysterious process even for expert assembler programmers. The example  I'm using is distributed with the imagecraft compiler in the examples dir, and the microsyl megaload avr side thats based on the same example. Neither of those has block mode, thus my query on how to do byte at a time mode. They fit in a 512 word/1k block. My goal is to have a sort of generic console app pc side that acts like the old prom programmers I used to use with hot key commands like load hex file into pc, dump it in bytes or words, burn it, verify, blankcheck, same stuff with eeprom. I can do stuff like erase, signature, its just burn a page in flash that I'm missing something on.