Yeah, it needs the same compiler options as in the bin/build.sh script. Specifically, -Os and —std=gnu99 seem to have the most effect on size.
Sorry, i’m not sure where i can find/set that. .
Can you please tell me more details?
Using Windows version.
Update:
Okay i found a different post here and now i added the Os paramter, the std was there already, these are the paramters for now:
Invoking: AVR/GNU Linker : (AVR_8_bit_GNU_Toolchain_3.4.1_830) 4.6.2
“C:\x\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-gcc.exe” -o GccApplication4.elf GccApplication4.o -Wl,-Map=“GccApplication4.map” -Wl,—start-group -Wl,-lm -Wl,—end-group -mmcu=attiny13a
Finished building target: GccApplication4.elf
“C:\x\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-objcopy.exe” -O ihex -R .eeprom -R .fuse -R .lock -R .signature “GccApplication4.elf” “GccApplication4.hex”
“C:\x\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-objcopy.exe” -j .eeprom —set-section-flags=.eeprom=alloc,load —change-section-lma .eeprom=0 —no-change-warnings -O ihex “GccApplication4.elf” “GccApplication4.eep” || exit 0
“C:\x\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-objdump.exe” -h -S “GccApplication4.elf” > “GccApplication4.lss”
“C:\xAtmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-objcopy.exe” -O srec -R .eeprom -R .fuse -R .lock -R .signature “GccApplication4.elf” “GccApplication4.srec”
“C:\x\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-size.exe” “GccApplication4.elf”
text data bss dec hex filename
1058 0 16 1074 432 GccApplication4.elf
Done executing task “RunCompilerTask”.
Task “RunOutputFileVerifyTask”
GccApplication4(0,0): Program Memory Usage : 1058 bytes 103,3 % Full (Memory Overflow)
Data Memory Usage : 16 bytes 25,0 % Full
Done executing task “RunOutputFileVerifyTask” — FAILED.
Done building target “CoreRebuild” in project “GccApplication4.cproj” — FAILED.
Done building project “GccApplication4.cproj” — FAILED.
Build FAILED.
Update:
Also tried with the manual commands:
avr-gcc -Wall -g -Os -mmcu=attiny13 -c -std=gnu99 -DATTINY=13 -I… -I…/… -I…/…/… -o blf-a6.o -c blf-a6.c
avr-gcc -Wall -g -Os -mmcu=attiny13 -o blf-a6.elf blf-a6.o
avr-objcopy —set-section-flags=.eeprom=alloc,load —change-section-lma .eeprom=0 —no-change-warnings -O ihex blf-a6.elf blf-a6.hex
Also tried from debug to release, but still the same error 
I really can’t help with Windows-related issues. I haven’t been anywhere near Windows in decades.
I also am not familiar with doing this in Windows, but it looks like the only error was generated during the size verification at the end. Try to decrease size by using minimal biking strobe instead of full, regular strobe instead of police, etc.
Edit: these are easily controlled using the #define lines toward the top.
Guys, thank you all of you, it seems i found the root cause. First i tried with atmel studio 7.0 As i did not the paramters i installed the 6.0, but now i installed back the 7.0 and tada it is working. But still will check your paramters. Thanks.
I didn't changed the paramter so far, these are:
define TURBO RAMP_SIZE // Convenience code for turbo mode
#define BATTCHECK 254 // Convenience code for battery check mode
#define GROUP_SELECT_MODE 253
//#define TEMP_CAL_MODE 252
// Uncomment to enable tactical strobe mode
#define STROBE 251 // Convenience code for strobe mode
// Uncomment to unable a 2-level stutter beacon instead of a tactical strobe
#define BIKING_STROBE 250 // Convenience code for biking strobe mode
// comment out to use minimal version instead (smaller)
#define FULL_BIKING_STROBE
//#define RAMP 249 // ramp test mode for tweaking ramp shape
//#define POLICE_STROBE 248
//#define RANDOM_STROBE 247
#define SOS 246
Success too burn the fw :D
Guys the flash was okay, but i guess something is not okay with my fw. I have 6x7135 s2+ convoy lamp. The only thing what i modified on the biscotti only this:
#define NUM_MODEGROUPS 5 // don't count muggle mode
PROGMEM const uint8_t modegroups[] = {
1, 2, 3, 5, 7, STROBE, BIKING_STROBE, BATTCHECK,
1, 2, 3, 5, 7, 0, 0, 0,
2, 4, 7, STROBE, BIKING_STROBE, BATTCHECK, SOS, 0,
2, 4, 7, 0, 0, 0, 0, 0,
1, 2, 3, 6, STROBE, BIKING_STROBE, BATTCHECK, SOS,
};
My problem now if going into the programming mode i have 1 long light and 1sec strobe and after 2 long light and 1sec strobe, after it starts again with moon mode. What is the problem? Thank you.
I’m not sure that you have a problem. That’s how Biscotti operates - there are two “main menu” options. If you don’t select either of the two options, it’ll dump you out of the config menu. Have you checked out the instructions ?
If you tap during the buzz following the first blink, that’ll take you into the mode group select “sub-menu”.
Thanks, you were right, that part was not clear for me, but now i understand.
Working 
Great! Only 6 posts in and you’ve successfully modified and flashed firmware. You’re well on your way to being a flashaholic! Welcome aboard, btw.
Thanks :student:
Where i can find BLF A6 firmware without turbo timer? .hex file ready for flashing would be great.
I’m not aware of any, but it’s reasonably simple to disable that function in the source code. Comment out the “#define NON_WDT_TURBO” line and it should get rid of the turbo timer.
*
Thanks ToyKeeper, it might be simple for someone who actually knows programing but i sure needed some help here. Ill try that right now.
I’ve got one of the USBasp units from Fasttech and one of the cheap SOIC clips and I’m running into a problem, just wondering if anyone else has encountered it…?
Running it on Win 10, the USBasp driver is installed and I’ve managed to flash one chip and get a success report from MHV AVR shell.
Now, when I plug the programmer into a USB port the indicator LED illuminates, but as soon as I attach the clip to a chip the programmer seems to lose power.
If I disconnect either the 5V or ground wires from the clip, it powers back on.
Any idea if I’m making some rookie mistake, or do I have a faulty programmer?
What driver or air doing an MCU? saw something similar on a bad wired driver - pin#5 was connected to ground.
I was seeing the same behaviour on what I think is a red Convoy Driver and a new Qlite Rev.A.
I’ve I’ve just checked the clip connections and it’s now connecting to the Qlite!
Looks like I had a dodgy connection to the legs…rookie mistake :disappointed:
Thanks 
Now to try flashing Crescendo.
That’s exactly what mine does when I put the clip the wrong way around.
I was wondering, what I’ve done wrong… :person_facepalming:
Just got my order arrived coupe days ago, and I try to build the things in the best way I could. No luck.
That looks like the AVR is not responding at all , which likely means a mis-wiring.
Perhaps try confirming with a multimeter that MOSI / MISO on your USBASP is actually connected to the pins they should be on the SOIC clip.
I had a similar issue when I had the incorrect pin order in my ribbon cable ( I had the odds and evens reversed Vcc to MOSI etc)
I would check the wires again …