eeprom_write_block on mega644

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

So I wrote a bootloader that receives 256 bytes at a time (over ethernet) and writes it a page at a time.  The image it writes is usually 50 or so pages long.  After it writes each page, it sends back an "ACK" to say all is well and ready for the next page.

 

This works correctly about a third of the time.  When it doesn't it usually freezes at some random amount of progress through the process and then becomes unresponsive and I have to restart the chip and begin again.  I thought my program that was sending it pages was sending them too fast so I made it wait 200ms or longer instead of the 100ms I usually do and it still fails often at about the same rate.

 

Anyone have any idea why a bootloader could be so unreliable but still functional if you're willing to let it try multiple times?  Kind of becoming a pain now.

 

Here's the function that writes the page:

void boot_program_page (uint32_t page, uint8_t *buf)
{
	uint16_t i;
	

	SREG = 0x00;				// Disable interrupts.
	cli();
	eeprom_busy_wait();

	boot_page_erase(page);
	boot_spm_busy_wait();      // Wait until the memory is erased.

	// Transfer new page data to temporary page buffer
	for (i=0; i<SPM_PAGESIZE; i+=2)
	{
		// Set up little-endian word.

		uint16_t w = *buf++;
		w += (*buf++) << 8;
	
		boot_page_fill (page + i, w);
	}

	boot_page_write (page);     // Store buffer in flash page.
	boot_spm_busy_wait();       // Wait until the memory is written.
	boot_rww_enable ();			// Reenable RWW-section again.
	SREG = (1<<7); 				// Re-enable interrupts
}

 

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

What has your thread title got to do with the subject of your post? This is about boot_program_page not eeprom_write_block isn't it?

 

Anyway as far as I know the only way you are going to resolve this is using diagnostics - the best option would be a JTAG debugger but otherwise you are going to have to pepper the bootloader code with printf()s so on a debug UART it documents its progress so you can get some idea of at what stage it is "stuck".

 

In reality code never really "freeze"s, (well not without SLEEP) so it presumably is continuing to fech and execute opcodes. But presumably this is caught in some kind of wait loop waiting for a termination that never happens?

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

Fair enough.  Thanks for the idea.  I'll have to learn how to use JTAGs it seems which is not a bad thing I guess.