[En-Nut-Discussion] Interrupt Problem
JOhan ferouskain
argaelgr at yahoo.gr
Tue Aug 25 12:34:05 CEST 2009
Hello
I am trying to use interrupts on ethernut 1.3.h as a part of a multithreaded application
My application uses a thread that does heavy use of ethernet communication(and communicates with another ehternut as a result of an interrupt) .What happens is that i get the following bizzare behavior , while all initializations end ok (NutIrqEnable etc) after i trigger one interrupt my threads die, and after a while i get a system reboot (i suppose watchdog timer causes it ) also the first interrupt i cause (on port e pin 7) executes normally but after that i cant cause any other interrupt nor use any of the other threads .I am quite generous on the thread stack (3024 kb ) (its a lot i know ) just to make sure it is not a stack overflow , also i do not use static array declarations only malloc . If i dont cause interrupts my application works ok.If you can give me any pointers it will be much appreciated
Regards
John
PS i registered the InterruptHandler as proposed in the nutos api , my aplication is not hard real time so the performance overhead was acceptable
PS2: Using Nutos 4.6.4 , ethernut 1.3 rev h .(under normal operation heapAvailable is 15kb, while using interrupt (the first one cause it dies after) heapAvailable is 14780 after interrupt 15kb)
--- Στις Τρίτ., 25/08/09, ο/η en-nut-discussion-request at egnite.de <en-nut-discussion-request at egnite.de> έγραψε:
Από: en-nut-discussion-request at egnite.de <en-nut-discussion-request at egnite.de>
Θέμα: En-Nut-Discussion Digest, Vol 70, Issue 21
Προς: en-nut-discussion at egnite.de
Ημερομηνία: Τρίτη, 25 Αύγουστος 2009, 13:00
Send En-Nut-Discussion mailing list submissions to
en-nut-discussion at egnite.de
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
or, via email, send a message with subject or body 'help' to
en-nut-discussion-request at egnite.de
You can reach the person managing the list at
en-nut-discussion-owner at egnite.de
When replying, please edit your Subject line so it is more specific
than "Re: Contents of En-Nut-Discussion digest..."
Today's Topics:
1. Ethernut 3 Flashbootloader (Joerg Wiegelmann)
2. Debugging Watchdogs via OS Thread Switching
(Timothy M. De Baillie)
3. Question regarding NutLoadConfig/NutSaveConfig (Ulrich Prinz)
4. Missing status return option in driver structure (Ulrich Prinz)
5. Re: Debugging Watchdogs via OS Thread Switching (Ulrich Prinz)
----------------------------------------------------------------------
Message: 1
Date: Mon, 24 Aug 2009 14:00:26 +0200
From: Joerg Wiegelmann <wiegelj at gmx.de>
Subject: [En-Nut-Discussion] Ethernut 3 Flashbootloader
To: en-nut-discussion at egnite.de
Message-ID: <4A9280DA.80703 at gmx.de>
Content-Type: text/plain; charset=ISO-8859-15
Hi folks,
I'm thinking about to migrate from good old ethernut 1.3 to Ethernut 3.
The reason is, that I'm running out of code memory. Does anyone knows a
bootloader that works like the ethernut 1 bootloader, that flashs the
code direct into program memory?
Thank you
Joerg
------------------------------
Message: 2
Date: Mon, 24 Aug 2009 14:19:08 -0500
From: "Timothy M. De Baillie" <debaillie at ciholas.com>
Subject: [En-Nut-Discussion] Debugging Watchdogs via OS Thread
Switching
To: "Ethernut User Chat (English)" <en-nut-discussion at egnite.de>
Message-ID: <4A92E7AC.9000706 at ciholas.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I was thinking today about adding some debug code to the function
NutThreadSwitch in context_icc.c. Let me explain my thinking here.
I have a watchdog timer set for some time (say 5 seconds).
My watchdog is kept at bay by a high priority (low in number) thread
that sleeps for at least 1 second at a time (via a NutSleep(1000)).
(this is the highest priority thread in the software)
I need to debug which thread is causing a watchdog in a very complex
multi-threaded system.
Therefore, it would be "nice" if the OS saved the state of the last
context switch.
Looking through the OS code, all of the "yielding" functions ultimately
call NutThreadResume, which then calls NutThreadSwitch. From my
understanding of the code (by inspection), I could save the thread I am
going to switch to, the total amount of RAM free, and the watchdog timer
information in a protected piece of RAM for later inspection from the
NutTheadSwitch function.
So my implementation would include modifying the OS Ram size to give me
some bytes of RAM to play with above the Heap. Every NutThreadSwitch
would save the information I listed above. Additionally I was wondering
if there was an easy way to get the specific line of code (code space
address) of the return path of the yield in both the "last thread" and
"next thread". This would help narrow down the problem to where in a
thread the problem might occur. On a watchdog, the first thing my
software would do, would be to read the contents of the RAM above the
Heap and report it.
I understand that these extra calls will slow down the context switch,
and therefore I would only add it in with a DEBUG compiler definition.
Does anyone have any thoughts or suggestions on the implementation of this?
Thanks in advance,
Tim
------------------------------
Message: 3
Date: Mon, 24 Aug 2009 23:21:39 +0200
From: Ulrich Prinz <uprinz2 at netscape.net>
Subject: [En-Nut-Discussion] Question regarding
NutLoadConfig/NutSaveConfig
To: "Ethernut User Chat (English)" <en-nut-discussion at egnite.de>
Message-ID: <4A930463.1000607 at netscape.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi!
I'd like to add the AT24C driver in combination with the new at91_twi.c
as a generic EEPROM driver to the NutConfig system.
Crawling through the code shows, that the existing NutLoadConfig() is
called at the beginning of the NutInit() function that also installs the
main() function as an idel-task.
Before that NutLoadConfig() call, there is no additonal code that
installs any kind of driver. While my boards run fine, if I use the
at91EFC option, where the config is locatd in the onchip flash, no other
option works. I.e. If I setup the AT45DB serial flash for NutConfig
space it doesn't work, and if I use my new eeprom driver, it doesnt work
either.
I was shure, that it don't work with my eeprom, as first the at91_twi
has to be initialized, and second, the at24c init has to be called to
setup at least one eeprom to be connected to the twi.
I knew that and investogated for the point, where the AT45DB installs
it's SPI node... I don't find it. And, as the system crashes with the
AT45DB too, I fear that there is something missing...
Any idea, or help, or tip where I missed something?
Best regards,
Ulrich
------------------------------
Message: 4
Date: Mon, 24 Aug 2009 23:37:00 +0200
From: Ulrich Prinz <uprinz2 at netscape.net>
Subject: [En-Nut-Discussion] Missing status return option in driver
structure
To: "Ethernut User Chat (English)" <en-nut-discussion at egnite.de>
Message-ID: <4A9307FC.5050903 at netscape.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi again :)
Yes I am actually doing NutO/S coding for four projects in parallel, so
there will be more to com from my side :)
Attaching a graphical OLED to the system, that should be simply used by
printf() I went the same way as the HD44780 or this STsomthing LCD.
I have a NUTDEVICE for the OLED, referring to a TERMDCB for the term.c
code. With that one can easily do character output and some cursor
control oon the display.
But I have some different displays ans some hardware that have slight
differences. I dream of displays that can return some information over
the SPI, but I never saw one of them :(
Now, the NUTDEVICE has an init function, returning an int as status if
the init failed. Sow the software can tell if the other software failed.
But the TERMDCB only accepts a void from the hardware init function. So
the hardware cannot tell the software if it failed.
The most reasons for the return codes in the NutO/S driver structure
are, that there might not be enough memory for installing the drivers
variables, structs or buffers in the ram. My hardware driver for the
oled needs some bytes of ram too and I prefer to install them only if
the hardware is found and the hardware is needed.
As a result you cannot detect, if the hardware failed and take actions
like reconfiguration, trying a different address for the hardware or
anything else. I even cannot detect if there is not enough ram to
install hardware drivers that need some ram space.
So, how about modifying this and giving hardware driver related Init()
functions always a return as int? I just ask if there is any reason
against that? If not, I'll include that into trunk in one of my next
updates.
And yes, the new led driver is missing its led.c... On my work PC it's
there, in the repository, it's there, but on my home PC it doesn't
appear in the checkout... If one of you guys has it hidden under his
keyboard, trust me I'll get you :)
Best regards, Ulrich
------------------------------
Message: 5
Date: Tue, 25 Aug 2009 00:00:55 +0200
From: Ulrich Prinz <uprinz2 at netscape.net>
Subject: Re: [En-Nut-Discussion] Debugging Watchdogs via OS Thread
Switching
To: "Ethernut User Chat (English)" <en-nut-discussion at egnite.de>
Message-ID: <4A930D97.7060704 at netscape.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Timothy!
In total not a bad idea, but two things:
How will a high priority task let the watchdog struck? I mean, yea, most
of the system crashes in the development phase will be caused by driver
problems and these crashes will stop any code execution. So that hiprio
task will get killed too.
But if the software is 'finished' (I know, software is never finished)
everything runs smoothly. Onc in a while a task will hang, but it's only
one of the four controlling a big motor in a complex machine... And your
high-prio task is stealing exatly these 2 microseconds the other task
had needed not to hang up. Only a simple race condition is neede for
that. And your watchdog ist reset and reset and reset, cause that hiprio
task is still living :)
<Example>
We investigated a problem on one of our systems, where after some time a
radio connection gets lost. The tasks are all running except one. But
that one is not killing the system, it just yields.
The problem was caused by a concurrent access to one SPI device by two
different callers. The task was writing through a buffer, the other task
did a direct access to the device. The driver wasn't aware and after
sending out the second tasks data it never finished the first ones, so
that one simply yield.
A watchdog producing a freezeframe of the system might help to find that
problem. Cause debug outpu slowes down the system and the tasks shift in
time. By adding more and more debug code, the concurrent accesses of the
SPI devic get less end less. So we had to spread debug code carfully and
bit by bit.
A watchdog put into each thread one by one is not that intrusive and
could help. But the watchdog would never have struck if it is called in
a high prio task.
Now we have another one: The system hangs every about four weeks... Yep.
I think I'll have another dozend grey hairs when I found that one.
</Example>
In my understanding a watchdog has to options where it is to be resettet
before tri00ggering:
1) You have a very very important task that needs to be executed in a
certain time again and again
2) The watchdog is reset in the idle task. The idle task has the lowes
priority and resetting the WD here ensures, that every task is giving
time to any other task in the chain and therefore now and then the idle
task gets some system time too.
Oh, so much text, but here comes the second comment:
Investigating in a thing that can save freezeframes of the system if it
crashes is something I am interested in too. But I'd like to see it as
an option in the nutconf. Have a look on one of the first folders there,
there you'll find NutO/S Debugging. There it should appear as an
configureable option to switch it on or off as needed.
Best regards,
Ulrich
Timothy M. De Baillie wrote:
> I was thinking today about adding some debug code to the function
> NutThreadSwitch in context_icc.c. Let me explain my thinking here.
>
> I have a watchdog timer set for some time (say 5 seconds).
> My watchdog is kept at bay by a high priority (low in number) thread
> that sleeps for at least 1 second at a time (via a NutSleep(1000)).
> (this is the highest priority thread in the software)
> I need to debug which thread is causing a watchdog in a very complex
> multi-threaded system.
> Therefore, it would be "nice" if the OS saved the state of the last
> context switch.
>
> Looking through the OS code, all of the "yielding" functions ultimately
> call NutThreadResume, which then calls NutThreadSwitch. From my
> understanding of the code (by inspection), I could save the thread I am
> going to switch to, the total amount of RAM free, and the watchdog timer
> information in a protected piece of RAM for later inspection from the
> NutTheadSwitch function.
>
> So my implementation would include modifying the OS Ram size to give me
> some bytes of RAM to play with above the Heap. Every NutThreadSwitch
> would save the information I listed above. Additionally I was wondering
> if there was an easy way to get the specific line of code (code space
> address) of the return path of the yield in both the "last thread" and
> "next thread". This would help narrow down the problem to where in a
> thread the problem might occur. On a watchdog, the first thing my
> software would do, would be to read the contents of the RAM above the
> Heap and report it.
>
> I understand that these extra calls will slow down the context switch,
> and therefore I would only add it in with a DEBUG compiler definition.
>
> Does anyone have any thoughts or suggestions on the implementation of this?
>
> Thanks in advance,
>
> Tim
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
------------------------------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
End of En-Nut-Discussion Digest, Vol 70, Issue 21
*************************************************
___________________________________________________________
Χρησιμοποιείτε Yahoo!;
Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail
διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών
μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr
More information about the En-Nut-Discussion
mailing list