Standalone uploading hex file from SD Card using STK500v2 protocol

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

I want to be able to upload a hex file to an  Atmega2560 from an ESP8266 with an attached SD Card.  Since the target is a 2560 I know have to use v2 of the STK500 protocol.  Additionally, I want to be able to upload the code using the bootloader on the 2560 over TTL serial.  Not over ICSP (SPI).  The reason is I don't have enough free pins on the ESP8266 to bit bang SPI.

 

So I've found two almost complete solutions to solve my problem:

 

http://www.gammon.com.au/uploader

It will program an Atmega2560 using STK500v2.  However, the problem is that it uses SPI not normal serial.

 

http://baldwisdom.com/bootdrive/

It uploads over TTL serial, but does not use the v2 protocol so it can't program a 2560.

 

So is uploading using the bootloader over TTL versus ICSP(SPI) almost the same thing (eg command codes and sequence) or significantly different?  I know the the reset sequence is somewhat different.  Also, I'm kinda stuck on terminology.  Is uploading a hex file via a bootloader still called ICSP?

 

Right now I'm working on changing Nick Gammon's code from SPI to TTL serial.  But, I'm not entirely sure this is the correct approach.  Any thoughts would be helpful.  Thanks.

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

Just replace the bottom level byte send/receive in the SPI one with UART send/receive and it's job done.

 

But surely Arduino has a bootloader for the 2560 in a Mega Arduino? Why aren't you using that? 

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

clawson wrote:

Just replace the bottom level byte send/receive in the SPI one with UART send/receive and it's job done.

 

But surely Arduino has a bootloader for the 2560 in a Mega Arduino? Why aren't you using that? 

 

As I implied in my original post I think I'm not completely understanding the problem I want to solve.  I know what I want to do but I can't describe it properly.  The Arduino Mega does indeed have a bootloader.  How else would I upload a hex file over the UART?  Is there another way?

 

I'm not sure what you mean by bottom level byte.  In any event are you saying I *am* on the correct track by modifying Nick Gammons ICSP code? Thanks.

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

Perhaps it's me not understanding what you are describing. But say you start with a blank 2560. You use ISP just once to put Optiboot into it and from then on you can deliver code to it from a PC using avrdude and "-c arduino". So far so good. But in your design you want the EPS to replace the PC right? So now you just have to implement what avrdude was doing on the EPS don't you? The 2560 just continues to use the Arduino bootloader. Then it all just works. What am I missing?

dpetican wrote:
I'm not sure what you mean by bottom level byte.
If a bootloader is well written at the core it is going to have some kind of:

uint8_t comms_get_byte();
void comms_send_byte(uint8_t);

If the booloader is SPI based those will be:

uint8_t SPI_get_byte();
void SPI_send_byte(uint8_t);

(actually for SPI they may well be combined into a single function as send/receive happen together). So it's just a case of re-implementing those as:

uint8_t UART_get_byte();
void UART_send_byte(uint8_t);

and the bootloader is now switched to using UART because you just had to change the two low level routines.

 

Of course, if the bootloader is written as "spaghetti" with code accessing the send/receive interface all over the place then job is much trickier - but I doubt one would choose to use such code as it's clearly not been subject to any kind of design.

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

Yes thats it except I never said blank 2560.  But I wan't specific either ;) I'm using a stock Arduino Mega Board.  The ESP will reside on a shield.  Working on the changes now.  However, I have another problem.  The stock bootloader will hang if any electrical signal is connected to Rx0 when booting.  Working on fixes for that.  This seems particular to the Mega bootloader as there are fixes for the Optiboot used in the Unos etc.  Any suggestions?  Thanks.