Trouble transferring program for ICCV AVR to AVR GCC

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

So I need to change/ compile a program written for the ICCV Avr compiler using Atmel Studio 6 using GCC. I no longer have access to the ICCV compiler. I've successfully done this with smaller programs before but I'm having issues with this larger and much more complex program. The major difference with this program is that I'm having to store some constant variables in the __flash named address space.

I've gotten the program to compile with no errors and few seemingly insignificant warnings (e.g. variable is used uninitialized in this function)but when I go into debug mode it seems like nothing is actually being written to program memory. When I pause the debugger the disassembly window pops up and it seems the program counter has gone out of bounds so when I scroll to the top I sometimes see "nop" despite seeing the placing for the functions at certain points in the non-existent assembly code or other times see some code with "??? memory out of bounds" seemingly randomly placed in the code. I can get the program to at least reach a breakpoint in the simulator.

After trying to debug just once I can't enter debug mode again until I go to the device programming window, set the "use external reset" then erase the memory on the chip. If I don't do this it will always say "unable to enter programming mode." Once I do erase the memory I can change the "use external reset" back to off and I can do whatever I want until I try to program the chip again.

There are no lock bits set and the jtagice fuse is set and the cksel bits are set correctly to the external clock so I don't think that has anything to do with it.

Details: Using JTAG mkII in programming an ATmega 640 using Atmel studio 6.1.2674 with AVR GCC 4.7.2

Any help would be greatly appreciated. There's no way I can post the entire code as there's 20+ files worth. If posting any portion of it would be helpful please let me know.

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

Your problems sound more like an issue with AS6 and its debugger than anything specific to GCC. Should I move this thread to the AS6 forum?

Moderator.

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

elirentz wrote:
I've gotten the program to compile with no errors and few seemingly insignificant warnings (e.g. variable is used uninitialized in this function)

This is significant warning. You program probably will not work, al least in some cases.

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

clawson wrote:
Your problems sound more like an issue with AS6 and its debugger than anything specific to GCC. Should I move this thread to the AS6 forum?

Moderator.

I'm not sure move it wherever you feel is best. I thought it may have to do with trying to store the variables using the __flash named memory space. That's why I posted it here. I'm open to suggestions for how to further trouble shoot this.

I can program another chip with another program that I've converted to being able to be compiled with AS6 GCC and the same jtag programmer with no problems. The only major difference besides using more peripherals etc is using the __flash memory space to store some constant strings and structures.

This program worked when compiled with ICCV. I know they're different compilers but the warnings I'm getting shouldn't cause the problem I'm seeing.

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

Shirley you can simply use ImageCraft. AS6 can debug the resultant COFF object file:
File->Open->Object File for Debugging

If you really want to port it to GCC, then this should be fairly straightforward. I have sed scripts that can automate this to a certain degree.

Incidentally, the COFF files are easier for a human to debug than the ELF files from GCC. (GCC's optimiser is too clever to follow)

If you are already familiar with ImageCraft and have paid for the licence, why change ?

David.

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

david.prentice wrote:

If you are already familiar with ImageCraft and have paid for the licence, why change ?

David.


I've never used Imagecraft unfortunately and the Imagecraft license is on the coworker's computer that wrote the original code. He's on long term medical leave and may not be back to work. My boss wants me to convert the program to be able to be compiled by GCC so we both can change the program without having to buy another license. So I don't need to just debug I need to be able to make changes and compile the new code. The old one worked fine but there are some hardware changes that are being made that need to have software updated to allow for the changes

I've already made most of the significant changes like change how the the ISR's are defined and changing the names of some of the macros and definitions Imagecraft uses that aren't used in GCC.

It really is a nightmare because there's 5 years of development and testing that went into this code but the organization and some of the programming practices are a mess and a pain to trouble shoot and the coworker is not able to be reached.

I'm still pretty new to this so any help would be really appreciated. I've tried to search but didn't find anything that seemed relevant.

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

A 20+ file project is fairly daunting to port. You really don't want to do this by hand.

You need to compile and test with both toolchains. There is a significant amount of time and effort involved.

Your boss should be realistic. Your time and salary is a lot more than the cost of a new ICC licence.

As a hobbyist, my time is 'free'. If you are an employee, the situation is completely different.

David.

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

david.prentice wrote:
A 20+ file project is fairly daunting to port. You really don't want to do this by hand.

You need to compile and test with both toolchains. There is a significant amount of time and effort involved.

Your boss should be realistic. Your time and salary is a lot more than the cost of a new ICC licence.

As a hobbyist, my time is 'free'. If you are an employee, the situation is completely different.

David.

Yeah I totally agree. Especially with how the absent coworker programs but no matter how I've tried to sell it to my boss he wants to switch to using AVR Studio.

From your memory what else needs to be changed for the port besides what I mentioned above?

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

No, the sed script only changes:
1. system headers
2. __flash and __eeprom
3. ISR() syntax
4. single line asm calls
5. adds a "portability" header

You always require human oversight. e.g. appropriate use of 'volatile'. Apparently ImageCraft does not implement it. (or at least Uncle Bob has no concept)

David.

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

Thanks David. I figured out what the problem was.

This was hidden in one of the init functions:

#ifndef DEBUG_IS_ON
        SET_BIT(MCUCR, JTD); //release JTAG IO pins - when not debugging
        SET_BIT(MCUCR, JTD);  // must be executed twice
    #endif

That explains why the JTAG was acting strange.

At least now the program loads. Now on to debugging.

Thanks again for the help. I foresee having issues with some of the string functions since all the string literals are stored in __flash but perhaps thats a topic for another thread.

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

Given that GCC (since 4.7.2) now has __flash, just as ICC does, then I'm not entirely sure I understand why there'd be any issue with using ICC code that uses __flash in GCC?

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

The code didn't use the __flash syntax but I'm guessing that ICCV was better about storing a constant into flash automatically because when I first tried to compile the code I got an error that the RAM would be way past full. So I had to go back and add __flash to the definitions and declarations of 150+ different constants to get it to compile without an error. I'm not sure what version of ICCV he was using but I'm guessing it was pretty old.

I thought there may be issues when using string functions like strcpy() etc since the pointer that is being passed isnt a pointer to ram but a pointer to flash so __flash needed to be included in the parameter declaration. Is this not the case?

Sorry if this is newb stuff but I am new to this.

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

elirentz wrote:
I thought there may be issues when using string functions like strcpy() etc since the pointer that is being passed isnt a pointer to ram but a pointer to flash so __flash needed to be included in the parameter declaration. Is this not the case?
Correct.
Some standard functions allowing constant strings, e.g. strcpy,
have _P versions that take in-flash strings.

Iluvatar is the better part of Valar.