Why do I need this delay_ms(...) to get it work?

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

Hi!
I am currently working with a mega8 @14.74MHz.
Here is a CodeVision snippet from my app. where I'm trying to invoke the bootloader...

case UPLOAD_SOFTWARE:
     send_ACK(); // send ack via UART
     delay_us(1500); // ???
     UploadCommand = 0x11; // write 0x11 in eeprom
     GICR = 1; GICR = 2; // move vectors to bootloader section
     #asm("rjmp 0xE00") // jump to bootloader 
break;

Can anyone explain to me why do I need to insert a delay after send_ACK?
Without this 1.5ms delay, the PC app. that sends the HEX-file to AVR says: "No ACK! Failed to invoke bootloader!"...

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Aren't you moving the vectors before the sendack is finished if no delay ??
There is a delay in shifting the messages out of the uart

Could be verified if you loop over the ("transmiter empty" uart bit) , instead of delay

/Bingo

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

Bingo600 wrote:
Aren't you moving the vectors before the sendack is finished if no delay ??
There is a delay in shifting the messages out of the uart

Could be verified if you loop over the ("transmiter empty" uart bit) , instead of delay

Well... the "sendACK" has only 4 bytes (... @ 9600 bps -> aprox. 1char/ms). No interrupts used for Tx... And, according to datasheet: eeprom write takes aprox. 8.5ms.
So, the question still stands...

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

While an eeprom write might take 8.5mS, the cpu will stall, and not process any further instructions. So it's likely that 3 of the 4 bytes of your ack (first two immediately, and the 3rd after the eeprom write) get out before the vector table switch, without the delay.

If you don't want a fixed delay, poll your UART buffer for empty.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

As I am not using interrupt-Tx, I suppose only the last byte remains unsent... 1.5ms confirms that. I tried using Tx Complete bit and now it works ok.
Thx Bingo & Glitch! :-)
PS: didn't know that also UART freezes while eeprom-write...!!! Why? :-( kinda strange... ummm.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

If you're not using interrupt driven TX, then I don't know why. As far as I know the I/O clock continues to run during an eeprom write, only the processing core is put on pause.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Quote:

PS: didn't know that also UART freezes while eeprom-write...!!!

The UART doesn't "freeze" as such--the EEPROM routines will have a hard loop to wait for any previous write to complete before proceeding. During many milliseconds of spin, many UART characters could be lost (RX) or a long gap could appear between transmitted characters (TX).

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:
During many milliseconds of spin, many UART characters could be lost (RX) or a long gap could appear between transmitted characters (TX).

Well... it seems that (in my first version of the code) the Tx managed to send the last byte in Nirvana! I was pulling my hair off... 'cause it seemed quite easy, yet sometimes problems occur from nowhere.
BTW: as I mentioned before, a good "remedy" is to use "Tx Complete" bit!

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.