Reply by Kenneth Crudup●November 22, 20072007-11-22
On Wed, 21 Nov 2007, mjames_doveridge wrote:
> I do not use the WDT. I'm not convinced that it
would help me much.
It placates the client. :)
> When using an OS, I don't know where to put the
WDT resets.
I'm a Linux guy; I program delays against a "jiffies" value that I
create by making PWM0 (whose output also controls external devices)
interrupt at a fixed rate.
> Even if the WDT interrupt saves state, there is no
guarantee that
> the thread that caused the excessive delay was the one that was
> bitten by the dog.
I have a 30sec WDT timeout; that's a crash! It's mostly 'cause
there's
a chance that the external hardware (that I can control via GPIO) can
get screwed up.
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Los Angeles
O: 3630 S. Sepulveda Blvd. #138, L.A., CA 90034-6809 (888) 454-8181
Reply by Kenneth Crudup●November 21, 20072007-11-21
On Wed, 21 Nov 2007, Richard Duits wrote:
> Maybe you can let the debugger send something to the
debug
> communications channel (dcc) first thing after it starts debugging.
Or better yet- attempt to send something out on the DCC to the JTAG
device. I have a BDI2000, and if nothing's listening on the SIO port,
DCC-to-JTAG output still pass thru anyway if I don't explicitly listen.
Thanks. Dunno if this'll actually do it, but it's a start. I'd
considered
the DCC before and got wrapped up in something else.
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Los Angeles
O: 3630 S. Sepulveda Blvd. #138, L.A., CA 90034-6809 (888) 454-8181
Reply by Richard Duits●November 21, 20072007-11-21
Kenneth Crudup wrote: > I'd like to put JTAG detection into the code
(but it's not a hard
> requirement, just something I'd like to do). Has anyone got a
*reliable*
> way of detecting a connected (and not just pinned-out for connection) JTAG
> device? Examining pins on the P. block in which it's connected
doesn't
> work very well.
> Maybe you can let the debugger send something to the debug
communications channel (dcc) first thing after it starts debugging. If
the target does not receive a dcc message, it can use idle. I know keil
(with the ulink2) has some background debug code you can compile in to
examine variables while running. Keil checks for the presense of this
code immidiately after it starts debugging.
Hopes this helps...
Richard.
Reply by mjames_doveridge●November 21, 20072007-11-21
>
> It placates the client. :)
> > When using an OS, I don't know where to put
the WDT resets.
>
> I'm a Linux guy; I program delays against a "jiffies" value that I
> create by making PWM0 (whose output also controls external devices)
> interrupt at a fixed rate.
I'm a Windows guy; I too have timeouts on all external transactions
that might fail, (and that's all of them :). The OS timer provides a
1ms tick/jiffy count that I can use to determine a timeout-count for
the transactions.
> > Even if the WDT interrupt saves state, there is no
guarantee that
> > the thread that caused the excessive delay was the one that was
> > bitten by the dog.
>
> I have a 30sec WDT timeout; that's a crash! It's mostly 'cause
there's
> a chance that the external hardware (that I can control via GPIO) can
> get screwed up.
>
Whenever I have used WDTs before, I always seems that the system stops
because it's stuck in some loop that includes a WDT reset :((
Rgds,
Martin
Reply by mjames_doveridge●November 21, 20072007-11-21
--- In l..., Kenneth Crudup wrote: > On Sun, 18 Nov 2007, Richard Duits wrote:
>
> > The idle mode will switch off the clock to the core until an interrupt
> > becomes active. The JTAG logic is the core, so it too will not receive
> > a clock and cannot respond to the jtag probe.
>
> Yeah, I ran into this, and also when the WDT is active- when you do a
> "go" to get back into the code, the watchdog fires (as I'd expect,
since
> PCLK is still running).
>
I do not use the WDT. I'm not convinced that it would help me much.
When using an OS, I don't know where to put the WDT resets. Even if
the WDT interrupt saves state, there is no guarantee that the thread
that caused the excessive delay was the one that was bitten by the
dog. I can conceive of complex WDT schemes involving sending
'echo'
messages to every thread in the system, but that adds more code and
uses more resources, so introducing more bugs and more testing....
Rgds,
Martin
Reply by mjames_doveridge●November 19, 20072007-11-19
> The idle mode will switch off the clock to the core
until an interrupt
> becomes active. The JTAG logic is the core, so it too will not receive a > clock and cannot respond to the jtag probe. I only
use the idle command
> when I compile a release version. Debug versions don't do idle.
>
> Richard.
Yeah - I guessed that was the problem. Now you have confirmed it, I am
no longer worried:)
Thanks,
Martin
Reply by Richard Duits●November 18, 20072007-11-18
The idle mode will switch off the clock to the core until an interrupt
becomes active. The JTAG logic is the core, so it too will not receive a
clock and cannot respond to the jtag probe. I only use the idle command
when I compile a release version. Debug versions don't do idle.
Richard.
mjames_doveridge wrote: > Adding the Idle mode set causes ructions in my
JTAG/wiggler debugger.
> It says that execution has transferred to FFFFFFF8, or something like
> that. OTOH, the code can be made to operate - hitting the run key on
> my PC again and.. - the keypad, UART, CAN etc. are all 'alive', so
it
> seems that any power-mode set may have to be left for the deliverable
> software and commented out during development.
>
>
Reply by mjames_doveridge●November 17, 20072007-11-17
> Yes - it is very common indeed to use an idle task
for this purpose. You > must select a sleep mode that can be woken by the
tick interrupt.
---------------------------------
void threadCodeIdle(void* param){
while (1) PCON|=PCON_IDL_MASK;
};
---------------------------------
Adding the Idle mode set causes ructions in my JTAG/wiggler debugger.
It says that execution has transferred to FFFFFFF8, or something like
that. OTOH, the code can be made to operate - hitting the run key on
my PC again and.. - the keypad, UART, CAN etc. are all 'alive', so
it
seems that any power-mode set may have to be left for the deliverable
software and commented out during development.
The > slower you can have the tick the better your power
consumption.
On the new project, I may be able to do without the tick interrupt
altogether.
'See also the sub heading "improved efficiency" ' - can't
disagree
with any of that. Without an OS, I doubt that I would have got my
present app working. There are three 'apps' that will run on
different boards, but for development, I run all three on one
board/uC. Debugging is so much easier because I can see the protocol
packets leaving on one port and arriving at another, all with the one
debugger. If I can demonstrate all three apps working harmoniously on
one CPU, there's next-to-no doubt that they'll work correctly
together
when they have a uC each.
Rgds,
Martin
Reply by "FreeRTOS.org Info"●November 17, 20072007-11-17
> -----Original Message-----
> From: l...
> [mailto:l...] On Behalf Of mjames_doveridge
> Sent: 17 November 2007 09:36
> To: l...
> Subject: [lpc2000] Power control - idle mode in RTOS?
>
> While examining power issues for a possible new project, it occurred
> to me that the idle thread of my Rowley ctl OS could set the processor
> into idle-mode power-saving. It should sit there waiting for
> interrupts to start the system doing something.
>
> Currently, the idle thread is the usual 'while(1);'. I tried
putting
> a switch to idle mode inside this loop, but my system died:(
>
> Anyone had any success switching to idle mode on LPC2129 and any RTOS? Yes - it is very common indeed to use an idle task for this purpose.
You
must select a sleep mode that can be woken by the tick interrupt. The
slower you can have the tick the better your power consumption. See also
the sub heading "improved efficiency" on the following page: http://www.freertos.org/FAQWhat.html#WhyUseRTOS
Regards,
Richard.
+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.
Reply by mjames_doveridge●November 17, 20072007-11-17
While examining power issues for a possible new project, it occurred
to me that the idle thread of my Rowley ctl OS could set the processor
into idle-mode power-saving. It should sit there waiting for
interrupts to start the system doing something.
Currently, the idle thread is the usual 'while(1);'. I tried
putting
a switch to idle mode inside this loop, but my system died:(
Anyone had any success switching to idle mode on LPC2129 and any RTOS?
