Robię urządzenie a ARMem LPC2148 i mam problem, być może banalny ale nie
mogę sobie z nim poradzić:
Programuję w C i debuguję JTAG-iem w CrossWorks. Program działa i chciałbym
zrobić kilka testów na urzadzeniu pracującym autonomicznie. Kompiluję
program jako THUMB Flash Release. W debugerze zgłasza mi sie program
zatrzymany gdzieś na początku (zamiast kodu w C jak w wersji debug mam kod
maszynowy). Gdy klupnę F5 (Run) program startuje, ale gdy włączę urządzenie
niezależnie bez kontroli środowiska debugującego progam nie rusza (pewnie
czeka na "F5". Jak zrobić że by ruszał od razu?

--
Piotrek.
http://www.pitlab.pl

do góry

Użytkownik "Piotr Pitlab Laskowski" <p...@p...wp.pl> napisał w
wiadomości news:h0046c$a5s$1@news.wp.pl...
> Programuję w C i debuguję JTAG-iem w CrossWorks. Program działa i
> chciałbym zrobić kilka testów na urzadzeniu pracującym autonomicznie.
> Kompiluję program jako THUMB Flash Release. W debugerze zgłasza mi sie
> program zatrzymany gdzieś na początku (zamiast kodu w C jak w wersji debug
> mam kod maszynowy). Gdy klupnę F5 (Run) program startuje, ale gdy włączę
> urządzenie niezależnie bez kontroli środowiska debugującego progam nie
> rusza (pewnie czeka na "F5". Jak zrobić że by ruszał od razu?
>

rozwiązanie problemu:
http://www.elektroda.pl/rtvforum/topic1241798.html
http://ccgi.rowley.co.uk/support/faq.php?do=article&
articleid=35

dodać dyrektywę STARTUP_FROM_RESET w Preprocessor > Preprocessor Definitions

do góry

> rozwiązanie problemu:
> http://ccgi.rowley.co.uk/support/faq.php?do=article&
articleid=35
> dodać dyrektywę STARTUP_FROM_RESET w Preprocessor > Preprocessor
> Definitions

Dzięki za naprowadzenie na trop.
Dodałem tą dyrektywę jako definicje preprocesora dla pliku "crt0.s" bo tylko
to wygląda mi na "startup code". Jednak nie pomogło.
Sprawdziłem stan linii P0.14 po resecie - był niski, wiec odpiąłem
urządzenie, które korzysta z tej linii i podciagnąłem ją do VCC ale dalej
nic.

Gdy włączę zasilanie i nastepnie podepnę się debuggerem: "Debug > Attach
Debugger" a następnie dam "Break" to widzę że program czeka w pętli na
reset:
<reset_wait>:
EAFFFFFE b 0x0000027C <reset_wait>

Dodam że reset jest zrobiony na układzie MCP100-315. Sprawdzałem
oscyloskopem: po starcie jest niski, po 250ms odpuszcza i jest wysoki, czyli
sprzętowo wszystko OK.

--
Piotrek.
http://www.pitlab.pl

do góry

dodaj tą dyrektywę do globalnych preferencji, nie dla konkretnego pliku;

project => project properties => w drzewku projektu pomiedzy: [Solution
"twoj projekt"] i folderem [Source Files] jest ["twoj projekt"]. Dopiero
tutaj w oknie "Preprocessor options" dodaj dyrektywe.

Użytkownik "Piotr Pitlab Laskowski" <p...@p...wp.pl> napisał w
wiadomości news:h00fuh$hl5$1@news.wp.pl...
>> rozwiązanie problemu:
>> http://ccgi.rowley.co.uk/support/faq.php?do=article&
articleid=35
>> dodać dyrektywę STARTUP_FROM_RESET w Preprocessor > Preprocessor
>> Definitions
>
> Dzięki za naprowadzenie na trop.
> Dodałem tą dyrektywę jako definicje preprocesora dla pliku "crt0.s" bo
> tylko to wygląda mi na "startup code". Jednak nie pomogło.
> Sprawdziłem stan linii P0.14 po resecie - był niski, wiec odpiąłem
> urządzenie, które korzysta z tej linii i podciagnąłem ją do VCC ale dalej
> nic.
>
> Gdy włączę zasilanie i nastepnie podepnę się debuggerem: "Debug > Attach
> Debugger" a następnie dam "Break" to widzę że program czeka w pętli na
> reset:
> <reset_wait>:
> EAFFFFFE b 0x0000027C <reset_wait>
>
> Dodam że reset jest zrobiony na układzie MCP100-315. Sprawdzałem
> oscyloskopem: po starcie jest niski, po 250ms odpuszcza i jest wysoki,
> czyli sprzętowo wszystko OK.
>
> --
> Piotrek.
> http://www.pitlab.pl
>

do góry

> dodaj tą dyrektywę do globalnych preferencji, nie dla konkretnego pliku;
> project => project properties => w drzewku projektu pomiedzy: [Solution
> "twoj projekt"] i folderem [Source Files] jest ["twoj projekt"]. Dopiero
> tutaj w oknie "Preprocessor options" dodaj dyrektywe.

Wielkie dzięki, teraz ruszyło :-)

--
Piotrek.
http://www.pitlab.pl

do góry