Arduino as ISP strange problem

Projects Programming
21

Those smaller boards don't have an interactive "monitor" which tries to talk to you via the serial port.

22

Ah, so your saying it's just the mega1280/2560 boards that require auto reset to be defeated to reliably run arduinoISP? Or no?

So far the only mega boards I own are 1280 based and I've 'upgraded' them to optiboot (so no monitor or WDT problems on my mega boards), which as I understand it won't work on a mega2650 board.

Lefty

23

retrolefty:
Ah, so your saying it's just the mega1280/2560 boards that require auto reset to be defeated to reliably run arduinoISP? Or no?

I'm saying yes, because of the nature of the bootloader "monitor". Optiboot won't work (as far as I know) because it only addresses 64 K words (128 Kb) of memory.

In the Mega bootloader:

#ifdef BLINK_LED_WHILE_WAITING
	boot_timeout	=	 20000;		//*	should be about 1 second
//	boot_timeout	=	170000;
#else
	boot_timeout	=	3500000; // 7 seconds , approx 2us per step when optimize "s"
#endif

...

	while (boot_state==0)
	{
		while ((!(Serial_Available())) && (boot_state == 0))		// wait for data
		{
			_delay_ms(0.001);
			boot_timer++;
			if (boot_timer > boot_timeout)
			{
				boot_state	=	1; // (after ++ -> boot_state=2 bootloader timeout, jump to main 0x00000 )
			}
		#ifdef BLINK_LED_WHILE_WAITING
			if ((boot_timer % 7000) == 0)
			{
				//*	toggle the LED
				PROGLED_PORT	^=	(1<<PROGLED_PIN);	// turn LED ON
			}
		#endif
		}
		boot_state++; // ( if boot_state=1 bootloader received byte from UART, enter bootloader mode)
	}

It was interesting that in my logic analyzer output, we saw it asserting my testing pins for about 7 seconds. That would appear to indicate that it was waiting the 7 seconds (above). I can't necessarily see where those pins are written to in the bootloader, but since they probably weren't set to output, they might have been floating, and activity on a nearby pin made them look high.

24

I've need the cap to program chips on a breadboard with my Rev 1 UNO every time.

but since they probably weren't set to output, they might have been floating, and activity on a nearby pin made them look high.

They've been floating and they only "look" high. A likely story! How come they're giggling too?

25

There is a race condition that can allow boards to work without disabling auto-reset. The (optiboot) bootloader time-out and the avrdude time-out are the same. I have an Uno that times-out before avrdude allowing the ArduinoISP sketch to work without disabling auto-reset.

However, disabling auto-reset shaves about one second off the upload time.

26

A quick test shows 1 uF appears to be enough. However 0.1 uF was marginal. It worked once but not a second time.

27

I see! Now it all makes sense! Thank you (especially for actually understanding what I was trying to do)!

Now I know why my ISP shield has a solder pad jumper that (if jumped) puts a 100 ohm pullup on the reset line!

28

I have an "edited" version of the MEGA bootloader that has the monitor program removed. It compiles to just under 2K. It works, but I never used it because I thought it would be "better" to use the original bootloader (I actually reflash a MEGA2560, when necessary, with the factory loader that also has the FIRMATA code in it).

I'm going to try my stripped down bootloader and see if it works (i.e. responds to attempts to send bootloader code).

Getting 6K more of free flash will be nice too! :slight_smile:

(yes I know I will have to modify boards.txt to reflect the new max mem size as well as the bootloader fuse size).

29

Is your logic analyzer a "soft" analyzer or an actual hardware box?

30

This (hardware) one:

Extremely useful. The technique of setting up pins for debugging purposes is very handy (I didn't actually have LEDs on them). The fact that the LEDs didn't toggle, even though my code made them toggle, gave me the clue that maybe my code wasn't even being executed.

Plus it confirmed that we were getting serial input into the device.