Can't create a hex file (Solved, Thanks)

I’m trying to create a hex file from a C file with Atmel Studio 7.0 and I’m not having any luck at all. My goal is just to recompile the factory firmware for my A6. It all looks setup good, but when I try to build it, it gives me 9 errors. What am I doing wrong?

Here’s what I do:

  1. I create a new “GCC C Executable Project”
  2. I choose ATtiny13A
  3. I replace all the main.c code with the code from the blf-a6.c
  4. I drop the 5 tk-xxx dependency files in the project folder, one level above the main.c file.
  5. I click build and get these major errors:

Those errors should be clickable or expandable or something, to show the source code for where each error occurred. It would probably help to see the context of each error to understand what happened.

Anyway, part of the issue is that you need to define ATTINY. If you look at the tk-attiny.h file, there should be something near the top which gives this hint. If it doesn’t know which MCU it’s compiling for, it’s designed to say “Hey, you need to define ATTINY.” and stop.

You can do this by putting a definition in the source code or by passing it on the command line to gcc. I normally do it via command line (like “-DATTINY=13”) because that allows the code to build for multiple MCUs with no changes.

There’s also an error about “int8_t”, which I don’t recognize offhand. Probably a compiler setup issue or a missing library header but it’s hard to say without more context.

FWIW, this is how it looks when I build the source (includes the command line options so you can compare against what Atmel Studio is doing:

[-(Mon 2017-01-16 0:21:42)-(~/src/torches/trunk/ToyKeeper/blf-a6/)-]> ../../bin/build.sh blf-a6
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
Program:    1004 bytes (98.0% Full)
Data:         13 bytes (20.3% Full)

I’m not sure how to get everything built in Windows.

Thanks ToyKeeper. I never thought to look inside the .h files for something like that. Simply defining ATTINY solved all the strange and serious errors. Trying to build now only gives one error. I wonder if Atmel Studio is bloating the result with some pointless metadata? I suppose I could delete some code to overcome this error, but perhaps there is a better way. We are getting close.

By deleting the code for both strobe modes I was able to get the size down to 99.2% and get a successful build. I wish I knew where that extra 10% inflation was coming from.

PS - after digging into the main code I found this: “// Choose your MCU here, or in the build script.” hehe

Do you have optimization for size enabled?

In that build session I pasted, most of the options are actually required in order to get a successful build. In this case, it’s probably the “-Os” and “—std=gnu99” options which are missing.

Thanks guys.
Well I found the option to optimize for size, and it compiles in full now. What does std=gnu99 mean? It says success even without that, yay.

And the second question would be for the next step. When I run MHV AVR Shell and use the commands:

I get an incomplete process, even when using ToyKeeper’s hex from the repo:

Update: After modifying the modes and strobe setting I flashed my hex and assembled the flashlight. It turns out the modifications took effect. However the delay for short and medium press is WAY off. I was worried about that.

Regarding the size problem:
Atmel Studio defaults to “Debug” configuration which adds additional code for debugging. If you haven’t done this yet, just select “Release” at the top of the window.

Regarding programming:
Avrdude didn’t program the fuses. Your “Ulfuse”parameter looks strange is this really an “x” between “0” and “75”?

Good catch FlashyMike. That symbol must have been on the how-to when I copy-pasted the line from into my notes. That fixed the read error! The Release-mode was a great idea, but it doesn’t appear to have reduced the size. After a little online reading about std=gnu99, it appears that would be a work-stop issue if it didn’t default to that. So it appears everything is set.

Excellent! A huge thank-you to everyone on this thread for the much needed assistance!

So should I look into that ‘sck period’ warning in the output, or is that normal?

It appears I need to read up on how to adjust the capacitor drain time too.

It’s normal and doesn’t harm.

Values are in “tk-calibration.h”.

Tools to help with calibration are under the battcheck/ directory, including a file explaining how to do the calibration. It helps to have a multimeter and a metronome.

Thanks. I had found the tools, but didn’t understand how it would communicate the .5 second and 1.5 second values back to me. So I did a naughty and just guessed with percentages. Originally fast-press was around a 3 seconds instead of .5 seconds, so working on percentages I made a good guess. After 4 tries I had both the .5 and 1.5 second values right where I wanted them.

Does the ADC for battery voltage need calibrating too?

Yes, the voltage probably needs calibration too. At least, if you want LVP and battcheck to work.

X

DOH! Disregard that last post. I was so convinced these things were set to a 4 bar battery meter I was reviewing the 4 bar code looking for a 8 bar mistake. Then I went back to the main file and saw the #define BATTCHECK_8bars… I guess it works as expected :person_facepalming: I’m too sick today to think straight.