Avr studio 4 and gcc compiler hangs up on build

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

HI

I am trying to compile c-code using avr studio and gcc plug-in.

for some reason it hangs and then a program error in windows occur. "Avr studio - not responding" and studio closes without compiling.

Any ideas???

Attachment(s): 

Regards

Compi

Last Edited: Thu. Mar 1, 2007 - 09:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OS: Windows 98SE
WInAVR: 20070122
AVR Studio: 4.13 Build 522 Beta

I couldn't find a target and i assumed compilation for Atmega32. Output in BUILD window seems OK for the first stage of compilation (preprocessor):

Quote:

Build started 10.2.2007 at 18:01:29
avr-gcc.exe -mmcu=atmega32 -Wall -gdwarf-2 -O0 -MD -MP -MT compi.o -MF dep/compi.o.d -c ../compi.c
avr-gcc.exe -mmcu=atmega32 -Wall -gdwarf-2 -O0 -MD -MP -MT Serial.o -MF dep/Serial.o.d -c ../../Serial.c
In file included from ../../Serial.c:28:
d:/winavr/bin/../avr/include/avr/signal.h:36:2: warning: #warning "This header file is obsolete. Use ."
../../Serial.c:34:23: error: Messaging.h: No such file or directory
../../Serial.c:35:20: error: Serial.h: No such file or directory
../../Serial.c: In function 'Serial_Processes':
../../Serial.c:131: warning: implicit declaration of function 'MsgHandler'
make: *** [Serial.o] Error 1

compi.c is a dummy file, which i have created with AVR Studio NEW PROJECT because you have supplied some sources but no real project.

Couldn't check further other source files and other tools (compiler, assembler, linker, objcopy), because some essential include files are missing.

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

compi,

The fault you describe was evident in 4.12 build 460 but fixed in 4.12 build 498 and now the beta of 4.13 build 522 - which version of Studio do you have? If anything less than 498 then upgrade.

Cliff

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

Thanks Cliff

I do have Studio ver.4.12 build 460. this explains it. will download the new build and try that. thanks for the help.

Steff, the code is for the ATmega8-16. I will try it again and keep you posted.

Compi

Regards

Compi

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

OK then just to note that 4.13 build 522 is available at www.atmel.no/beta_ware/

(be ready for a 75MB download!)

Cliff

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

Hi Cliff

I downloaded build498 and installed it, now the c code does compile but it does not generate the eeprom hex file, only the flash hex file. i added the revised code on my first post called whereavr.zip.

What should i do???

(All credits for the original code to Gary Dion)

Compi

Regards

Compi

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

I don't see your Makefile in the whereavr.zip so it's difficult to know what you were expecting to happen. It's certainly true that if you have defined any variables as EEMEM with initial values and you are using an Mfile generated Makefile then you SHOULD expect to see that a projname.eep file has been generated and it will contain those initial EEPROM values. But this is conjecture without seeing the whole of your project.

If you are using your own homebrew makefile do you have a step that uses avr-objcopy to extract the .eeprom memory section from th .ELF ?

Cliff

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

Hi Cliff

Sorry for the cross post!!

I updated the file "whereavr.zip" , it now contains all the files of my project. The "makefile" is in the "default" directory. This file was created by itself upon compiling. I am not to sure how the "makefile" works or what command to put into it to make the eeprom file.

there is a file called avr.atmel_eeprom_contents.
it only contains ":00000001FF"

There is also the file called avr.elf with gibberish in it.

Thanks for the help

Compi.

Regards

Compi

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

Well the file that you WOULD use to program in your initial EEPROM values is default/avr.eep but that contains just:

:00000001FF

This perhaps isn't such a great surprise as a grep of your source files shows nothing that would lead to EEPROM initial values being generated. Why do you think there would be some initial values for EEPROM generated by your code? Which line in which file do YOU think is responsible for doing that? (because I cannot spot such a line myself!)

Cliff

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

Cliff,

I see what you are saying. I was under the impression that the ax25.c should be programmed into the eeprom contents if I follow the original author`s comments. I did program his main hex file into flash and the main_eeprom.n4txi into the eeprom and everything works correct.

so, if I have it right then this means that I would not need the eeprom hex file. it should work with only the main hex file???

would my asumption be correct?? This will save me a lot of hassle.

Compi

Regards

Compi

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

I don't know as I'm not familiar with the software. Suggest you ask the original author.

Cliff

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

Thanks Cliff

I will try to contact him. should still have his email adress.

Compi

Regards

Compi

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

Hi

No luck with trying to get hold of the original author.

I compiled the code and programmed the 19kb file into the avr flash to see what happens.

It does not work. the sentance creation taken from the ax25.c file needs to be in the eeprom. now just to get it in the eeprom some how???

Compi

Regards

Compi

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

Out of curiosity, are you building an APRS tracker or something else related to packet radio?

Jim, KA7EHK

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Hi Jim

That is correct. I am trying to build a APRS tracker for use in my truck (Double cab pickup). The problem we have in South Africa is that we need to import the Tiny track or opentracker and it is a bit of a problem.

I am trying to get this code adapted for normal aprs mobile use, it will come in handy with events like the upcoming cycle challange where we assit with communications. We will have a medicaly trained person with us in our trucks and with aprs the event manager (also a HAM) can know which ham is closest to the scene of a problem to assist and perhaps help with medical assistance.

This is why i need to get this project of the ground asap.

Later on i would like to change the code to be a fully integrated packet radio modem like the baycom modem using the FX614 ic. we don't seem to get these chips in S.A , only if we import 50 units at a dollar value close to $500 they will assist us.

Kind Regards

Hannes (Compi)
ZS6LW

Regards

Compi

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

I hope you mean parts of ax25.c in EEPROM since you cannot execute out of EEPROM. The common thing would be to put "constants" (such as fixed strings) in EEPROM. Check out Dean's tutorial in the "AVR Tutorials" forum -

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=38417

If the strings remain fixed for the life of the device, then you can put THAT in program space. But if its call sign or ID strings, then you probably want it in EEPROM.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Hi Jim

Thanks for that info.

I decided to get rid of the eeprom file for now and make it all run of the flash. i will try the eeprom file again later on.

I changed the code but am not able to get any thing from the decoder rx i am using. the packet sound is good and the info sounds like it is there , but my tnc does not decode the signal.I will have to investigate further. Maybe my test avr got damaged some how.!!!???

I Will have to program a new one and see what happens.

Regards

Compi

Regards

Compi

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

You might toggle a port pin on modulation zero crossings. An LED on that pin, if you don't have a scope, would tell you if you are getting that far. If the LED is ON during idle, it will go to half-brightness and flicker during modulation. If the LED is off during idle, it will come on and flicker during modulation. With a scope, you can see the "squared" modulation, varying in period as it shifts from 1200Hz to 2200Hz on that LED port pin.

If it works that far, then something else downstream is happening.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Jim

seems like I messed up the code some where. when I load the original author's
hex files in eeprom and flash it works but with his info. in his readme file he says that one needs to edit the eeprom file and put your callsign info in there. but I am unable to see where his callsign and ssid info is in the file. thus I decided to revert back to putting this info in the flash side (ax25.c] I also made a change to the main.c file so that the avr will listen for no traffic before tx. all the code was there just had to remove the // .

I will post the code as I changed it. maybe someone can spot the problem. I went through it many a time and am unable to find the fault. maybe I messed up the timming by adding some more lines.

regards

Compi

Regards

Compi

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

If you open his working eeprom file in a hex editor, do the contents resemble the data listed in ax25.c in the commented-out lines of calls to ax25sendByte()? Keep in mind that the data apparently has to be encoded according to the lookup table given in ax25.c. Presumably the file should start with 0x82 0xA0 0x82... and then that first string should end with 0x03 0xF0 0x00 (as it's supposed to be a null-terminated string). Whether there's another string in his file I don't know, but his second (commented-out) use of ax25sendEEPROMString(31) implies that there might be a second string, starting at byte offset 31. You need to edit this (or these) string(s) to contain your data, rather than his, and it has to be encoded according to the lookup table. The EEPROM file won't be generated by compilation, but rather has to be edited by hand.

Aaron T.

Edited to add: he recommends using the program Hexplorer to open the eeprom file, presumably because it can import Intel hex files (among other formats), which his file might be stored in. I didn't see his eeprom file among the files you posted, so I don't know what format it's in, but this program might be necessary in order to edit it.

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

I can not seem to decode the eeprom file
at all. it does not make any sense even with the lookup table. what interests me is later in the code he makes use of the
ax25sendbyte('h') for example and not any encoded hex value.that transmits fine.

compi

Regards

Compi

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

Could you attach the eeprom file so we could take a look?

Aaron T.

ETA:

Quote:
what interests me is later in the code he makes use of the
ax25sendbyte('h') for example and not any encoded hex value.that transmits fine.
The character constant 'h' has the value 0x68, which is the code for the number four, according to the lookup table. Could this be what he's really transmitting with that command?

ETA again:
Never mind, I see that the lookup table only applies to the callsign, and not to the message that's transmitted separately, so outside of transmitting the callsign, 'h' really does mean 'h'. As it says:

Quote:
Each callsign character is shifted to use the high seven bits of the byte. Use the table below to determine the hex values for these characters.

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

Guys

I found the relationship between the lookup table in the ax25.c file and the main_eeprom file. if you edit the main_eeprom.n4txi file using notepad you will see the 2nd line from character number 9 looking like this (82A082ACA460609C68A8B0924076A48A....) the first byte send in the header is 0x82 the second byte is 0xA0 and so on. using the table in the ax25.c file it converts to "APAVR00" , just change this and save it using wordpad and load it on the avr, as easy as that ( took me how many weeks to see this????)

Just happy i could solve it.

Thanks for all the help

Regards

Compi

Regards

Compi

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

You aren't going to want to edit that file in Notepad, since it's an Intel hex format file, like I mentioned I suspected a few posts ago. If you edit it in Notepad, then the checksums at the ends of the lines aren't going to be correct. Try using the hex editor called Hexplorer (http://artemis.wszib.edu.pl/~mdudek/), like the author mentioned in his docs (and I mentioned a few posts ago), and import the file as an Intel hex record file. Then you can edit just the values in the file, and re-export it as an Intel hex record file with the checksums correct for each line.

Aaron T.

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

Hi Aaron

Thanks for the tip. i did not think of the checksum.
that would have messed me around quite a bit.

Thanks

Compi

Regards

Compi

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

I now have one problem. i dont know how to work hexplorer. i have struggled for many hours trying to figure it out but with no luck.

1) i open the main_eeprom.n4txi
2) i go to find to look for the current hex code (9C68A8B0924076) that i need to edit and the seach comes back with "SEARCH BYTES NOT FOUND"
3) i am using hexplorer v2.6

any ideas

Compi

Regards

Compi

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

I'm not having any problems finding that hex string in the file. First, did you import it as an Intel Hex file like I said? Second, when you're searching, are you entering that hex string in the "Hex" field of the find box, and not the "Text" field?

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

I got it right!!!

My project is finaly working as it should.

Thanks for the help

Compi.

Regards

Compi

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

Hello house,am new to this site,am building an RFID security system using Atmega32 i found the project on this site
http://instruct1.cit.cornell.edu...

with this c code for the Avr atmega32 c code on this link

http://instruct1.cit.cornell.edu...

i tried compiling with AVR studio but i get a whole lot of erros like these below

rm -rf RFID.o RFID.elf dep/* RFID.hex RFID.eep RFID.lss RFID.map
Build succeeded with 0 Warnings...
avr-gcc -mmcu=atmega32 -Wall -gdwarf-2 -std=gnu99 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT RFID.o -MF dep/RFID.o.d -c ../RFID.c
../RFID.c:5:21: error: Mega32.h: No such file or directory
../RFID.c:7:19: error: delay.h: No such file or directory
../RFID.c:65: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
../RFID.c:67: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
../RFID.c:72: error: 'USART_RXC' undeclared here (not in a function)
../RFID.c:72: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
../RFID.c:91: error: 'USART_DRE' undeclared here (not in a function)
../RFID.c:91: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
../RFID.c:103: error: 'TIM0_COMP' undeclared here (not in a function)
../RFID.c:103: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
../RFID.c:112: error: 'EXT_INT2' undeclared here (not in a function)
../RFID.c:112: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
../RFID.c:143: warning: return type of 'main' is not 'int'
../RFID.c: In function 'main':
../RFID.c:169: error: 'GICR' undeclared (first use in this function)
../RFID.c:169: error: (Each undeclared identifier is reported only once
../RFID.c:169: error: for each function it appears in.)
../RFID.c:175: warning: pointer targets in passing argument 1 of 'copy_code' differ in signedness
../RFID.c:175: warning: pointer targets in passing argument 2 of 'copy_code' differ in signedness
../RFID.c:180: warning: pointer targets in passing argument 1 of 'match_code' differ in signedness
../RFID.c:180: warning: pointer targets in passing argument 2 of 'match_code' differ in signedness
../RFID.c:185: warning: pointer targets in passing argument 1 of 'match_code' differ in signedness
../RFID.c:185: warning: pointer targets in passing argument 2 of 'match_code' differ in signedness
../RFID.c:187: warning: pointer targets in passing argument 1 of 'verify_code' differ in signedness
../RFID.c:192: error: 'PORTC' undeclared (first use in this function)
../RFID.c:226: error: 'bank_status' undeclared (first use in this function)
../RFID.c:237: warning: implicit declaration of function 'delay_ms'
../RFID.c:272: warning: pointer targets in passing argument 1 of 'copy_code' differ in signedness
../RFID.c:272: warning: pointer targets in passing argument 2 of 'copy_code' differ in signedness
../RFID.c:277: warning: pointer targets in passing argument 1 of 'match_code' differ in signedness
../RFID.c:277: warning: pointer targets in passing argument 2 of 'match_code' differ in signedness
../RFID.c: In function 'check_receive':
../RFID.c:330: error: 'bank_status' undeclared (first use in this function)
../RFID.c:351: warning: implicit declaration of function 'putsf'
../RFID.c:356: warning: array subscript has type 'char'
../RFID.c:356: error: 'code_bank' undeclared (first use in this function)
../RFID.c:391: error: 'PORTC' undeclared (first use in this function)
../RFID.c: In function 'store_into_bank':
../RFID.c:498: error: 'code_bank' undeclared (first use in this function)
../RFID.c: In function 'verify_code':
../RFID.c:515: error: 'bank_status' undeclared (first use in this function)
../RFID.c:520: error: 'code_bank' undeclared (first use in this function)
../RFID.c: In function 'match_code':
../RFID.c:541: warning: array subscript has type 'char'
../RFID.c:541: warning: array subscript has type 'char'
../RFID.c: In function 'initialize':
../RFID.c:668: error: 'DDRD' undeclared (first use in this function)
../RFID.c:669: error: 'TCCR2' undeclared (first use in this function)
../RFID.c:670: error: 'OCR2' undeclared (first use in this function)
../RFID.c:673: error: 'DDRA' undeclared (first use in this function)
../RFID.c:676: error: 'DDRC' undeclared (first use in this function)
../RFID.c:677: error: 'PORTC' undeclared (first use in this function)
../RFID.c:687: error: 'TIMSK' undeclared (first use in this function)
../RFID.c:688: error: 'TCCR0' undeclared (first use in this function)
../RFID.c:689: error: 'OCR0' undeclared (first use in this function)
../RFID.c:690: error: 'TCNT0' undeclared (first use in this function)
../RFID.c:697: error: 'UCSRB' undeclared (first use in this function)
../RFID.c:698: error: 'UBRRL' undeclared (first use in this function)
../RFID.c:713: error: 'bank_status' undeclared (first use in this function)
../RFID.c:717:3: error: invalid preprocessing directive #asm
../RFID.c:719:3: error: invalid preprocessing directive #endasm
../RFID.c:718: error: 'sei' undeclared (first use in this function)
../RFID.c:727: error: expected ';' before 'GICR'
../RFID.c:728: error: 'MCUCSR' undeclared (first use in this function)
../RFID.c:729: error: 'DDRB' undeclared (first use in this function)
../RFID.c:729: error: expected ';' before numeric constant
../RFID.c:751: warning: pointer targets in passing argument 1 of 'sscanf' differ in signedness
../RFID.c:752: warning: pointer targets in passing argument 1 of 'sscanf' differ in signedness
../RFID.c:753: warning: pointer targets in passing argument 1 of 'sscanf' differ in signedness
../RFID.c: In function 'gets_str':
../RFID.c:768: error: 'UCSRB' undeclared (first use in this function)
../RFID.c:768: error: expected ';' before numeric constant
../RFID.c: In function 'puts_str':
../RFID.c:777: error: 'UCSRB' undeclared (first use in this function)
../RFID.c:777: error: expected ';' before numeric constant
make: *** [RFID.o] Error 1
Build failed with 47 errors and 20 warnings...

and it looks like some header files like delay.h and mega32.h are missing or is there something am not doin correctly.

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

Dave,

Bad news I'm afraid:

1) you hijacked a thread
2) you hijacked a thread and it wasn't even the same subject or anything even remotely close
3) that code is written for Codevision and you are trying to use avr-gcc

In future start your own threads.

Moderator.