Enhanced Butterfly BootLoader Rev.2 with Power Management

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

ButterflyBoot2 is an Enhanced Butterfly BootLoader. It is a fully compatible, alternative Butterfly BootLoader with the unique feature of power management, that extends the battery life.
Tests have been done, resulted in impressively lower power consumption: Down to 27% of any other similar firmware release without power management, either being official or not.

ButterflyBoot2 is the GPL licenced upgrowth of my own ButterflyBoot LGPL licenced project, I have published at: https://www.avrfreaks.net/index.p...

The ButterflyBoot2 firmware size is below the 512W boundary, in order to fit into the 512W bootloader space of the third boot-start option. This way, the ButterflyBoot2 releases 1KB of program memory space for you to dedicate to your Application Section by presetting the boot-start at the third position (512W, at address 0x1E00) instead of the standard fourth position (1024W, at address 0x1C00). This can be easily done by changing the boot-block-size Fuses, accordingly.

The ButterflyBoot2 firmware size can be so small, without sacrificing any functionality at all, because it is hand-crafted in pure assembly.

The major enhancements of the ButterflyBoot2 are:
* The addition of Power Management routines, to minimize the overall power consumption.
* A large part of its predecessor's ButterflyBoot Programming Engine has been rewritten and optimized.
* It has an improved Auto-Oscillator-Calibration accuracy.
* The firmware still fits into the 512W bootloader space, of the third boot-start option.
* It is functionally compatible with the official Butterfly bootloader releases, because it supports all the memory access modes (Word/Block mode, FLASH/EEPROM read/write and LOCK/FUSE read access).
* It is failsafe because the Write_Lock_Bits command is disabled, therefore the MCU cannot be locked by itself. This way, the firmware eliminates the known 0x940C error, discussed at: https://www.avrfreaks.net/index.p...

Here are a few typical current consumption figures:

# Butterfly Battery specifications:
Model: CR2450
Nominal Voltage: 3.0 Volts
Nominal Capacity: 550 mAh (at 0.2 mA Discharge Current, +23°C)
Standard Discharge Rate: 0.2 mAh
Maximum recommended current under continuous discharge: 3 mA
Maximum recommended current under pulse discharge: 15 mA

# Butterfly current consumption measurement conditions:
Butterfly Vcc: 3.00V (provided by a regulated power supply)
Brown-Out Detector: Disabled
CPU clock frequency: 2 MHz
USART baud rate: 19200 bps
Test-writing and reading the official "AVR_Butterfly_application_rev06.hex" firmware


# "ButterflyBoot v1.1" (or any other) bootloader, without power management:
* Bootloader is inactive:
Buttons released:     0.01 mA (100%)
"ENTER" presssed:     1.50 mA (100%)
* Bootloader is active:
On line, standing by: 1.42 mA (100%)
FLASH reading:        1.95 mA (100%)
FLASH programming:    1.95 mA (100%)
FLASH erasing:        4.41 mA (100%)
EEPROM reading:       1.95 mA (100%)
EEPROM programming:   4.44 mA (100%)

# "ButterflyBoot2 v1.0" bootloader, with power management:
* Bootloader is inactive:
Buttons released:     0.01 mA (100%)
"ENTER" presssed:     0.47 mA ( 31%)
* Bootloader is active:
On line, standing by: 0.39 mA ( 27%)
FLASH reading:        0.99 mA ( 50%)
FLASH programming:    0.99 mA ( 50%)
FLASH erasing:        3.82 mA ( 86%)
EEPROM reading:       0.99 mA ( 50%)
EEPROM programming:   3.91 mA ( 88%)

Note: The ATmega169 does not support single EEPROM erasing operations; these take place in the background, during EEPROM Programming.

If anybody wonders why I have not released a smaller sized bootloader firmware, to fit into the 256W bootloader space perhaps, my answer is straightforward: It can easily be done; but it is NOT recommended at all for the Butterfly device.
Having it discussed off-line with Smiley, the huge Oscillator_Calibration function is essential for the Butterfly bootloader operation, to help the latter have an accurate baud-rate USART. This is because the main clock source of the Butterfly is its calibrated internal oscillator, whose default OSCCAL value is not always the best one: The frequency of the Butterfly internal oscillator will drift over the ambient temperature range and the power supply voltage variations, and as a result of this, the oscillator has to be calibrated at every power-up or reset.
In my opinion, the oscillator calibration function should not be omitted, especially when the Butterfly is operated on battery power. Therefore the Butterfly bootloader cannot be stripped down, below the 512W boundary, which is already half of the size of the official bootloader.

TIP #1: Even with power management, since a battery is the Butterfly's main power source, when the battery is almost empty there is a possibility for the CPU to execute random instructions, that could probably alter the Fuse/Lock settings and/or the program memory and/or the EEPROM contents. Reference: "Preventing Flash Corruption" at the ATmega169 data sheet Rev.O, page 262.
To prevent this erratic behaviour you can enable the Brown-Out Detector at 1.8V, which will prevent the CPU from random instruction executions when the voltage drops, at the expense of an extra 10μA continous current consumption. Unfortunately, the BOD Fuses cannot be changed during the program runtime, so the BOD cannot be controlled by the firmware. The BOD can only be always enabled, or always disabled, and its status and settings can be changed only during the ISP/JTAG/HVP programming.

TIP #2: After the completion of any BootLoader operation you can reset the Butterfly, to enter a minimal power consumption state, by sending the "Bootloader Exit" command ("E"), pressing the "Exit" button of the AVRProg.exe front-end programmer. It has the same effect as pulling the /RESET line to GND. The AVRDude programmer sends the "Exit" command automatically.
Be careful though, not to confuse the "Bootloader Exit" command ("E") with the "Chip Erase" command ("e"), if using an RS-232 terminal. The ASCII BootLoader commands are case-sensitive.

I hope that you will find useful this special piece of firmware, I had promised to release.

Best Regards,
George.

Attachment(s): 

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Nice work George!!!

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

Well done

Will use this one for sure , as i can adapt it due to the source being released also.

/Bingo

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

dksmall and Bingo, thank you both!

I am sorry I did not respond earlier; I was away...
Though I have extensively tested this firmware, If you happen to find any possible malfunctions, or have any improvements to suggest, please tell me, to make this piece of software even better.

Thanks again

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Oh my , oh my!!!! It is happening!!! :shock:

Thank you Gio! amazing work!

---
ARod

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

Now, that's a wonderful piece of software :)!

Embedded Dreams
One day, knowledge will replace money.

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

Congradulations on your new release Giorgos!

Giorgos_K wrote:
If anybody wonders why I have not released a smaller sized bootloader...the huge Oscillator_Calibration function is essential for the Butterfly bootloader operation,
.

You are right, the routine used by Atmel is huge!

Below is my condensed version... only 16 lines,
consider it a peace offering, feel free to use it.
If anyone else that wants to use it, I'd appreaciate the credit.

CAVEAT LECTOR: The following code may be offensive to some of the more convervative programmers.

TSTOSC:  DEC    TMP        ;ADJUST OSCAL  
         STS    OSCCAL,TMP
         OUT	TIFR1,FF    ;RESET
         OUT	TIFR2,FF    ;OSC COUNTER
         STS	TCNT1H,ZERO ;START IT
         STS	TCNT1L,ZERO ;FROM ZERO
         STS	TCCR1B,ONE  ;READY...GO!
         STS    TCNT2,ZERO ;CLEAR TIMER
W6103:   SBIS	TIFR2,1    ;CHECK TIMER
          RJMP	W6103     ;6103uS PASSED?
         LDS    XL,TCNT1L  ;READ COUNTER
         LDS	XH,TCNT1H   ;CHECK ACCURACY
         CPI    XH,23      ;CHECK HIGH BYTE
          BRNE  TSTOSC     ;WAY OUT-OF-RANGE
         CPI    XL,175     ;CHECK LOW BYTE
          BRLO  TSTOSC     ;OUT-OF-RANGE    
           RET             ;OSC=6103+/-40uS

Since we are going in different directions, you conserving power and me trying to squeeze more from the Butterfly, can we put aside rivalries and co-operate? I have tried to follow the register conventions that you and Atmel started so some of our routines might be interchangeable.

Last Edited: Fri. Mar 31, 2006 - 04:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Gentlemen, I feel honoured to be among you.

Thank you for your nice words.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

I hope you don't mind sharing ideas like this Giorgos.

In my bootloaders I go back and re-calibrate the oscillator coming out of the sleep state.

I don't see you or Atmel doing that.

It might be a good idea because there's no way to know if temperature changed or what has happened since taking the nap.

Last Edited: Thu. Mar 30, 2006 - 11:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also, Giorgos, I drop the clock speed to just 1Mhz before taking the nap with my Bootloaders to further conserve the draw on the battery while sleeping. Then I reset it when chip wakes. This might help you to make your version even more energy-wise.

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

[Delete]

Last Edited: Sat. Apr 15, 2006 - 01:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My Routine is acually MORE accurate than the above C program from Atmel. If you examine the C code you'll see that they are calibrating the oscaillator between 6150 and 6250 which is about +/- 50uS of the 6103 where it should be. If you read my comments or examined the code closley you'd see that I calibrate to +/- 40uS which is more accurate.

Actually my routine, does work, it works very well and has so for quite a while now. If you can't figure how it works, I understand, as there are a few "dirty" programming tricks I used to reduce it's size. Size is the #1 problem with the OSCCAL routine.

I'd love to explain, but this is Girogos' thread for his new BootLoader, both these comments are off topic (sorry Giorgos). Keep and eye on the Tutorial Forum. If there's any interest perhaps I'll do a walk-through on some of the tricks I used. I'm going to leave the topic at that for now, as I do not want anyone to hijack Giorgos' thread. The real topic of this thread is his new bootloader and not my unconventional programming practices.

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

Giorgos,
Thanks very much for your work including the detailed power measurements.

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

Quote:

Actually my routine, does work, it works very well and has so for quite a while now.

The guts of your routine are common in approach to the posted GCC routine. Apparently we aren't seeing the pre-entry code--for example, what value does TMP have when entering the fragment?

I assume the fragment is entered with interrupts cleared or other provisions are taken.

My main question also revolves around TMP, indirectly. Since your fragment only goes in one direction I can only assume that TMP starts out at the max OSCCAL value? Otherwise one can go in the wrong direction with the coarse adjustment and many repetitions would have to elapse before it finally wraps to the right value. Perhaps not a bad approach for the smallest-bootloader goal; a lengthy recal may not be a problem. For continuous recal in a different (non-bootloader) app, I'd only want to tweak in the correct direction to keep comms going. Luckily for the actual numbers involved, 175 is pretty much in the middle of 255 so the 23 test will almost always come true.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:
RetroDan, shouldn't that be CAVEAT EMPTOR?

I guess "caveat lector" means "let the reader beware", as opposed to the buyer. Still, nice to know you're still out there, MOM!

Four legs good, two legs bad, three legs stable.

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

My apologies to Giorgos.

My intent was to help him reduce his OSCCAL routine and did not realize it would generate controversy and interest.

Due to this, and some private mail feed-back I have started a thread in the Tutorial Forum on this topic. See you there!

Sorry Giorgos. The real topic of this thread should be his new Bootloader.

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

Nice work Giorgos!

Shucks, it's so nice to have folks acting civilized once again. Maybe I'll hang around for awhile.
Nice new avatar Lee!

-Tom

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

Thank you all, for the feedback.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)