Честно говоря такие вопросы задавать стыдно, но все же может ответ на поверхности. Работаю в WINAVR из AVRStudio. Например есть 3 файла исходников на Си. Один главный в котором функция main и 2 с подпрограммами. Из главного вызываются подпрограммы, описанные в 2 других файлах. Так вот когда запускаю симуляцию по шагам, то в подпрограммы, расположенные в первом файле вход происходит и можно посмотреть что делается в них по шагам. А вот в подпрограммы, расположенные во втором файле вход не происходит, как будто подается команда на выполнения шага без захода в подпрограмму. Хидеры в главном файле объявлены. Что можно сделать, или это глюк такой у WINAVR? WINAVR у меня 20060421, AVRStudio 4.13, система XP.

Makefile покажите. Было такое при включенной оптимизации в значение 3.

Make файл

###############################################################################
# Makefile for the project MP3_Player_2
###############################################################################

## General Flags
PROJECT = MP3_Player_2
MCU = atmega128
TARGET = MP3_Player_2.elf
CC = avr-gcc.exe

## Options common to compile, link and assembly rules
COMMON = -mmcu=$(MCU)

## Compile options common for all C compilation units.
CFLAGS = $(COMMON)
CFLAGS += -Wall -gdwarf-2 -std=gnu99 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
CFLAGS += -MD -MP -MT $(*F).o -MF dep/$(@F).d

## Assembly specific flags
ASMFLAGS = $(COMMON)
ASMFLAGS += $(CFLAGS)
ASMFLAGS += -x assembler-with-cpp -Wa,-gdwarf2

## Linker flags
LDFLAGS = $(COMMON)
LDFLAGS += -Wl,-Map=MP3_Player_2.map


## Intel Hex file production flags
HEX_FLASH_FLAGS = -R .eeprom

HEX_EEPROM_FLAGS = -j .eeprom
HEX_EEPROM_FLAGS += --set-section-flags=.eeprom="alloc,load"
HEX_EEPROM_FLAGS += --change-section-lma .eeprom=0 --no-change-warnings


## Objects that must be built in order to link
OBJECTS = MP3_Player_2.o fat.o glcd.o id3.o mmc.o playlist.o skin.o vs1011.o

## Objects explicitly added by the user
LINKONLYOBJECTS =

## Build
all: $(TARGET) MP3_Player_2.hex MP3_Player_2.eep MP3_Player_2.lss size

## Compile
MP3_Player_2.o: ../MP3_Player_2.c
$(CC) $(INCLUDES) $(CFLAGS) -c $<

fat.o: ../fat.c
$(CC) $(INCLUDES) $(CFLAGS) -c $<

glcd.o: ../glcd.c
$(CC) $(INCLUDES) $(CFLAGS) -c $<

id3.o: ../id3.c
$(CC) $(INCLUDES) $(CFLAGS) -c $<

mmc.o: ../mmc.c
$(CC) $(INCLUDES) $(CFLAGS) -c $<

playlist.o: ../playlist.c
$(CC) $(INCLUDES) $(CFLAGS) -c $<

skin.o: ../skin.c
$(CC) $(INCLUDES) $(CFLAGS) -c $<

vs1011.o: ../vs1011.c
$(CC) $(INCLUDES) $(CFLAGS) -c $<

##Link
$(TARGET): $(OBJECTS)
$(CC) $(LDFLAGS) $(OBJECTS) $(LINKONLYOBJECTS) $(LIBDIRS) $(LIBS) -o $(TARGET)

%.hex: $(TARGET)
avr-objcopy -O ihex $(HEX_FLASH_FLAGS) $< $@

%.eep: $(TARGET)
-avr-objcopy $(HEX_EEPROM_FLAGS) -O ihex $< $@ || exit 0

%.lss: $(TARGET)
avr-objdump -h -S $< > $@

size: ${TARGET}
@echo
@avr-size -C --mcu=${MCU} ${TARGET}

## Clean target
.PHONY: clean
clean:
-rm -rf $(OBJECTS) MP3_Player_2.elf dep/* MP3_Player_2.hex MP3_Player_2.eep MP3_Player_2.lss MP3_Player_2.map


## Other dependencies
-include $(shell mkdir dep 2>/dev/null) $(wildcard dep/*)

Пользуйтесь окном дизасемблера, хоть это и неудобно.

Причина в том, что функции, просмотреть которые нельзя, просто проинлайнены, ввиду того, что вызываются небольшое число раз. Можете, конечно, запретить инлайнить на время отладки атрибутом или в ком строке.

Как запретить инлайнить на время отладки атрибутом или в ком строке.

Читайте об аттрибутах в:
C:/WinAVR/doc/gcc/HTML/gcc-4.3.2/gcc/Function-Attributes.html

Это не помогло.

А в листинг вы смотрели? Проблема действительно во встраивании? Если да, то куда вы применяли атрибут? Сделайте и выложите сюда минимальный проект из одного main() и двух функций a() и b() в разных файлах, на котором эффект наблюдается. Только весь проект, в виде архива.

Отправить файл не получается. Но тем не менее, на маленьком проекте все работает и без атрибутов.
С большим проектом тоже разобрался. Возможно глючит WINAVR периодически.

Даю 99.9%, что WinAVR в вашем случае не глючит даже периодически, а виноват недостаток знаний. Приведите отрывок исходника и листинга, где он "сглючил", будем разбираться. Пока нет доказательства в виде листинга вероятность источника глюков примерно такова: 99% - кривые руки и 1% - положение звезд на небе. По поводу последней цифры агрументация примерно как у вас: "возможно".

несколько раз натыкался на подобное, когда над одним и тем же комплектов исходников работал из разных сред - AVR Studio и Eclipse. Студия по умолчанию делает несколько упрощенный make-файл и бывает так, что не компилируя прилинковывает объектники, ранее сгенерированные без отладочной информации. т.е. В этом случае заход в функции, о которых нет отладочной инфы, не получается...

хотя судя по первому посту, это не та ситуация...

Руки как раз не такие уж и кривые. Проблема была решена так: был создан новый проект и все файлы исходников были созданы заново, а их исходные тексты скопированы из "условно глючных". Все заработало. Замечена еще одна странность: после изменения текста в каком-либо файле и последующем его сохранении в папке с проектом появляется некий файл имя которого начинается с имени сохраняемого файла, далее в имени идут цифры, а его расширение "TMP". Чтобы это значило? Причем потом этот файл нельзя удалить даже после закрытия AVR Studio. Есть подозрения что проблема с операционкой.

Есть подозрения что проблема с вирусом. Который плодит тмп-шки, не давая их удалять. Проверьте машину...

"Казалось бы, при чем здесь Лужков?" Т.е. при чем тут компилятор? Вы нашли что же именно в этих "условно глючных" файлах приводит к сбою и не передается копировальным путем? Причина так и не установлена, но свалить вину на компилятор как бы за между прочим - нормальное дело.

На мой взгляд было бы вполне достаточно просто пересоздать проект, а не морочиться с копированием текстов. ARV об этом намекал, хотя и сделал неверный вывод.

Clean Project и потом Build All

Я пользуюсь AVRStudio_4.15b619 + WinAVR_20081124rc3, ОС WinXP_sp2. Таких проблем никогда не было.

Наступил на те же грабли. Winavr2008 - который последний.

Тут не только попытки инлайнить вызываемые функции (довольно большие), но и инлайнится for(),  и если первое убрал расстановкой атрибута noinline, то второе проявляется случайным образом. 20071221 так не хулиганил. В общем, было 2180 байт после расстановки  noinline стало 1180. Не мало. Я так понимаю, теперь при -Os что-то еще по умолчанию подключено, а что может быть - не могу найти. Помогите, плз

Попробуйте --param inline-call-cost=N, с N = 4, 5 или 6.

Также функции которые используются только в одном модуле, должны быть объявлены как static.

Анатолий.

Спасибо! Но это только вложенные вызовы. А оно затронет циклы? Пока не на чем проверить...

Извините но я не знаю термина "инлайнится <цикл> for(), ", пример привидите.


Анатолий.

Это называется "unrolling loops", когда небольшие циклы "разматываются" в линейный код