Страшные глюки с Philips 80C32, уже не знаю что деклать Опции

[Shedon]

Есть сабжевый контроллер, есть прога на си, код хранится во внешней флэш, на 64кб, есть графический дисплей с контроллером SED1335, стал замечать следующею зависимость: чем больше программа по объёму тем больше становится глюков, сейчас прога весит без оптимизации 56889bytes of code. глюки заключаются в следующем перестаёт выводить графику на экран()рисует какие-то линии от болды), и зависает на этом, причём скол-во глюков зависит неким образом от оптимизации. Больше всех глючат функции обращения к контроллеру дисплея, обработка прерывания от таймера и функции си типа sprintf, vsprintf
. Вот ниже привожу пример как у меня построена работа с дисплеем, эта функция рисует точку в один пихел.

Код

#define BASE_ADDR          0x5000
#define DISP_W_D ((char volatile*) 0x018000)
#define DISP_W_C ((char volatile*) 0x018001)
#define DISP_R_D ((char volatile*) 0x018001)
#define DISP_R_C ((char volatile*) 0x018000)

__data unsigned char n_bit,n_bat,d_byt;
__data unsigned int adress;

//...
//...

void put_pixel(int tx, int ty)
{
   n_bat = tx/8;
   n_bit = tx-n_bat*8;
   adress = BASE_ADDR+(ty*40+n_bat);

   *DISP_W_C=0x46;
   *DISP_W_D=adress;
   *DISP_W_D=adress>>8;
   *DISP_W_C=0x43;
   d_byt=*DISP_R_D;

   d_byt |= (0x80>>n_bit);

   *DISP_W_C=0x46;
   *DISP_W_D=adress;
   *DISP_W_D=adress>>8;
   *DISP_W_C=0x42;
   *DISP_W_D=d_byt;
}

Контроллер дисплея подключён как внешняя память, т.е. здаётся мне глюки происходят при обращение к внешней памяти. Как мне кажется я где-то ошибаюсь с настройками компилятора, да забыл написать, компилятор IAR8051 v6.11, эмулятор PICE51, ниже привожу коммандные файлы с настройками проекта может кто что подскажет, заранее спасибо.

Все файлы проекта компилируются со след. параметрами:

Код

--no_wrap_diagnostics --only_stdout
--core=pl
--code_model=n
--data_model=l
--nr_virtual_regs=8
--calling_convention=pr
--place_constants=data
--require_prototypes
--migration_preprocessor_extensions
-e
--enable_multibytes
-r
-lCN indic
--no_cse
--no_inline
--no_code_motion
--no_unroll
-IC:\PROGRA~1\IARSYS~1\EMBEDD~1.2EV\8051\inc\FileName.c

Илинкуются след. образом:

Код

-IC:\PROGRA~1\IARSYS~1\EMBEDD~1.2EV\8051\config
-D_EXTENDED_STACK_START=2000
-D_EXTENDED_STACK_END=23FF
-D_EXTENDED_STACK_SIZE=3FF
-D?DPS=86
-D_NR_OF_VIRTUAL_REGISTERS=8
-D?DPMASK=1
-D?CBANK=90
-D_CODEBANK_START=8000
-D_CODEBANK_END=10000
-D_IDATA_STACK_SIZE=0x90
-D_PDATA_STACK_SIZE=0x90
-D_XDATA_STACK_SIZE=0xFFF
-e_medium_read=_formatted_read
-l "KALIBR.MAP"
-xsm
-p80
-IC:\PROGRA~1\IARSYS~1\EMBEDD~1.2EV\8051\lib\clib\
-f "lnk51ew.xcl"
-FINTEL-EXTENDED
graf_r.R51
indic.R51
obr_klav.R51
pribor.R51
proverka.R51
sint_nch.R51
svitok.R51
upr_pkan.R51
ZNGENM10.R51
gui.R51
AT24C32.R51
ExchangePC.R51
C:\PROGRA~1\IARSYS~1\EMBEDD~1.2EV\8051\lib\clib\cl-pli-nlpd-1e.r51
-o KALIBR.hex

В итоге программа получается след. размеров:
55 565 bytes of CODE memory
70 bytes of DATA memory( + 11 absolute )
10 262 bytes of XDATA
149 bytes of IDATA
8 bits of BIT memory

[IgorKossak]

Позволю и себе высказаться.
Что касается стека, то поведение МК в этом случае очень симптоматично и причина, скорее всего, кроется именно в этом. Особенно когда я увидел ссылки в сообщениях на функции sprintf.
Но. Контроль стека предварительным заполнением его какой нибудь детерминированной величиной не на все 100% может дать нужный результат. Дело в том, что когда компилятор выделяет некое пространство в стеке под временные переменные, он просто меняет значение указателя стека (которое может указывать за пределы сегмента стека), но не обязательно что-то пишет в выделенное пространство. Поэтому в работе может сложиться впечатление, что стека ещё достаточно, но программа, тем не менее, падает, т. к. локальные переменные могут быть уже вне сегмента стека и затирают какие-нибудь глобальные переменные или случается прерывание, которое изменяя глобальные переменные на самом деле изменяет свой адрес возврата.
Поэтому, как ещё одна мера предосторожности, нужно расположить под стеком наименее ответственный сегмент данных, например сегмент со стрингами. Глюки в этом случае будет легче выявить и они не будут приводить к падению программы.

[-Tумблер-]

..не на все 100% может дать нужный результат. ..

Хорошенько подумав, пришел к выводу, что все-таки
"так не может быть". Действительно, в случае создания
автоматических переменных в стеке сначала произойдет коррекция
SP. Если в этот момент произойдет прерывание, у стека
будет занято еще некоторое пространство. Которое, очевидно,
будет использовано раньше (чем пространство локальных переменных).
И что же ? После окончания прерывания, локальные переменные
будут использованы, и память в стеке также будет изменена.
Никаких "проплешин" использования стека не будет.
В этом случае поменяется лишь порядок искажения стекового
пространства. Однако, если после вывода дампа стека в ком-порт
мы обнаружим не искаженную область стекового "ковра памяти",
это одназначно будет указывать на отсутствие переполнения.
А вот если не искаженной области не будет совсем,
однозначного вывода сделать нельзя.
Но даже если и в "этом разе" переполнения нет, работать
так не рекомендуется.. любая последующая коррекция проекта может привести к самым разным результатам..