Hi all

During debugging my code, I often end up all of a sudden in a "hang"
kind of situation in calls where nothing really should go wrong. Hitting
the pause button then showes that the MCU sits in a loop at the
reset_wait label.

I'm new to ARM7. I figure that my MCU went into a reset unexpectedly? Is
there a way I can find out what part of my code caused the reset
(provided I interpret this right)?

TIA

Markus Start a New Thread

Hi,

> During debugging my code, I often end up all of a sudden in a "hang"
> kind of situation in calls where nothing really should go wrong.
> Hitting the pause button then showes that the MCU sits in a loop at the
> reset_wait label.
>
> I'm new to ARM7. I figure that my MCU went into a reset unexpectedly?

Could be. Are you using pre-canned projects on your target board? Is the
target board your own or is it an off-the-shelf eval board? Did you set the
crystal frequency correctly in the IDE for your board? What JTAG adapter
are you using?

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors Start a New Thread

I'm (unfortunately) using a Chameleon Board (from EBV, but I figure it
was developped by the Frauenhofer Institute). The unfortunate part
relates to the fact that no other people here seem to use this board.

For the JTAG I use the Amontec Tiny USB. The project for the moment is
mostly the "emactest" example from NXT which I try to modify into
something useable. The crystall frequency is set to 6Mhz and that's the
same like the crystal on the board.

The board uses an LPC2378 with a DP83848 Phy from National, alas exactly
the same chip as what's used in the emac example from NXP. I currently
don't use any other features of the board. Our own board will be
indentical with regard to this and we will aditionally use the ADC, one
PWM channel and four GPIO lines. None of these things are touched in the
software yet though.

Markus

Paul Curtis schrieb:
>
> Hi,
>
> > During debugging my code, I often end up all of a sudden in a "hang"
> > kind of situation in calls where nothing really should go wrong.
> > Hitting the pause button then showes that the MCU sits in a loop at the
> > reset_wait label.
> >
> > I'm new to ARM7. I figure that my MCU went into a reset unexpectedly?
>
> Could be. Are you using pre-canned projects on your target board? Is the
> target board your own or is it an off-the-shelf eval board? Did you
> set the
> crystal frequency correctly in the IDE for your board? What JTAG adapter
> are you using?
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
> Start a New Thread

Markus,

> I'm (unfortunately) using a Chameleon Board (from EBV, but I figure it
> was developped by the Frauenhofer Institute). The unfortunate part
> relates to the fact that no other people here seem to use this board.
>
> For the JTAG I use the Amontec Tiny USB. The project for the moment is
> mostly the "emactest" example from NXT which I try to modify into
> something useable. The crystall frequency is set to 6Mhz and that's the
> same like the crystal on the board.

You will need to reduce the JTAG TCK frequency of the JTAGKey-Tiny by
selecting the JTAGKey in the Targets window using the Properties Window to
increase the JTAG clock divider. The NXP devices use the return clock which
the Tiny doesn't support, so you have to throttle it back or use something
that does support RTCK (such as the CrossConnect or later J-Links).

http://ccgi.rowley.co.uk/support/faq.php?do=article&articleid=5

The clock divider property is available for FT2232 devices (such as the
Signalyzer and JTAGKey).

Regards,

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors Start a New Thread

Paul,

Thanks for your quick reply. I don't hesitate to get a CrossConnect if
that solves the problem. We are shortly before ordering Crossworks btw -
outstanding support here and product!

Note though, I experience the same behaviour with a divider setting of
40, well even with 200 or 255.... So do you think this is still
possible? It apears like it happens always after the fourth time I hit
the same breakpoint within the MAC isr routine. The routine then works
ok (interstingly it gets called even tough MAC_INTSTATUS == 0) to its
end wehre it executes then
ctl_global_interrupts_un_re_enable_from_isr(); followed by VICVectAddr 0; /* Acknowledge Interrupt */ is called ok, and then the
"return" statement jumps intoVIC_irqhandler.s line 56 (bx r1) with r1 in
this situation only containing the address of the next network
descriptor in MAC ram instead of the propper address (an invalid address
I figure and I figure the reason for the resett right?) So, something
seems really odd here.

Should I eventually not allow recursive interrupts in this routine? I
think I still have problems with changing the original code to use the
ctl library routines for IRQ treatement....

Anything else I could check? Any ideas?

Markus

Paul Curtis schrieb:
>
> Markus,
>
> > I'm (unfortunately) using a Chameleon Board (from EBV, but I figure it
> > was developped by the Frauenhofer Institute). The unfortunate part
> > relates to the fact that no other people here seem to use this board.
> >
> > For the JTAG I use the Amontec Tiny USB. The project for the moment is
> > mostly the "emactest" example from NXT which I try to modify into
> > something useable. The crystall frequency is set to 6Mhz and that's the
> > same like the crystal on the board.
>
> You will need to reduce the JTAG TCK frequency of the JTAGKey-Tiny by
> selecting the JTAGKey in the Targets window using the Properties Window to
> increase the JTAG clock divider. The NXP devices use the return clock
> which
> the Tiny doesn't support, so you have to throttle it back or use something
> that does support RTCK (such as the CrossConnect or later J-Links).
>
> http://ccgi.rowley.co.uk/support/faq.php?do=article&articleid=5
> The clock divider property is available for FT2232 devices (such as the
> Signalyzer and JTAGKey).
>
> Regards,
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
> Start a New Thread

Hi Markus,

> Note though, I experience the same behaviour with a divider setting of
> 40, well even with 200 or 255.... So do you think this is still
> possible?

Probably not the cause, no.

? It apears like it happens always after the fourth time I hit
> the same breakpoint within the MAC isr routine. The routine then works
> ok (interstingly it gets called even tough MAC_INTSTATUS == 0) to its
> end wehre it executes then
> ctl_global_interrupts_un_re_enable_from_isr(); followed by VICVectAddr
> > 0; /* Acknowledge Interrupt */ is called ok, and then the
> "return" statement jumps into VIC_irqhandler.s line 56 (bx r1) with r1
> in this situation only containing the address of the next network
> descriptor in MAC ram instead of the propper address (an invalid
> address I figure and I figure the reason for the resett right?) So,
something
> seems really odd here.

Hmm. Given you're modifying something that worked and swapping out the
RTOS, it's probably a porting issue.

> Should I eventually not allow recursive interrupts in this routine? I
> think I still have problems with changing the original code to use the
> ctl library routines for IRQ treatement....

I think that might be right. Whilst I'm not against chatting about this
problem on the list, it's probably best addressed through our support
helpdesk or directly.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors Start a New Thread