Show Posts
Pages: [1]
1  Using Arduino / Microcontrollers / Re: Why did the mega 2560 not work as an ISP? on: July 19, 2013, 09:17:33 am
Hi Coding Badly et al,

Please provide a code fix for the observation that you make:
For the record, your solution has a race condition that makes it unreliable.

In my opinion the fix detailed above does not introduce any additional race condition that was not already present.  Instead the fix to mega-isp actually improves the operation by limiting the number of signon responses that are made to one, if you like the last one mega-isp receives.  After all for a signon attempt its only the last one that should have any significance, the earlier attempts are redundant.  As I commented above
it would be better (for avrdude) to try, try till it comes up
Indeed a three way handshake where avrdude confirms that it saw the response would ensure that the two way communication channel has started as with the two way handshake its not obvious to the mega-isp code that its response has been received by the avrdude code, however more complex fixes would likely require changes to stk500 startup code that the avrdude arduino startup is based on and since stk500 code is well established perhaps the additional code churn would not be worth the effort?

Anyway I can confirm that I have been using my fixed versions of avrdude and mega-isp for some time now with no obvious problems and I dont have to make any modifications to the mega2560 board to get it all working.  Now all I need is for openocd to support atmega644!
2  Using Arduino / Microcontrollers / Re: Why did the mega 2560 not work as an ISP? on: July 01, 2013, 03:54:01 am

I updated my first post with the two bug fixes (one for avrdude and the other for mega-isp).  The new versions should work for all isp actions (installing bootloader or installing sketch).  Hope these bug fixes help someone.  I have contacted the avrdude and mega-isp teams and hope to get the bug fixes included at some point in the main code.

3  Using Arduino / Microcontrollers / Why did the mega 2560 not work as an ISP? on: June 30, 2013, 03:03:03 am

I have a mega 2560 and wish to programme a ATmega644PA chip.  I have read lots of posts and lots of tutorials and tried them out with no success then I found that mentioned that mega 2560 did not work for others, so rather than purchase a Arduino UNO thought it a good point to open this new thread about why the mega 2560 does not work as an ISP out of the box and provide the fix to make it work.

TESTING ArduinoISP sketch:
I have loaded into my mega 2560 and open a serial connection to the mega 2560 and send "1 " to the mega-isp sketch and get the response "?AVR ISP?" so I know that the sketch is loaded correctly and that it is responding correctly (the ? is my way of indicating the 0x14 or other none print character).  My serial speed is 9600 baud because the mega-isp sketch has Serial.begin(9600).

I have already got the latest avrdude on my Ubuntu computer but just to be safe (and also because it did not work) I built avrdude from source

Now I run the command
avrdude -b 9600 -c arduino -p m644p -t -vvvv -P /dev/ttyACM0

And get
         Using Port                    : /dev/ttyACM0
         Using Programmer              : arduino
         Overriding Baud Rate          : 9600
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

avrdude done.  Thank you.

Start the serial monitor again and type "1 " and it is still working.  So it seems to me that the mega-isp sketch does not correctly communicate with avrdude Version 5.11svn-20111019 out of the box.

BUG FIX 1 in avrdude V5.11 - Ok so I am editing this question as I find fixes / as people tell me what to do - thus you only need to read this message and the end of the thread that I have not done anything with yet!
Nick suggests - disabled reset on the Mega - and - disable the bootloader - well I dont like the idea of that I would rather fix avrdude so that you dont have to make any hardware modifications.  So as I have built avrdude Version 5.11svn-20111019 all I need to do is add a bit of additional delay into the static int arduino_open(PROGRAMMER * pgm, char * port) in arduino.c I added 1 second.. it would be better to try try till it comes up but the delay is a good first patch:
  /* Set DTR and RTS back to high */
  serial_set_dtr_rts(&pgm->fd, 1);

  /* Sleep to allow the Arduino board to reset */

   * drain any extraneous input
Now the avrdude gets the basic communication with the mega-isp working but I get a couple of protocol error messages:
avrdude: Send: A [41] . [80]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Recv: . [14]
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x14
avrdude: Send: A [41] . [81]   [20]
avrdude: Recv: . [10]
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x10
avrdude: Send: B [42] . [82] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [ff] . [ff] . [ff] . [ff] . [01] . [00] . [08] . [00] . [00] . [01] . [00] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [01]
avrdude: stk500_initialize(): (b) protocol error, expect=0x10, resp=0x01

And more important at the end it reads the wrong signature
avrdude: Device signature = 0x98e781
avrdude: Expected signature for ATMEGA644P is 1E 96 0A

BUG FIX 2 in mega-isp - Looking at the trace (and also I implemented a second USART connection to the mega 2560 to confirm with additional debug output to the second port) its obvious that the avrdude code sends a burst of signon messages without giving the mega-isp code time to process the received messages.  So avrdude keeps on getting the responses to each of these messages that it sent earlier -
avrdude: Recv: . [14]
avrdude: Recv: . [10]
till the mega-isp code has finally processed all the signon messages.  Oops.. thats the root cause of the problem because avrdude has moved on so it sees the response to signon as a response to the next message that it has sent... thus the string of protocol error from avrdude.  So the fix for this is to catch the first signon message and before responding clean out the receive buffer then send the STK_INSYNC / STK_OK message that the avrdude is waiting for.  Then the avrdude sends its next message and mega-isp will respond to that message correctly because its the first message in the receive queue.  The fixed sketch int avrisp() function now has:
  uint8_t ch = getch();
  switch (ch) {
  case '0': // signon
    error = 0;
    if (getch() == CRC_EOP) {
      // empty the input stream
      while (0<Serial.available()) getch();
    } else {

I have wired the mega 2560 up to the ATmega644PA processor as described in

I have made no other alterations (because the tutorial does not ask for further modifications) and it seems to me that no other modifications should be needed.

With these two fixes - one to avrdude - and the other to mega-isp - I can now enter the interactive terminal and get all the great features that avrdude provides.  I have now tested out programming etc and have not found a problem and the mega 2560 does work as an ISP.

In the thread below Coding Badly et al suggest a better fix for the mega-isp code.  Rather than empty the input stream blindly
      // empty the input stream
      while (0<Serial.available()) getch();
Its better to set a flag and empty the input stream checking for each new command.  If a new different command is received then clear the flag and proceed as normal.  This fix will avoid the chance that avrdude could send two signon messages that mega-isp handles then receives the third signon message and fails.  I have not tried this slightly better fix yet so just refer you to the quotes from Coding Badly and @westfw
When I try this fix I will clear initSent on every command other than signon because till initSend is cleared mega-isp would be un-responsive to future signon messages.
In addition johnwasser points out below that we might need STK500V2 protocol rather than STK500V1 protocol.
Great comments from these guys, I am still working on avrdude team to fix the first and most basic problem where avrdude starts before mega-isp has come out of reset.

4  Using Arduino / Installation & Troubleshooting / Re: External supply at 5v pin on: April 06, 2013, 03:52:07 pm
I also looked at the NCP1117 datasheet and came to the same conclusion.  With care it should be ok to use +5V pin on the Mega2560.  With care means look at 10 ways to Destroy an Arduino - and dont try any of these! 
I also tried for a short period of time to use both external 5v regulator and the USBVCC power with no obvious problems.  It is clear that the USBVCC switch will be switched on because VIN will not have sufficient voltage to switch it off so both USBVCC and the external 5v regulator will be supplying the +5v rail and thats not good and you will need to protect your external regulator.  I would not run with both USBVCC and an external 5v regulator at the same time because you may not be lucky.  Also ensure that you use an isolated external supply because you dont want to have the external supply to have a different ground potential to the USB port.
5  Using Arduino / Storage / Re: SD Card - how to reduce the power consumption? on: February 24, 2013, 06:03:45 pm
I added a simple change to the SD library to help with this issue.  I have not tested it fully yet but it may be of interest to know that the SD library has a begin() but no matching end().  I implemented:

void SDClass::end() {
       if (root.isOpen())

This allows you to close the SD library.  Also I am using an N-Channel FET in the ground of the SD card (BS170 Drain connected to SD card gnd, BS170 Gate connected to 10K to ground and Arduino digital IO pin, BS170 Source connected to ground).  When I wish to switch off the SD card I tristate all the SD card connections and then I tristate the FET Gate pin.  The 10K resistor forces the Gate to 0v and all the pins on the SD card float to Vcc.  Next step is to switch off the SPI module in the processor and take the power consumption down further.
Switching back on is easy but this time to switch on the power to the SD card put the FET Gate pin to HIGH.  This forces the FET full on and with its low Drain - Source resistance puts power back on to the SD card.  It all seems to work but I have not measured the off current and I still have to put the processor to sleep.
Pages: [1]