Standalone uploading hex file from SD Card using STK500v2 protocol

Go To Last Post
7 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.

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

Just finally gotten around to trying out the serial programming.  The bootloader hanging was a problem with my board design.  I've fixed that.  So what I did is follow Nick's original instructions and connected an Uno (as programmer) to a Mega (as target) using SPI connection.  I was able to flash a program from the SD card to the Mega.  So to try this over serial I changed the code as follows with no luck:

 

// Bit Banged SPI transfer
byte BB_SPITransfer (byte c) {
  //byte bit;

  /*for (bit = 0; bit < 8; bit++) {
    // Write MOSI on falling edge of previous clock
    if (c & 0x80)
        BB_MOSI_PORT |= bit (BB_MOSI_BIT);
    else
        BB_MOSI_PORT &= ~bit (BB_MOSI_BIT);
    c <<= 1;

    // Read MISO
    c |= (BB_MISO_PORT & bit (BB_MISO_BIT)) != 0;

   // Clock high
    BB_SCK_PORT |= bit (BB_SCK_BIT);

    // Delay between rise and fall of clock
    delayMicroseconds (BB_DELAY_MICROSECONDS);

    // Clock low
    BB_SCK_PORT &= ~bit (BB_SCK_BIT);

    // Delay between rise and fall of clock
    delayMicroseconds (BB_DELAY_MICROSECONDS);
  }*/

  altSerial.write(c);
  // Possibly need a delay here?
  if (altSerial.available());
    c = altSerial.read();

  return c;
}

// Execute one programming instruction ... b1 is command, b2, b3, b4 are arguments
// Processor may return a result on the 4th transfer, this is returned.
byte program(const byte b1, const byte b2 = 0, const byte b3 = 0, const byte b4 = 0) {
  noInterrupts();
  BB_SPITransfer(b1);
  BB_SPITransfer(b2);
  BB_SPITransfer(b3);
  byte b = BB_SPITransfer(b4);
  interrupts();
  return b;
}

I tried using hardware serial as well with the same results.  Am I doing something simple wrong or is it more complex than just this change?  I believe there is a difference between talking with the processor over SPI and talking to the bootloader over serial.  I'm thinking its a different set of hex codes and structure. Thanks.

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

Best way to diagnose SPI problems is with an oscilloscope or logic analyser.