Sign in
Search adsp
Subscribe to adsp
adsp by Keywords
AD1819 | AD7332 | ADSP-2106 | ADSP-21060 | ADSP-21065L | ADSP-2116 | ADSP-21160M | ADSP-2181 | ADSP-218x | ADSP-219 | ADSP-2199 | ADSP219 | BF531 | BF532 | BF533 | BF535 | Blackfin | FFT | JTAG | LDF | SDRAM | SHARC | SPORT | UART | VDSP++ | VisualDSP
Discussion Groups
Discussion Groups | Analog Devices DSPs | RE: 21065L, Running Code goes aperiodic to HW boot loader?
Technical discussions related to Analog Devices DSPs (including Blackfin, TigerSHARC, SHARC and ADSP-21xx DSPs).
21065L, Running Code goes aperiodic to HW boot loader? - John Henry - Sep 13 16:39:00 2005
Hi,
Peculiar situation arising.
Aperiodically, when running the full product code, I get reset into
the HW 256 byte boot loader. I know for a fact that it is the HW boot
loader because it first loads a product specific boot loader I wrote,
that has a given running mode that is lost as soon as it loads any of
the product codes. Remember, I'm the one that re-wrote the boot
loader, and based on a given customer selection which is sensed on the
flag pins, I load code from any of a given locations in the eeprom.
Once that code gets loaded, there is no way to get back to the boot
loader unless there is a HW reset.
I do not get this all of the time.
It can occur when I am running the emulator, and it can also occur
when I am running with my code burned into the PROM.
My question is this:
What can cause a running application to invoke the HW boot loader to run?
Is there an assembly language statement in code that can do this? or a
read or write to a specific DM or PM space that can cause this?
Or is the only way to do this would be HW based, as in the power line
dipping low enough to force a HW reset, or a reset line???
Thanks for your help and support in advance as always.
Hope all are doing well and fine.
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
Re: 21065L, Running Code goes aperiodic to HW boot loader? - Jon Harris - Sep 14 0:49:00 2005
As far as I know, there are 3 ways to reset the 21065L:
1. The hardware RESET pin
2. via a JTAG command
3. The SRST bit in SYSCON.
#3 could happen with a suprious write, including in multi-processor memory
space.
Other than that, I suppose you could end up in your boot loader due to an
erroneous jump. Some chips have a watchdog that can reset them, but the 21065L
is not one of them.
--- John Henry <jshenry1963@jshe...> wrote:
> Hi,
> Peculiar situation arising.
> Aperiodically, when running the full product code, I get reset into
> the HW 256 byte boot loader. I know for a fact that it is the HW boot
> loader because it first loads a product specific boot loader I wrote,
> that has a given running mode that is lost as soon as it loads any of
> the product codes. Remember, I'm the one that re-wrote the boot
> loader, and based on a given customer selection which is sensed on the
> flag pins, I load code from any of a given locations in the eeprom.
> Once that code gets loaded, there is no way to get back to the boot
> loader unless there is a HW reset.
>
> I do not get this all of the time.
> It can occur when I am running the emulator, and it can also occur
> when I am running with my code burned into the PROM.
> My question is this:
> What can cause a running application to invoke the HW boot loader to run?
> Is there an assembly language statement in code that can do this? or a
> read or write to a specific DM or PM space that can cause this?
> Or is the only way to do this would be HW based, as in the power line
> dipping low enough to force a HW reset, or a reset line???
>
> Thanks for your help and support in advance as always.
>
> Hope all are doing well and fine.
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
1. The hardware RESET pin
2. via a JTAG command
3. The SRST bit in SYSCON.
#3 could happen with a suprious write, including in multi-processor memory
space.
Other than that, I suppose you could end up in your boot loader due to an
erroneous jump. Some chips have a watchdog that can reset them, but the 21065L
is not one of them.
--- John Henry <jshenry1963@jshe...> wrote:
> Hi,
> Peculiar situation arising.
> Aperiodically, when running the full product code, I get reset into
> the HW 256 byte boot loader. I know for a fact that it is the HW boot
> loader because it first loads a product specific boot loader I wrote,
> that has a given running mode that is lost as soon as it loads any of
> the product codes. Remember, I'm the one that re-wrote the boot
> loader, and based on a given customer selection which is sensed on the
> flag pins, I load code from any of a given locations in the eeprom.
> Once that code gets loaded, there is no way to get back to the boot
> loader unless there is a HW reset.
>
> I do not get this all of the time.
> It can occur when I am running the emulator, and it can also occur
> when I am running with my code burned into the PROM.
> My question is this:
> What can cause a running application to invoke the HW boot loader to run?
> Is there an assembly language statement in code that can do this? or a
> read or write to a specific DM or PM space that can cause this?
> Or is the only way to do this would be HW based, as in the power line
> dipping low enough to force a HW reset, or a reset line???
>
> Thanks for your help and support in advance as always.
>
> Hope all are doing well and fine.
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
RE: 21065L, Running Code goes aperiodic to HW boot loader? - Bernhard Holzmayer - Sep 14 3:47:00 2005
Hi John,
don't know if this helps, but...
while working on a 21161, I happened to experience spurious resets.
Trying to track it down, led me to a processor anomaly having to do with
RTI (db) instructions.
I guess this isn't of interest for you, since you're on another device.
However, the effect was, that RTI worked with a wrong return address.
Every now and then, this led to a reset.
Check, if addressing/calling the reset vector leads to a similar behaviour.
If yes, I'd suggest "instrumenting" your code around the reset vector,
just to make sure that your software is not unintentionally resetting.
Since this happens aperiodically, I guess that it depends on a certain
interrupt,
maybe on a nesting condition where two interrupts stack.
To verify such a condition, you might want to increase the interrupt
frequency of
each interrupt and watch the event's frequency.
In my situation, it happened every 20 minutes or so, but I could speed it
up
by decreasing the interval of a certain timer. So I found it, finally.
-----Original Message-----
From: John Henry [SMTP:jshenry1963@jshe...]
Sent: Tuesday, September 13, 2005 10:39 PM
To: adsp@adsp...
Subject: [adsp] 21065L, Running Code goes aperiodic to HW boot loader?
Hi,
Peculiar situation arising.
Aperiodically, when running the full product code, I get reset into
the HW 256 byte boot loader. I know for a fact that it is the HW boot
loader because it first loads a product specific boot loader I wrote,
that has a given running mode that is lost as soon as it loads any of
the product codes. Remember, I'm the one that re-wrote the boot
loader, and based on a given customer selection which is sensed on the
flag pins, I load code from any of a given locations in the eeprom.
Once that code gets loaded, there is no way to get back to the boot
loader unless there is a HW reset.
I do not get this all of the time.
It can occur when I am running the emulator, and it can also occur
when I am running with my code burned into the PROM.
My question is this:
What can cause a running application to invoke the HW boot loader to run?
Is there an assembly language statement in code that can do this? or a
read or write to a specific DM or PM space that can cause this?
Or is the only way to do this would be HW based, as in the power line
dipping low enough to force a HW reset, or a reset line???
Thanks for your help and support in advance as always.
Hope all are doing well and fine. ----------------------------------------------------------------------------
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.
Ueber das Internet versandte E-Mails koennen leicht unter fremden Namen
erstellt oder manipuliert werden. Aus diesem Grunde bitten wir um
Verstaendnis, dass wir zu Ihrem und unserem Schutz die rechtliche
Verbindlichkeit der vorstehenden Erklaerungen und Aeusserungen
ausschliessen.
This E-mail may contain confidential and/or privileged information. If
you are not the intended recipient or have received this E-mail in
error, please notify the sender immediately and destroy this E-mail. Any
unauthorized copying, disclosure or distribution of the material in this
E-mail is strictly forbidden.
E-mails via Internet can easily be prepared or manipulated by third
persons. For this reason we trust you will understand that, for your own
and our protection, we rule out the legal validity of the foregoing
statements and comments.
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
don't know if this helps, but...
while working on a 21161, I happened to experience spurious resets.
Trying to track it down, led me to a processor anomaly having to do with
RTI (db) instructions.
I guess this isn't of interest for you, since you're on another device.
However, the effect was, that RTI worked with a wrong return address.
Every now and then, this led to a reset.
Check, if addressing/calling the reset vector leads to a similar behaviour.
If yes, I'd suggest "instrumenting" your code around the reset vector,
just to make sure that your software is not unintentionally resetting.
Since this happens aperiodically, I guess that it depends on a certain
interrupt,
maybe on a nesting condition where two interrupts stack.
To verify such a condition, you might want to increase the interrupt
frequency of
each interrupt and watch the event's frequency.
In my situation, it happened every 20 minutes or so, but I could speed it
up
by decreasing the interval of a certain timer. So I found it, finally.
-----Original Message-----
From: John Henry [SMTP:jshenry1963@jshe...]
Sent: Tuesday, September 13, 2005 10:39 PM
To: adsp@adsp...
Subject: [adsp] 21065L, Running Code goes aperiodic to HW boot loader?
Hi,
Peculiar situation arising.
Aperiodically, when running the full product code, I get reset into
the HW 256 byte boot loader. I know for a fact that it is the HW boot
loader because it first loads a product specific boot loader I wrote,
that has a given running mode that is lost as soon as it loads any of
the product codes. Remember, I'm the one that re-wrote the boot
loader, and based on a given customer selection which is sensed on the
flag pins, I load code from any of a given locations in the eeprom.
Once that code gets loaded, there is no way to get back to the boot
loader unless there is a HW reset.
I do not get this all of the time.
It can occur when I am running the emulator, and it can also occur
when I am running with my code burned into the PROM.
My question is this:
What can cause a running application to invoke the HW boot loader to run?
Is there an assembly language statement in code that can do this? or a
read or write to a specific DM or PM space that can cause this?
Or is the only way to do this would be HW based, as in the power line
dipping low enough to force a HW reset, or a reset line???
Thanks for your help and support in advance as always.
Hope all are doing well and fine. ----------------------------------------------------------------------------
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.
Ueber das Internet versandte E-Mails koennen leicht unter fremden Namen
erstellt oder manipuliert werden. Aus diesem Grunde bitten wir um
Verstaendnis, dass wir zu Ihrem und unserem Schutz die rechtliche
Verbindlichkeit der vorstehenden Erklaerungen und Aeusserungen
ausschliessen.
This E-mail may contain confidential and/or privileged information. If
you are not the intended recipient or have received this E-mail in
error, please notify the sender immediately and destroy this E-mail. Any
unauthorized copying, disclosure or distribution of the material in this
E-mail is strictly forbidden.
E-mails via Internet can easily be prepared or manipulated by third
persons. For this reason we trust you will understand that, for your own
and our protection, we rule out the legal validity of the foregoing
statements and comments.
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
R: 21065L, Running Code goes aperiodic to HW boot loader? - Fabrizio Nicolini - Sep 14 7:11:00 2005
Hi,
I experienced spurious resets working on a 21161.
I use the emulator to load the code.
I thought it was an emulator problem, but I am note sure.
Sometime the emulator halts and I can read 0xFFFF... on all memory and
variables.
But the processor go on !!!
If I press the run key, the debugger work well, but I don't know what it
happened (dsp reset ...)
I don't know if the problem can happen without the emulator.
Bernhard, the problem you experienced is something similar ?
Thanks for your help in advance.
Fabrizio
>-----Messaggio originale-----
>Da: adsp@adsp...
>[mailto:adsp@adsp...]Per conto di
>Bernhard Holzmayer
>Inviato: mercoledi 14 settembre 2005 9.48
>A: adsp@adsp...
>Oggetto: RE: [adsp] 21065L, Running Code goes aperiodic
>to HW boot
>loader? >Hi John,
>
>don't know if this helps, but...
>
>while working on a 21161, I happened to experience
>spurious resets.
>Trying to track it down, led me to a processor anomaly
>having to do with
>RTI (db) instructions.
>I guess this isn't of interest for you, since you're on
>another device.
>
>However, the effect was, that RTI worked with a wrong
>return address.
>Every now and then, this led to a reset.
>
>Check, if addressing/calling the reset vector leads to a
>similar behaviour.
>If yes, I'd suggest "instrumenting" your code around the
>reset vector,
>just to make sure that your software is not
>unintentionally resetting.
>
>Since this happens aperiodically, I guess that it
>depends on a certain
>interrupt,
>maybe on a nesting condition where two interrupts stack.
>To verify such a condition, you might want to increase
>the interrupt
>frequency of
>each interrupt and watch the event's frequency.
>
>In my situation, it happened every 20 minutes or so, but
>I could speed it
>up
>by decreasing the interval of a certain timer. So I
>found it, finally.
>
>-----Original Message-----
>From: John Henry [SMTP:jshenry1963@jshe...]
>Sent: Tuesday, September 13, 2005 10:39 PM
>To: adsp@adsp...
>Subject: [adsp] 21065L, Running Code goes aperiodic to
>HW boot loader?
>
>Hi,
>Peculiar situation arising.
>Aperiodically, when running the full product code, I get
>reset into
>the HW 256 byte boot loader. I know for a fact that it
>is the HW boot
>loader because it first loads a product specific boot
>loader I wrote,
>that has a given running mode that is lost as soon as it
>loads any of
>the product codes. Remember, I'm the one that re-wrote the boot
>loader, and based on a given customer selection which is
>sensed on the
>flag pins, I load code from any of a given locations in
>the eeprom.
>Once that code gets loaded, there is no way to get back
>to the boot
>loader unless there is a HW reset.
>
>I do not get this all of the time.
>It can occur when I am running the emulator, and it can
>also occur
>when I am running with my code burned into the PROM.
>My question is this:
>What can cause a running application to invoke the HW
>boot loader to run?
>Is there an assembly language statement in code that can
>do this? or a
>read or write to a specific DM or PM space that can cause this?
>Or is the only way to do this would be HW based, as in
>the power line
>dipping low enough to force a HW reset, or a reset line???
>
>Thanks for your help and support in advance as always.
>
>Hope all are doing well and fine. >---------------------------------------------------------
>-------------------
>Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
>Informationen. Wenn Sie nicht der richtige Adressat sind
>oder diese
>E-Mail irrtuemlich erhalten haben, informieren Sie bitte
>sofort den
>Absender und vernichten Sie diese Mail. Das unerlaubte
>Kopieren sowie
>die unbefugte Weitergabe dieser Mail ist nicht gestattet.
>Ueber das Internet versandte E-Mails koennen leicht
>unter fremden Namen
>erstellt oder manipuliert werden. Aus diesem Grunde bitten wir um
>Verstaendnis, dass wir zu Ihrem und unserem Schutz die rechtliche
>Verbindlichkeit der vorstehenden Erklaerungen und Aeusserungen
>ausschliessen.
>
>This E-mail may contain confidential and/or privileged
>information. If
>you are not the intended recipient or have received this
>E-mail in
>error, please notify the sender immediately and destroy
>this E-mail. Any
>unauthorized copying, disclosure or distribution of the
>material in this
>E-mail is strictly forbidden.
>E-mails via Internet can easily be prepared or
>manipulated by third
>persons. For this reason we trust you will understand
>that, for your own
>and our protection, we rule out the legal validity of
>the foregoing
>statements and comments.
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
I experienced spurious resets working on a 21161.
I use the emulator to load the code.
I thought it was an emulator problem, but I am note sure.
Sometime the emulator halts and I can read 0xFFFF... on all memory and
variables.
But the processor go on !!!
If I press the run key, the debugger work well, but I don't know what it
happened (dsp reset ...)
I don't know if the problem can happen without the emulator.
Bernhard, the problem you experienced is something similar ?
Thanks for your help in advance.
Fabrizio
>-----Messaggio originale-----
>Da: adsp@adsp...
>[mailto:adsp@adsp...]Per conto di
>Bernhard Holzmayer
>Inviato: mercoledi 14 settembre 2005 9.48
>A: adsp@adsp...
>Oggetto: RE: [adsp] 21065L, Running Code goes aperiodic
>to HW boot
>loader? >Hi John,
>
>don't know if this helps, but...
>
>while working on a 21161, I happened to experience
>spurious resets.
>Trying to track it down, led me to a processor anomaly
>having to do with
>RTI (db) instructions.
>I guess this isn't of interest for you, since you're on
>another device.
>
>However, the effect was, that RTI worked with a wrong
>return address.
>Every now and then, this led to a reset.
>
>Check, if addressing/calling the reset vector leads to a
>similar behaviour.
>If yes, I'd suggest "instrumenting" your code around the
>reset vector,
>just to make sure that your software is not
>unintentionally resetting.
>
>Since this happens aperiodically, I guess that it
>depends on a certain
>interrupt,
>maybe on a nesting condition where two interrupts stack.
>To verify such a condition, you might want to increase
>the interrupt
>frequency of
>each interrupt and watch the event's frequency.
>
>In my situation, it happened every 20 minutes or so, but
>I could speed it
>up
>by decreasing the interval of a certain timer. So I
>found it, finally.
>
>-----Original Message-----
>From: John Henry [SMTP:jshenry1963@jshe...]
>Sent: Tuesday, September 13, 2005 10:39 PM
>To: adsp@adsp...
>Subject: [adsp] 21065L, Running Code goes aperiodic to
>HW boot loader?
>
>Hi,
>Peculiar situation arising.
>Aperiodically, when running the full product code, I get
>reset into
>the HW 256 byte boot loader. I know for a fact that it
>is the HW boot
>loader because it first loads a product specific boot
>loader I wrote,
>that has a given running mode that is lost as soon as it
>loads any of
>the product codes. Remember, I'm the one that re-wrote the boot
>loader, and based on a given customer selection which is
>sensed on the
>flag pins, I load code from any of a given locations in
>the eeprom.
>Once that code gets loaded, there is no way to get back
>to the boot
>loader unless there is a HW reset.
>
>I do not get this all of the time.
>It can occur when I am running the emulator, and it can
>also occur
>when I am running with my code burned into the PROM.
>My question is this:
>What can cause a running application to invoke the HW
>boot loader to run?
>Is there an assembly language statement in code that can
>do this? or a
>read or write to a specific DM or PM space that can cause this?
>Or is the only way to do this would be HW based, as in
>the power line
>dipping low enough to force a HW reset, or a reset line???
>
>Thanks for your help and support in advance as always.
>
>Hope all are doing well and fine. >---------------------------------------------------------
>-------------------
>Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
>Informationen. Wenn Sie nicht der richtige Adressat sind
>oder diese
>E-Mail irrtuemlich erhalten haben, informieren Sie bitte
>sofort den
>Absender und vernichten Sie diese Mail. Das unerlaubte
>Kopieren sowie
>die unbefugte Weitergabe dieser Mail ist nicht gestattet.
>Ueber das Internet versandte E-Mails koennen leicht
>unter fremden Namen
>erstellt oder manipuliert werden. Aus diesem Grunde bitten wir um
>Verstaendnis, dass wir zu Ihrem und unserem Schutz die rechtliche
>Verbindlichkeit der vorstehenden Erklaerungen und Aeusserungen
>ausschliessen.
>
>This E-mail may contain confidential and/or privileged
>information. If
>you are not the intended recipient or have received this
>E-mail in
>error, please notify the sender immediately and destroy
>this E-mail. Any
>unauthorized copying, disclosure or distribution of the
>material in this
>E-mail is strictly forbidden.
>E-mails via Internet can easily be prepared or
>manipulated by third
>persons. For this reason we trust you will understand
>that, for your own
>and our protection, we rule out the legal validity of
>the foregoing
>statements and comments.
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
Re: R: 21065L, Running Code goes aperiodic to HW boot loader? - Mike Rosing - Sep 14 9:06:00 2005
On Wed, 14 Sep 2005, Fabrizio Nicolini wrote:
> Hi,
>
> I experienced spurious resets working on a 21161.
> I use the emulator to load the code.
> I thought it was an emulator problem, but I am note sure.
> Sometime the emulator halts and I can read 0xFFFF... on all memory and
> variables.
> But the processor go on !!!
> If I press the run key, the debugger work well, but I don't know what it
> happened (dsp reset ...)
>
> I don't know if the problem can happen without the emulator.
>
> Bernhard, the problem you experienced is something similar ?
> Thanks for your help in advance.
>
Howdy Fabrizio,
that could be an emulator connection problem. Check the physical
connections and ground between target and PC. Sounds like the processor
is ignoring the JTAG port, you are not really halting it. Does it stop at
breakpoints ok? If so, you might have to set a break point when you check
for some external flag pin, then halt with button rather than jtag.
Patience, persistence, truth,
Dr. mike
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
> Hi,
>
> I experienced spurious resets working on a 21161.
> I use the emulator to load the code.
> I thought it was an emulator problem, but I am note sure.
> Sometime the emulator halts and I can read 0xFFFF... on all memory and
> variables.
> But the processor go on !!!
> If I press the run key, the debugger work well, but I don't know what it
> happened (dsp reset ...)
>
> I don't know if the problem can happen without the emulator.
>
> Bernhard, the problem you experienced is something similar ?
> Thanks for your help in advance.
>
Howdy Fabrizio,
that could be an emulator connection problem. Check the physical
connections and ground between target and PC. Sounds like the processor
is ignoring the JTAG port, you are not really halting it. Does it stop at
breakpoints ok? If so, you might have to set a break point when you check
for some external flag pin, then halt with button rather than jtag.
Patience, persistence, truth,
Dr. mike
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
Re: R: 21065L, Running Code goes aperiodic to HW boot loader? - Bernhard Holzmayer - Sep 14 9:40:00 2005
---------- Weitergeleitete Nachricht ----------
Subject: Re: R: [adsp] 21065L, Running Code goes aperiodic to HW boot loader?
Date: Mittwoch, 14. September 2005 15:39
From: Bernhard Holzmayer <Holzmayer.Bernhard@Holz...>
To: f...@f.ni...
Am Mittwoch, 14. September 2005 13:11 schrieb Fabrizio Nicolini:
> Hi,
>
> I experienced spurious resets working on a 21161.
> I use the emulator to load the code.
> I thought it was an emulator problem, but I am note sure.
> Sometime the emulator halts and I can read 0xFFFF... on all memory and
> variables.
> But the processor go on !!!
> If I press the run key, the debugger work well, but I don't know what it
> happened (dsp reset ...)
>
> I don't know if the problem can happen without the emulator.
>
> Bernhard, the problem you experienced is something similar ?
Maybe yes.
I mistrusted everything in the end!
However, it turned out to be the problem I described in the other post.
For reasons see ADI's anomaly list.
Then, there were different problems with the VDK causing ISR errors.
They should have vanished since.
It was never (!) a hardware issue or emulator specific problem.
> Thanks for your help in advance.
You're welcome.
Bernhard
-------------------------------------------------------
----------------------------------------------------------------------------
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.
Ueber das Internet versandte E-Mails koennen leicht unter fremden Namen
erstellt oder manipuliert werden. Aus diesem Grunde bitten wir um
Verstaendnis, dass wir zu Ihrem und unserem Schutz die rechtliche
Verbindlichkeit der vorstehenden Erklaerungen und Aeusserungen
ausschliessen.
This E-mail may contain confidential and/or privileged information. If
you are not the intended recipient or have received this E-mail in
error, please notify the sender immediately and destroy this E-mail. Any
unauthorized copying, disclosure or distribution of the material in this
E-mail is strictly forbidden.
E-mails via Internet can easily be prepared or manipulated by third
persons. For this reason we trust you will understand that, for your own
and our protection, we rule out the legal validity of the foregoing
statements and comments.
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
R: R: 21065L, Running Code goes aperiodic to HW boot loader? - Fabrizio Nicolini - Sep 14 9:47:00 2005
Hi Mike,
thanks for your reply.
Breakpoints work properly.
The problem is sporadic (every 10 min or more) and happens only on the
21161.
The same PC and emulator connected on a 21065L board works properly.
Could it be a problem with our new 21161 board design ? (the JTAG connection
or something similar)
Fabrizio >-----Messaggio originale-----
>Da: adsp@adsp...
>[mailto:adsp@adsp...]Per conto di Mike
>Rosing
>Inviato: mercoledi 14 settembre 2005 15.07
>A: f...@f.ni...
>Cc: adsp@adsp...
>Oggetto: Re: R: [adsp] 21065L, Running Code goes
>aperiodic to HW boot
>loader? >On Wed, 14 Sep 2005, Fabrizio Nicolini wrote:
>
>> Hi,
>>
>> I experienced spurious resets working on a 21161.
>> I use the emulator to load the code.
>> I thought it was an emulator problem, but I am note sure.
>> Sometime the emulator halts and I can read 0xFFFF...
>on all memory and
>> variables.
>> But the processor go on !!!
>> If I press the run key, the debugger work well, but I
>don't know what it
>> happened (dsp reset ...)
>>
>> I don't know if the problem can happen without the emulator.
>>
>> Bernhard, the problem you experienced is something similar ?
>> Thanks for your help in advance.
>>
>Howdy Fabrizio,
>
>that could be an emulator connection problem. Check the physical
>connections and ground between target and PC. Sounds
>like the processor
>is ignoring the JTAG port, you are not really halting
>it. Does it stop at
>breakpoints ok? If so, you might have to set a break
>point when you check
>for some external flag pin, then halt with button rather
>than jtag.
>
>Patience, persistence, truth,
>Dr. mike
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
thanks for your reply.
Breakpoints work properly.
The problem is sporadic (every 10 min or more) and happens only on the
21161.
The same PC and emulator connected on a 21065L board works properly.
Could it be a problem with our new 21161 board design ? (the JTAG connection
or something similar)
Fabrizio >-----Messaggio originale-----
>Da: adsp@adsp...
>[mailto:adsp@adsp...]Per conto di Mike
>Rosing
>Inviato: mercoledi 14 settembre 2005 15.07
>A: f...@f.ni...
>Cc: adsp@adsp...
>Oggetto: Re: R: [adsp] 21065L, Running Code goes
>aperiodic to HW boot
>loader? >On Wed, 14 Sep 2005, Fabrizio Nicolini wrote:
>
>> Hi,
>>
>> I experienced spurious resets working on a 21161.
>> I use the emulator to load the code.
>> I thought it was an emulator problem, but I am note sure.
>> Sometime the emulator halts and I can read 0xFFFF...
>on all memory and
>> variables.
>> But the processor go on !!!
>> If I press the run key, the debugger work well, but I
>don't know what it
>> happened (dsp reset ...)
>>
>> I don't know if the problem can happen without the emulator.
>>
>> Bernhard, the problem you experienced is something similar ?
>> Thanks for your help in advance.
>>
>Howdy Fabrizio,
>
>that could be an emulator connection problem. Check the physical
>connections and ground between target and PC. Sounds
>like the processor
>is ignoring the JTAG port, you are not really halting
>it. Does it stop at
>breakpoints ok? If so, you might have to set a break
>point when you check
>for some external flag pin, then halt with button rather
>than jtag.
>
>Patience, persistence, truth,
>Dr. mike
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
Re: R: R: 21065L, Running Code goes aperiodic to HW boot loader? - Mike Rosing - Sep 14 11:40:00 2005
On Wed, 14 Sep 2005, Fabrizio Nicolini wrote:
> Hi Mike,
>
> thanks for your reply.
>
> Breakpoints work properly.
> The problem is sporadic (every 10 min or more) and happens only on the
> 21161.
> The same PC and emulator connected on a 21065L board works properly.
> Could it be a problem with our new 21161 board design ? (the JTAG connection
> or something similar)
>
Howdy Fabrizio,
I'd check out the anomaly posted by Bernhard first. But definitly scope
your TMS, TCK and TDO to be sure. If TDO looks good when the emulator
looks bad, it's software on the PC. If TDO isn't quite getting below 2
volts now and then, you'll know where to look! Good luck, it will be
challanging.
Patience, persistence, truth,
Dr. mike
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )
> Hi Mike,
>
> thanks for your reply.
>
> Breakpoints work properly.
> The problem is sporadic (every 10 min or more) and happens only on the
> 21161.
> The same PC and emulator connected on a 21065L board works properly.
> Could it be a problem with our new 21161 board design ? (the JTAG connection
> or something similar)
>
Howdy Fabrizio,
I'd check out the anomaly posted by Bernhard first. But definitly scope
your TMS, TCK and TDO to be sure. If TDO looks good when the emulator
looks bad, it's software on the PC. If TDO isn't quite getting below 2
volts now and then, you'll know where to look! Good luck, it will be
challanging.
Patience, persistence, truth,
Dr. mike
(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )