Go Down

Topic: NEWER New Optiboot bootloader (Read 2153 times) previous topic - next topic

otto001

#15
Aug 23, 2015, 07:29 pm Last Edit: Aug 23, 2015, 08:32 pm by otto001
Hi all,

first of all: thanks for this wonderful work!

I am just trying to get an UNO R3 together with a W5100 shield to work.
However, in case of power loss (or first power up) the sketch does not properly load, but as soon as I press reset, everything works fine.
As far as I could find out the arduino boots so fast, that the shield cannot properly initialize.
So I tried to add a delay to optiboot for my special purpose - all I could achieve was that I could not burn a program any more, as avrdude ran into timeouts.

So my question: can anyone please tell me, WHERE exactly in the optiboot.c code a delay could be placed without interfering with the flashing routines?

/edit: the TIMEOUT_MS could point in that direction, but seems not to be supported (yet)?

Thanks in advance!

Otto

westfw

While it is "interesting" that the normal Bootloader timeout is sufficient to allow the WS5100 shield to initialize, the proper place to insert a delay is surely in the sketch itself, rather than the bootloader.  A "delay(1500)" at the beginning of setup() should be indistinguishable from a delay in the bootloader.  (Ideally, there should be some way for the code to check whether the ws5100 is 'ready' for whatever is being done to it.  But I don't know whether there is.  The WS5100 has a lot of signals that are not connected to Arduino at all...)

(It DOES make sense that you're seeing insufficient delay on poweron, but not normal reset.   The bootloader has a feature called "fast start" that starts the sketch code immediately after poweron, and only runs the bootloader (which delays for about 1500ms looking for new code) on an explicit "reset.")

john1993

i always set opti timeout to half second regardless of reset type. just enough time for the "button pushers" and plenty snappy for auto-reset. instant run after flash.

btw if you are responsible for the alternate boards.txt in there mucho grassy-asss. it was a huge problem solver.

otto001

Thanks for your hints.
Interesting: Even a delay(5000) as first instruction of setup does not change anything.
As soon as I power on the arduino, the RX led flashes approx. once a second. Thats it. Only if I press the reset button, the sketch loads and everything runs as it should. And I have tested this with different sketches on different arduinos and different shields (all the same w5100 thou...)

My last hope is to try the delay somewhere in the bootloader, but I cant find out where ^^

westfw

You can try changing the code at main, from:
Code: [Select]
  ch = MCUSR;
  MCUSR = 0;
  if (ch & (_BV(WDRF) | _BV(BORF) | _BV(PORF)))
      appStart(ch);


to

Code: [Select]
  ch = MCUSR;
  MCUSR = 0;
  if (ch & (_BV(WDRF)))
     appStart(ch);


That should remove the special treatment of power-on.

otto001

#20
Aug 27, 2015, 07:41 pm Last Edit: Aug 28, 2015, 04:55 pm by otto001
Hi,

thank you. I am experiencing a weird problem though...

I am running a Fedora 22 box and compiled optiboot using

Code: [Select]
make ENV=arduino LED_DATA_FLASH=1 LED_START_FLASHES=3 LED=B0 BAUD_RATE=115200 atmega328

I am getting optiboot_atmega328.hex and optiboot_atmega328.lst
Then I burn it using avrdude:
Code: [Select]
avrdude -c usbtiny -p m328p -U flash:w:optiboot_atmega328.hex -v

Everything works fine, but when I try to upload a sketch using the arduino environment I am getting:
Code: [Select]
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00

I think I am having a more basic problem when trying to build / burn optiboot....
The weird thing is, if I burn the optiboot-version which is delivered with the arduino environment everything works fine!?
Does anyone know this problem? Or is this the wanted behaviour?
(Sorry, if this should be too basic for this thread)
/edit: the command I am using (from arduino IDE) to upload the program is
Code: [Select]
/home/otto/Downloads/arduino-1.6.5/hardware/tools/avr/bin/avrdude -C/home/otto/Downloads/arduino-1.6.5/hardware/tools/avr/etc/avrdude.conf -v -patmega328p -carduino -P/dev/ttyUSB0 -b115200 -D -Uflash:w:/tmp/build2203132785643432015.tmp/sketch_aug28a.cpp.hex:i

And this is the entry in boards.txt:
Code: [Select]
uno.name=Arduino Uno

uno.vid.0=0x2341
uno.pid.0=0x0043
uno.vid.1=0x2341
uno.pid.1=0x0001
uno.vid.2=0x2A03
uno.pid.2=0x0043

uno.upload.tool=avrdude
uno.upload.protocol=arduino
uno.upload.maximum_size=32256
uno.upload.maximum_data_size=2048
uno.upload.speed=115200

uno.bootloader.tool=avrdude
uno.bootloader.low_fuses=0xFF
uno.bootloader.high_fuses=0xDE
uno.bootloader.extended_fuses=0x05
uno.bootloader.unlock_bits=0x3F
uno.bootloader.lock_bits=0x0F
uno.bootloader.file=optiboot/optiboot_atmega328.hex

uno.build.mcu=atmega328p
uno.build.f_cpu=16000000L
uno.build.board=AVR_UNO

otto001


westfw

Code: [Select]
make ENV=arduino LED_DATA_FLASH=1 LED_START_FLASHES=3 LED=B0 BAUD_RATE=115200 atmega328


So, where are you executing this command?  And what are the results?
For instance, you also say:
Code: [Select]
/home/otto/Downloads/arduino-1.6.5/



But I don't think that the ENV=arduino thing works with 1.6.5...

Code: [Select]
avrdude -c usbtiny -p m328p -U flash:w:optiboot_atmega328.hex -v


And what's the output from this?  It doesn't program the fuses, but if you started with an Uno and can use the stock bootloader, that should mean the fuses are OK.
Do you see the initial three blinks when you press reset or start an upload?


Quote
when I try to upload a sketch using the arduino environment I am getting
The "not in sync" error is pretty worthless error messages go. :-(  Can you turn on verbose uploading and report the output from that as well?

I haven't actually tested the patch I suggested, on a real Uno or otherwise.
(and yes, this should probably be a new thread.)


otto001

#23
Aug 30, 2015, 04:48 pm Last Edit: Aug 30, 2015, 04:48 pm by otto001
Thank you!
I opened a new thread for this here: http://forum.arduino.cc/index.php?topic=344873.0

Go Up