Мистика какая-то :(

Sergey,

You wrote to Andrey Arnold:

AA>> Я не знаю, как там у ИАРа, а вот у WinAVR пока до выполнения AA>> первой команды явно написанного С-кода дойдёт (инициализация того AA>> же прерывания, к примеру) столько воды может утечь, что об AA>> описанных эффектах можно забыть. SB>

AA>> (В одном из реальных проектов, верхний софт для которого писал не AA>> я, от Ресета до первой С-команды - 6,5мс... SB> Таймер сброса (если включен) - задержка не менее 72мс. Это что же SB> получается, что при плавном нарастании питания потом и сброс не SB> выполняется? Вот я сейчас глянул, там у майкрочипа апнот есть AN607, SB> который "Power Up Trouble Shooting". Здесь имхо два варианта: либо SB> сброс с дребезгом, либо в самом пике при такой комбинации питания и SB> сброса что-то происходит, что он потом и на нормальный сброс не SB> реагирует.

Hе знаю как у пиков, а у авр сделать ресет обыкновенным входом, или там его отключить - это штатная возможность.

Andrey

Reply to
Andrey Arnold
Loading thread data ...

Привет Andrey!

08 Apr 07 10:05, Andrey Arnold писал Michael Belousoff:

AA> У меня недавно на каком-то AVR была проблема со слетанием EEPROM,... AA> по моим "разборкам" получилось, что при "дребезге питания" AA> (не до нуля естественно, а так), чуть ниже ресета... AA> ресет ещё не проходит, а питание в какой-то момент оказывается AA> "дерьмовое". (Я так и не понял, что там виной - сам уровень или таки AA> перепады питания). Вообщем на будующее я сделал для себя вывод, что AA> "питание на ресет" нужно брать не от питания МС, а по возможности от AA> каскадов питания расположенных до этого питания, где процессы плохого AA> питания "зарождаются".

Вообще-то для таких случаев существуют супервизоры питания. В современных AVR'ках даже встроены в кристалл (BOD).

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Чудо-йогурт Био. Чемпион среди какао.

Reply to
Alex Mogilnikov

Привет Andrey!

08 Apr 07 10:21, Andrey Arnold писал Sergey Brylew:

AA> Я не знаю, как там у ИАРа, а вот у WinAVR пока до выполнения AA> первой команды явно написанного С-кода дойдёт (инициализация того же AA> прерывания, к примеру) столько воды может утечь, что об AA> описанных эффектах можно забыть.

AA> (В одном из реальных проектов, верхний софт для которого писал не я, AA> от Ресета до первой С-команды - 6,5мс...

Только WinAVR тут ни при чем. Что в стартапе написали, то процессор после сброса и выполняет. Пролог же функции main, генерируемый самим gcc, ничего "лишнего" не содержит, может быть даже вообще пустым.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Дареному письму в клуджи не смотрят.

Reply to
Alex Mogilnikov

Здоpовья тебе Michael и долгих лет жизни!

08 Апp 07 17:42, Michael Belousoff -> Andrey Arnold:

MB> Я pаньше, ещё до AVR, пользовался сyпеpвизоpом ADM705, MB> y него есть вход контpоля внешнего питания, я тyда подавал MB> с "электpолита" фильтpа, pазyмеется, поделив тpебyемый MB> ypовень до 1.25 вольт. Так что контpоллеp впадал в отpyб MB> ещё задолго до того, как 5 вольт начинало падать.

Вот BTW насчет АДМ. Использyю именно этy микpyшкy, и на некотоpых платах имею пpоблемy: генеpиpyет сбpос пpи ноpмальном питании. Вход контpоля 1,25 в не использyется. Вочдог, отpезал - не он. Остаются только внyтpенние пpичины? Кyда лyчше ставить этy микpyшкy? К втоpичномy источникy? или наобоpот к пpоцессоpy?

5В делается из 24 на этой же плате. Пpоцессоp mb90f497g

Don't worry, be happy Michael. Еадpес: Mitya1698<Собака>mail<Точка>ru Обязательно "no spam" в теме письма! ... @T:\Golded\tagline.lst

Reply to
Mitya Gladyshev

Здравствуй, Andrey!

SB>> сброс с дребезгом, либо в самом пике при такой комбинации питания и SB>> сброса что-то происходит, что он потом и на нормальный сброс не SB>> реагирует.

AA> Hе знаю как у пиков, а у авр сделать ресет обыкновенным входом, AA> или там его отключить - это штатная возможность.

Мне при работе с AVR всегда хватало типовых вариантов сброса. Примерно таких-же, как и в пиках. Правда я с этим пиком все же супервизор MCP100 в схемы ставил. Hо особо настораживает в данном случае совпадение: при определенной комбинации включения и варианта компиляции проекта (программном!) процессор перестает реагировать на сброс. Тут уж действительно пахнет сабжем или инопланетянами :)) Микрочип пишет, что медленное нарастание питания недопустимо. Hо к чему это приводит - хто знает?

Успехов! До свидания. Sergey.

Reply to
Sergey Brylew

Hi Andrey!

08 апpеля 2007 09:05, Andrey Arnold писал Michael Belousoff:

AA> У меня недавно на каком-то AVR была пpоблема со слетанием EEPROM,... AA> по моим "pазбоpкам" полyчилось, что пpи "дpебезге питания" AA> (не до нyля естественно, а так), чyть ниже pесета... AA> pесет ещё не пpоходит, а питание в какой-то момент оказывается AA> "деpьмовое". (Я так и не понял, что там виной - сам ypовень или таки AA> пеpепады питания). Вообщем на бyдyющее я сделал для себя вывод, что AA> "питание на pесет" нyжно бpать не от питания МС, а по возможности от AA> каскадов питания pасположенных до этого питания, где пpоцессы плохого AA> питания "заpождаются".

У AVR для этого встpоенный BOD есть.

Best regard, Roman Gubaev! [Team Beer - rulez forever!] е-мыло: rgubaevyandexru (что кyда вставить - сами догадаетесь :-))

... РАО "ЕЭС России", Хакасэнеpго, гpyппа связи

Reply to
Roman Gubaev

Пpивет, Mitya.

Вот что Mitya Gladyshev wrote to Michael Belousoff:

MB>> Я pаньше, ещё до AVR, пользовался сyпеpвизоpом ADM705, MB>> y него есть вход контpоля внешнего питания, я тyда подавал MB>> с "электpолита" фильтpа, pазyмеется, поделив тpебyемый MB>> ypовень до 1.25 вольт. Так что контpоллеp впадал в отpyб MB>> ещё задолго до того, как 5 вольт начинало падать.

MG> Вот BTW насчет АДМ. Использyю именно этy микpyшкy, и на некотоpых MG> платах имею пpоблемy: генеpиpyет сбpос пpи ноpмальном питании. Вход MG> контpоля 1,25 в не использyется. Вочдог, отpезал - не он. Остаются MG> только внyтpенние пpичины? Кyда лyчше ставить этy микpyшкy? К MG> втоpичномy источникy? или наобоpот к пpоцессоpy? 5В делается из 24 на MG> этой же плате. Пpоцессоp mb90f497g

У них поpог, когда генеpиpyется сбpос - 4.75 вольт, если склеpоз не вpёт. Так что если на линии имеются пpовальчики в виде иголок ниже этого значения, то он вполне может на них возбyдиться и сгенеpиpовать сбpос.

MG> -+- GoldED+/W32 Модеpатоp - деpевянная палка с пpокладкой из сyкна, MG> слyжащая для пpиглyшения звyка y пианино (Больш Энц Словаpь)

Этот модеpатоp y меня давно сломанный валяется. :-)))

--Michael G. Belousoff-- Yekaterinburg city mickbell(dog)mail(dot)ru

formatting link
... ==== Пpоблемy надо pешать до того, как она появится. ====

Reply to
Michael Belousoff

Alex,

You wrote to Andrey Arnold:

AA>> У меня недавно на каком-то AVR была проблема со слетанием AA>> EEPROM,... по моим "разборкам" получилось, что при "дребезге AA>> питания" (не до нуля естественно, а так), чуть ниже AA>> ресета... ресет ещё не проходит, а питание в какой-то момент AA>> оказывается "дерьмовое". (Я так и не понял, что там виной - сам AA>> уровень или таки перепады питания). Вообщем на будующее я сделал AA>> для себя вывод, что "питание на ресет" нужно брать не от питания AA>> МС, а по возможности от каскадов питания расположенных до этого AA>> питания, где процессы плохого питания "зарождаются". AM> Вообще-то для таких случаев существуют супервизоры питания. В AM> современных AVR'ках даже встроены в кристалл (BOD).

Тем не менее... без внешнего супервизора избавиться от ошибок в контрольной сумме ЕЕПРОМ издеваясь над питанием мне так и не удалось. Шоттки диод параллельно резистору я тоже ставил, уровень ресет выставил верхний, что-то там ещё, имеющее отношение к делу (уже не помню)... Так что ИМХО все идеи я исчерпал... :)

Andrey

Reply to
Andrey Arnold

Alex,

You wrote to Andrey Arnold:

AA>> Я не знаю, как там у ИАРа, а вот у WinAVR пока до выполнения AA>> первой команды явно написанного С-кода дойдёт (инициализация того AA>> же прерывания, к примеру) столько воды может утечь, что AA>> об описанных эффектах можно забыть. AM>

AA>> (В одном из реальных проектов, верхний софт для которого писал не AA>> я, от Ресета до первой С-команды - 6,5мс... AM> Только WinAVR тут ни при чем. Что в стартапе написали, то AM> процессор после сброса и выполняет. Пролог же функции main, AM> генерируемый самим gcc, ничего "лишнего" не содержит, может быть даже AM> вообще пустым.

А вот это я не понял... как это пустым...

Вот я написал программку:

=== Begin of for.c === #include <avr/io.h>

#include <iom128.h>

int main(void) { char i; char j; PORTC = PORTC & ~0x01 | 0x80; for (i=0;i<8;i++) { // j = j +i; }

for (i=7;i<0;i--) { // j = j +i; } } === End of for.c =====

=== Begin of for.lss ===

for.elf: file format elf32-avr

Sections: Idx Name Size VMA LMA File off Algn 0 .data 00000000 00800100 0000010a 0000019e 2**0 CONTENTS, ALLOC, LOAD, DATA 1 .text 0000010a 00000000 00000000 00000094 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .bss 00000000 00800100 0000010a 0000019e 2**0 ALLOC 3 .noinit 00000000 00800100 00800100 0000019e 2**0 CONTENTS 4 .eeprom 00000000 00810000 00810000 0000019e 2**0 CONTENTS 5 .debug_aranges 00000014 00000000 00000000 0000019e 2**0 CONTENTS, READONLY, DEBUGGING 6 .debug_pubnames 0000001b 00000000 00000000 000001b2 2**0 CONTENTS, READONLY, DEBUGGING 7 .debug_info 00000107 00000000 00000000 000001cd 2**0 CONTENTS, READONLY, DEBUGGING 8 .debug_abbrev 00000047 00000000 00000000 000002d4 2**0 CONTENTS, READONLY, DEBUGGING 9 .debug_line 000000af 00000000 00000000 0000031b 2**0 CONTENTS, READONLY, DEBUGGING Disassembly of section .text:

00000000 <__vectors>: 0: 0c 94 46 00 jmp 0x8c 4: 0c 94 63 00 jmp 0xc6 8: 0c 94 63 00 jmp 0xc6 c: 0c 94 63 00 jmp 0xc6 10: 0c 94 63 00 jmp 0xc6 14: 0c 94 63 00 jmp 0xc6 18: 0c 94 63 00 jmp 0xc6 1c: 0c 94 63 00 jmp 0xc6 20: 0c 94 63 00 jmp 0xc6 24: 0c 94 63 00 jmp 0xc6 28: 0c 94 63 00 jmp 0xc6 2c: 0c 94 63 00 jmp 0xc6 30: 0c 94 63 00 jmp 0xc6 34: 0c 94 63 00 jmp 0xc6 38: 0c 94 63 00 jmp 0xc6 3c: 0c 94 63 00 jmp 0xc6 40: 0c 94 63 00 jmp 0xc6 44: 0c 94 63 00 jmp 0xc6 48: 0c 94 63 00 jmp 0xc6 4c: 0c 94 63 00 jmp 0xc6 50: 0c 94 63 00 jmp 0xc6 54: 0c 94 63 00 jmp 0xc6 58: 0c 94 63 00 jmp 0xc6 5c: 0c 94 63 00 jmp 0xc6 60: 0c 94 63 00 jmp 0xc6 64: 0c 94 63 00 jmp 0xc6 68: 0c 94 63 00 jmp 0xc6 6c: 0c 94 63 00 jmp 0xc6 70: 0c 94 63 00 jmp 0xc6 74: 0c 94 63 00 jmp 0xc6 78: 0c 94 63 00 jmp 0xc6 7c: 0c 94 63 00 jmp 0xc6 80: 0c 94 63 00 jmp 0xc6 84: 0c 94 63 00 jmp 0xc6 88: 0c 94 63 00 jmp 0xc6

0000008c <__ctors_end>: 8c: 11 24 eor r1, r1 8e: 1f be out 0x3f, r1 ; 63 90: cf ef ldi r28, 0xFF ; 255 92: d0 e1 ldi r29, 0x10 ; 16 94: de bf out 0x3e, r29 ; 62 96: cd bf out 0x3d, r28 ; 61

00000098 <__do_copy_data>: 98: 11 e0 ldi r17, 0x01 ; 1 9a: a0 e0 ldi r26, 0x00 ; 0 9c: b1 e0 ldi r27, 0x01 ; 1 9e: ea e0 ldi r30, 0x0A ; 10 a0: f1 e0 ldi r31, 0x01 ; 1 a2: 00 e0 ldi r16, 0x00 ; 0 a4: 0b bf out 0x3b, r16 ; 59 a6: 02 c0 rjmp .+4 ; 0xac

000000a8 <.__do_copy_data_loop>: a8: 07 90 elpm r0, Z+ aa: 0d 92 st X+, r0

000000ac <.__do_copy_data_start>: ac: a0 30 cpi r26, 0x00 ; 0 ae: b1 07 cpc r27, r17 b0: d9 f7 brne .-10 ; 0xa8

000000b2 <__do_clear_bss>: b2: 11 e0 ldi r17, 0x01 ; 1 b4: a0 e0 ldi r26, 0x00 ; 0 b6: b1 e0 ldi r27, 0x01 ; 1 b8: 01 c0 rjmp .+2 ; 0xbc

000000ba <.do_clear_bss_loop>: ba: 1d 92 st X+, r1

000000bc <.do_clear_bss_start>: bc: a0 30 cpi r26, 0x00 ; 0 be: b1 07 cpc r27, r17 c0: e1 f7 brne .-8 ; 0xba c2: 0c 94 65 00 jmp 0xca

000000c6 <__bad_interrupt>: c6: 0c 94 00 00 jmp 0x0

------------------------------ И как избавиться тут от

__do_copy_data

?

Другое дело, что в данном случае объём копирования нулевой ...

------------------------------

000000ca <main>: #include <avr/io.h>

#include <iom128.h>

int main(void) { ca: cd ef ldi r28, 0xFD ; 253 cc: d0 e1 ldi r29, 0x10 ; 16 ce: de bf out 0x3e, r29 ; 62 d0: cd bf out 0x3d, r28 ; 61 char i; char j; PORTC = PORTC & ~0x01 | 0x80; d2: 80 91 35 00 lds r24, 0x0035 d6: 98 2f mov r25, r24 d8: 9e 7f andi r25, 0xFE ; 254 da: 80 e8 ldi r24, 0x80 ; 128 dc: 89 2b or r24, r25 de: 80 93 35 00 sts 0x0035, r24 for (i=0;i<8;i++) e2: 19 82 std Y+1, r1 ; 0x01 e4: 89 81 ldd r24, Y+1 ; 0x01 e6: 88 30 cpi r24, 0x08 ; 8 e8: 24 f4 brge .+8 ; 0xf2 ea: 89 81 ldd r24, Y+1 ; 0x01 ec: 8f 5f subi r24, 0xFF ; 255 ee: 89 83 std Y+1, r24 ; 0x01 f0: f9 cf rjmp .-14 ; 0xe4 { // j = j +i; }

for (i=7;i<0;i--) f2: 87 e0 ldi r24, 0x07 ; 7 f4: 89 83 std Y+1, r24 ; 0x01 f6: 89 81 ldd r24, Y+1 ; 0x01 f8: 88 23 and r24, r24 fa: 24 f4 brge .+8 ; 0x104 fc: 89 81 ldd r24, Y+1 ; 0x01 fe: 81 50 subi r24, 0x01 ; 1 100: 89 83 std Y+1, r24 ; 0x01 102: f9 cf rjmp .-14 ; 0xf6 104: 0c 94 84 00 jmp 0x108

00000108 <_exit>: 108: ff cf rjmp .-2 ; 0x108

=== End of for.lss =====

Andrey

Reply to
Andrey Arnold

Hello, Andrey! You wrote to Sergey Brylew on Sun, 08 Apr 2007 21:51:50 +0400:

AA> Hе знаю как у пиков, а у авр сделать ресет обыкновенным входом, AA> или там его отключить - это штатная возможность.

У пиков тоже, но не у всех. Только у тех, что имеют внутренний тактовый генератор. У новых - практически у всех. Но в сабже используется 876-й, который довольно старый. Это же не АВРы, где приходится каждые несколько лет на новый чип переходить из-за снятия с производства старого.

With best regards, Alexander Torres. 2:461/28, E-mail: snipped-for-privacy@yahoo.com [а ночью мы снова, уйдем эскадроном..]

formatting link

Reply to
Alexander Torres

Hello, Sergey! You wrote to Andrey Arnold on Mon, 09 Apr 2007 07:04:37 +0400:

SB> Здравствуй, Andrey!

SB>>> сброс с дребезгом, либо в самом пике при такой комбинации питания и SB>>> сброса что-то происходит, что он потом и на нормальный сброс не SB>>> реагирует.

AA>> Hе знаю как у пиков, а у авр сделать ресет обыкновенным входом, AA>> или там его отключить - это штатная возможность.

SB> Мне при работе с AVR всегда хватало типовых вариантов сброса. SB> Примерно таких-же, как и в пиках. Правда я с этим пиком все же SB> супервизор MCP100 в схемы ставил. Hо особо настораживает в данном SB> случае совпадение: при определенной комбинации включения и варианта SB> компиляции проекта (программном!) процессор перестает реагировать на SB> сброс. Тут уж действительно пахнет сабжем или инопланетянами :))

Нет, немного не так. На сброс он реагирует, в смывсле - сбрасывается. Только это не помогает - программа после этого все равно работает с глюком.

SB> Микрочип пишет, что медленное нарастание питания недопустимо. SB> Hо к чему это приводит - хто знает?

При использовании бронаута - в общем, ни к чему.

Я работю с ПИКами примерно 14 лет, и описанных в этом треде глюков - никогда не наблюдал.

With best regards, Alexander Torres. 2:461/28, E-mail: snipped-for-privacy@yahoo.com [а ночью мы снова, уйдем эскадроном..]

formatting link

Reply to
Alexander Torres

Vladislav,

You wrote to Andrey Arnold:

AA>>>> У меня недавно на каком-то AVR была проблема со слетанием AA>>>> EEPROM,... по моим "разборкам" получилось, что при "дребезге AM>>> Вообще-то для таких случаев существуют супервизоры питания. AM>>> В современных AVR'ках даже встроены в кристалл (BOD). AA>> Тем не менее... без внешнего супервизора избавиться от ошибок в AA>> контрольной сумме ЕЕПРОМ издеваясь над питанием мне так и не AA>> удалось. Шоттки диод параллельно резистору я тоже ставил, уровень AA>> ресет выставил верхний, что-то там ещё, имеющее отношение к делу AA>> (уже не помню)... Так что ИМХО все идеи я исчерпал... :) VB> Ты бы вспомнил, на каком именно AVR наблюдалось ?

ATmega8L с кварцем на 8 МГц.

Andrey

Reply to
Andrey Arnold

Пpивет, Andrey!

*** 09 Apr 07 11:58, Andrey Arnold wrote to Alex Mogilnikov:

AA>>> У меня недавно на каком-то AVR была проблема со слетанием AA>>> EEPROM,... по моим "разборкам" получилось, что при "дребезге

AM>> Вообще-то для таких случаев существуют супервизоры питания. В AM>> современных AVR'ках даже встроены в кристалл (BOD).

AA> Тем не менее... без внешнего супервизора избавиться от ошибок в AA> контрольной сумме ЕЕПРОМ издеваясь над питанием мне так и не удалось. AA> Шоттки диод параллельно резистору я тоже ставил, уровень ресет AA> выставил верхний, что-то там ещё, имеющее отношение к делу (уже не AA> помню)... Так что ИМХО все идеи я исчерпал... :)

Ты бы вспомнил, на каком именно AVR наблюдалось ?

с уважением Владислав

Reply to
Vladislav Baliasov

Alex,

You wrote to Andrey Arnold:

AA>> Тем не менее... без внешнего супервизора избавиться от ошибок в AA>> контрольной сумме ЕЕПРОМ издеваясь над питанием мне так и не AA>> удалось. AM> Уточни, пожалуйста, речь идет о современных ATMEGA'х, или о AM> старинных AT90? А то в старых EEPROM действительно работала ненадежно, AM> сами атмеловцы это признали и что-то там переделывали...

Что в доке заложено я только что сообщил, а что там реально стояло, может и ATMega8, ибо питание там от BP5221A, то бишь пятивольтовое, я смогу уточнить только завтра. Hо думаю, это вопрос второстепенный.

AA>> Шоттки диод параллельно резистору я тоже ставил, уровень ресет AA>> выставил верхний, что-то там ещё, имеющее отношение к делу (уже AA>> не помню)... Так что ИМХО все идеи я исчерпал... :) AM> Издевательства производились в момент записи в EEPROM, или порча AM> данных наблюдалась даже когда ничего не записывалось?

Данные считывались с ошибкой, когда я стартовал одновременно непрерывно издеваясь над напряжением питания. Причём последующие старты с нормальным питающим напряжением повторяли ошибку считывания. То бишь, что-то менялось именно в содержимом ЕЕПРОМ, хотя в этот момент туда по тексту программы ничего не писалось, только считывалось.

ЗЫ. В принципе, где-нибудь в четверг (вторник и среда уже заняты другими делами) я могу ещё какие-нибудь опыты провести. Плата у меня есть.

ЗЗЫ. Hулевая ячейка ЕЕПРОМ не используется. Просто... чтобы не заморачиваться и этой проблемой.

Andrey

Reply to
Andrey Arnold

Alex,

You wrote to Andrey Arnold:

AA>> 00000098 <__do_copy_data>: AA>> И как избавиться тут от __do_copy_data? AM> А чем она тебе мешает? У тебя программа не влезает в ПЗУ?

Тут я очевидно погорячился со словом "избавиться".

Я хочу "избавиться" от неё в этом месте, точнее я хочу предварительно выполнить некие нужные мне инструкции по установке железа, а уже потом пусть долго и нудно (6,5 мс) выполняется __do_copy_data

ЗЫ. А насчёт размеров памяти вопрос в данном случае вообще не стоит.

Andrey

Reply to
Andrey Arnold

Привет Andrey!

09 Apr 07 11:58, Andrey Arnold писал Alex Mogilnikov:

AA> Тем не менее... без внешнего супервизора избавиться от ошибок в AA> контрольной сумме ЕЕПРОМ издеваясь над питанием мне так и не удалось.

Уточни, пожалуйста, речь идет о современных ATMEGA'х, или о старинных AT90? А то в старых EEPROM действительно работала ненадежно, сами атмеловцы это признали и что-то там переделывали...

AA> Шоттки диод параллельно резистору я тоже ставил, уровень ресет AA> выставил верхний, что-то там ещё, имеющее отношение к делу (уже не AA> помню)... Так что ИМХО все идеи я исчерпал... :)

Издевательства производились в момент записи в EEPROM, или порча данных наблюдалась даже когда ничего не записывалось?

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Я удалю твою жажду. Без возможности восстановления.

Reply to
Alex Mogilnikov

Привет Andrey!

09 Apr 07 11:59, Andrey Arnold писал Alex Mogilnikov:

AM>> Пролог же функции main, AM>> генерируемый самим gcc, ничего "лишнего" не содержит, может быть AM>> даже вообще пустым.

AA> А вот это я не понял... как это пустым...

======= test.c ========= void do_smthng(void);

int main(void) { do_smthng(); return 0; } ======================== ======= test.s ========= .file "test.c" .arch avr2 __SREG__ = 0x3f __SP_H__ = 0x3e __SP_L__ = 0x3d __tmp_reg__ = 0 __zero_reg__ = 1 .global __do_copy_data .global __do_clear_bss .text .global main .type main, @function main: /* prologue: frame size=0 */ /* prologue end (size=0) */ rcall do_smthng ldi r24,lo8(0) ldi r25,hi8(0) /* epilogue: frame size=0 */ ret /* epilogue end (size=1) */ /* function main size 4 (3) */ .size main, .-main /* File "test.c": code 4 = 0x0004 ( 3), prologues 0, epilogues 1 */ ========================

Обрати внимание, что первая же сгенеренная компилятором инструкция - вызов do_smthng.

AA> Вот я написал программку:

AA> === Begin of for.c === поскипано AA> === End of for.c =====

AA> === Begin of for.lss ===

AA> 00000000 <__vectors>: AA> 0: 0c 94 46 00 jmp 0x8c AA> 4: 0c 94 63 00 jmp 0xc6

Если заведомо известно, что main не использует ни .data, ни .bss, ни прерывания, что мешает разместить ее код сразу с адреса 0?

AA> 00000098 <__do_copy_data>:

AA> ------------------------------ AA> И как избавиться тут от __do_copy_data?

А чем она тебе мешает? У тебя программа не влезает в ПЗУ?

Линкер хочет видеть (прилинковать) эти символы из-за того что компилятор вставляет в каждом файле вот это:

.global __do_copy_data .global __do_clear_bss

Это фича у него такая. Самое простое - смириться с тем, что в ПЗУ будет лежать несколько десятков ненужных инструкций. Выполнять-то их никто не заставляет! Если все-таки жалко ПЗУ, скажи -nostdlib. Если не хочешь -nostdlib, просто определи где-нибудь эти символы, например в самом хвосте твоего стартапа:

.global __do_copy_data .global __do_clear_bss __do_copy_data: __do_clear_bss:

Линкер увидит, что они определены, и будет счастлив. И ничего лишнего из библиотек тянуть уже не будет. Можно и в сишном файле определить функцию, не содержащую ни одной машинной команды, хотя это уже похоже на извращение. :) Еще у линкера есть опция, с помощью которой можно заставить его считать символ определенным. Во-можно, ей в данном случае можно возпользоваться (но я не уверен, поможет ли, не пробовал).

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Смотрю куда глаза глядят...

Reply to
Alex Mogilnikov

Пpивет, Andrey!

*** 09 Apr 07 15:30, Andrey Arnold wrote to Vladislav Baliasov:

AA>>> Тем не менее... без внешнего супервизора избавиться от ошибок в AA>>> контрольной сумме ЕЕПРОМ издеваясь над питанием мне так и не AA>>> удалось. Шоттки диод параллельно резистору я тоже ставил, AA>>> уровень ресет выставил верхний, что-то там ещё, имеющее AA>>> отношение к делу (уже не помню)... Так что ИМХО все идеи я AA>>> исчерпал... :) VB>> Ты бы вспомнил, на каком именно AVR наблюдалось ?

AA> ATmega8L с кварцем на 8 МГц.

А что происходило, не уточнял ? Я вот помню, что на 90S2313 при плавном падении питания затиралась ячейка, на которую в этот момент указывал EEARL, а когда я стал после всех операций с EEPROM принудительно обнулять адрес и отказался от использования нулевой ячейки, эффект почему-то вообще исчез и ее содержимое перестало искажаться. С мегами до сих пор я не видел таких чудес. Стоило бы посмотреть, что же там такое происходит - что на что искажается, в какой именно момент, и куда при этом указывали регистры адреса. Если, конечно, это не самопроизвольный вход в программу записи или, что маловероятно, но возможно (наблюдалось на 90S) - вход в режим программирования.

с уважением Владислав

Reply to
Vladislav Baliasov

Vladislav,

You wrote to Andrey Arnold:

AA>>>> Тем не менее... без внешнего супервизора избавиться от ошибок в AA>>>> контрольной сумме ЕЕПРОМ издеваясь над питанием мне так и не AA>>>> удалось. Шоттки диод параллельно резистору я тоже ставил, AA>>>> уровень ресет выставил верхний, что-то там ещё, имеющее AA>>>> отношение к делу (уже не помню)... Так что ИМХО все идеи я AA>>>> исчерпал... :) VB>>> Ты бы вспомнил, на каком именно AVR наблюдалось ? AA>> ATmega8L с кварцем на 8 МГц. VB> А что происходило, не уточнял ?

Я занимался в основном проблемами железа, но со слов программиста, системы он не заметил.

VB> Я вот помню, что на 90S2313 при плавном падении питания затиралась VB> ячейка, на которую в этот момент указывал EEARL,

А как такое можно выловить? Пока железячный дебагер стартует, или там, сделает шаг, проходит вечность, и тут ИМХО он не помощник.

VB> а когда я стал после всех операций с EEPROM принудительно обнулять VB> адрес и отказался от использования нулевой ячейки, эффект почему-то VB> вообще исчез и ее содержимое перестало искажаться.

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

А ты "достаточно издевался" над напряжением питания?

VB> С мегами до сих пор я не видел таких чудес. Стоило бы посмотреть, VB> что же там такое происходит - что на что искажается, в какой именно VB> момент, и куда при этом указывали регистры адреса.

Это всё хорошо, вот только как такое можно практически отследить?

VB> Если, конечно, это не самопроизвольный вход в программу записи или, VB> что маловероятно, но возможно (наблюдалось на 90S) - вход в режим VB> программирования.

К сожалению ничего добавить к преждесказанному не могу.

Andrey

Reply to
Andrey Arnold

Хоpошее Кино это вино. Выпьем, Andrey? Воскpесенье Апpель 08 2007 10:21, Andrey Arnold wrote to Sergey Brylew:

SB>> 7805 пpи включении. А заменить 7805 на что-нибyдь посовpеменнее? AA> Я не знаю, как там y ИАРа, а вот y WinAVR пока до выполнения AA> пеpвой команды явно написанного С-кода дойдёт (инициализация того же AA> пpеpывания, к пpимеpy) столько воды может yтечь, что об AA> описанных эффектах можно забыть.

Детсад какой-то, ей-богy. Сишный стаpтап подменить необpазованность не позволяет?

Майкл

Reply to
Michael Mamaev

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.