On Feb 16, 2011, at 9:51 PM, mohamed wrote:
> actually, the stack size is 4 K, and i have a sample
code that hase two simple task, the first one is doing nothing and the other one
is responsable to handle the PPP, if the PPP task didn't switch to the
other task using OStimeDly, the code will work without crashing and if the task
did switch, the code will crash
> So i think that PPP is causing unbalance in the stack
> and here is the sample code.
Have you contacted Rabbit's tech support (s...@rabbit.com) yet? I'd
be very surprised if PPP wasn't compatible with uC/OS-II. The fact that
you have a small program to reproduce the problem should help them track down
the problem quickly.
-Tom
PPP while using ucos2
Started by ●February 11, 2011
Reply by ●February 18, 20112011-02-18
Reply by ●February 20, 20112011-02-20
actually, i did but the response was totally useless.
they reply was
"checkRx(IfaceType *pt_iface) is not treated as a uCos task so please do not put uCos functions in functions that are not officially tasks. When an official uCos task is switched out, its info is saved to the uCos stack set aside for that task."
then my reply
"
i used your advice but it still crashing after receiving the third 1100 byte.
i'm attaching the code after the modifications by moving the OSTimeDly inside the official task
"
and finally they said
"I saw these macros:
#define DIALUP_SENDEXPECT "#CLIENTCLIENT CLIENTSERVER" //DIALUP_AUTH
//************************* DEBUGGING MACROS ***********************************
//Uncomment to get PPP detail (Show me some debugging info)
#define PPP_VERBOSE
#define PPPLINK_VERBOSE
#define CHAT_VERBOSE
#define DNS_VERBOSE
#define IP_VERBOSE
but have not seen the results of the STDIO log. And there is another matter, that of your attempt to connect not to an isp, but to another peer.
#define DIALUP_SENDEXPECT "#CLIENTCLIENT CLIENTSERVER" //DIALUP_AUTH
For that, support is a bit limited. Attached is a sample that does that, to a degree."
so for now i'm sure that the ucos has a problem with the PPP over serial port, so to save my time i got raid of the ucos to deliver my project and if i have time i will check their problem, really i lost alot of time and i didn't get the expected support. it was disappointed.
thanks,
Mohamed Fawzy
--- In r..., Tom Collins wrote:
>
> On Feb 16, 2011, at 9:51 PM, mohamed wrote:
> > actually, the stack size is 4 K, and i have a sample code that hase two simple task, the first one is doing nothing and the other one is responsable to handle the PPP, if the PPP task didn't switch to the other task using OStimeDly, the code will work without crashing and if the task did switch, the code will crash
> > So i think that PPP is causing unbalance in the stack
> > and here is the sample code.
>
> Have you contacted Rabbit's tech support (support@...) yet? I'd be very surprised if PPP wasn't compatible with uC/OS-II. The fact that you have a small program to reproduce the problem should help them track down the problem quickly.
>
> -Tom
>
they reply was
"checkRx(IfaceType *pt_iface) is not treated as a uCos task so please do not put uCos functions in functions that are not officially tasks. When an official uCos task is switched out, its info is saved to the uCos stack set aside for that task."
then my reply
"
i used your advice but it still crashing after receiving the third 1100 byte.
i'm attaching the code after the modifications by moving the OSTimeDly inside the official task
"
and finally they said
"I saw these macros:
#define DIALUP_SENDEXPECT "#CLIENTCLIENT CLIENTSERVER" //DIALUP_AUTH
//************************* DEBUGGING MACROS ***********************************
//Uncomment to get PPP detail (Show me some debugging info)
#define PPP_VERBOSE
#define PPPLINK_VERBOSE
#define CHAT_VERBOSE
#define DNS_VERBOSE
#define IP_VERBOSE
but have not seen the results of the STDIO log. And there is another matter, that of your attempt to connect not to an isp, but to another peer.
#define DIALUP_SENDEXPECT "#CLIENTCLIENT CLIENTSERVER" //DIALUP_AUTH
For that, support is a bit limited. Attached is a sample that does that, to a degree."
so for now i'm sure that the ucos has a problem with the PPP over serial port, so to save my time i got raid of the ucos to deliver my project and if i have time i will check their problem, really i lost alot of time and i didn't get the expected support. it was disappointed.
thanks,
Mohamed Fawzy
--- In r..., Tom Collins wrote:
>
> On Feb 16, 2011, at 9:51 PM, mohamed wrote:
> > actually, the stack size is 4 K, and i have a sample code that hase two simple task, the first one is doing nothing and the other one is responsable to handle the PPP, if the PPP task didn't switch to the other task using OStimeDly, the code will work without crashing and if the task did switch, the code will crash
> > So i think that PPP is causing unbalance in the stack
> > and here is the sample code.
>
> Have you contacted Rabbit's tech support (support@...) yet? I'd be very surprised if PPP wasn't compatible with uC/OS-II. The fact that you have a small program to reproduce the problem should help them track down the problem quickly.
>
> -Tom
>
Reply by ●April 20, 20112011-04-20
PPP is not compatible with uCOS. Don't belive anything customer support
tells you. The drivers, especially for PPP (SERLINK.LIB), cause stack
corruption which leads to watchdog reboots.
Reply by ●April 21, 20112011-04-21
Hi Joey,
I would be very interested to know more about this.
I am using PPP with UCOS on a DC 9.62 setup and not found any issues with it
so far but interested to know what you found out.
Please post all your findings here as I am sure others would be interested
and we could help to sort this out. I am keen to help as I depend on this
for a current project.
Cheers,
Dave...
---
Very funny Scotty, now beam down my clothes!!!
---
From: r... [mailto:r...] On
Behalf Of Joey
Sent: 20 April 2011 22:35
To: r...
Subject: [rabbit-semi] Re: PPP while using ucos2
PPP is not compatible with uCOS. Don't belive anything customer support
tells you. The drivers, especially for PPP (SERLINK.LIB), cause stack
corruption which leads to watchdog reboots.
I would be very interested to know more about this.
I am using PPP with UCOS on a DC 9.62 setup and not found any issues with it
so far but interested to know what you found out.
Please post all your findings here as I am sure others would be interested
and we could help to sort this out. I am keen to help as I depend on this
for a current project.
Cheers,
Dave...
---
Very funny Scotty, now beam down my clothes!!!
---
From: r... [mailto:r...] On
Behalf Of Joey
Sent: 20 April 2011 22:35
To: r...
Subject: [rabbit-semi] Re: PPP while using ucos2
PPP is not compatible with uCOS. Don't belive anything customer support
tells you. The drivers, especially for PPP (SERLINK.LIB), cause stack
corruption which leads to watchdog reboots.
Reply by ●April 21, 20112011-04-21
The major problem is with the interrupt handlers. They are not
compliant with the uCOS interrupt handler spec. Stack corruptions
occurs whenever a nested interrupt causes a task switch. A typical case
is as follows:
1 the serlink driver (PPP) interrupts and starts processing
2 the serlink driver re-enables interrupts before completing
3 the rt clock interrupt fires
4 clock driver declares a task switch because some timer expired for a
higher prio task
5 clock driver completes and task switches
6 new task starts running with corrupted stack because the serlink
registers are still on the stack. often it is the xpc that is messed up
7 watchdog causes reboot
I see this a lot with serlink because it interrupts a lot and the
handler takes a long time to execute so the probability of corruption is
great (especially with large data packets), but other handlers
(RS232.lib, util.lib) are also capable of causing the same problem.
There is also a bug in the ucos2.lib that complicates the issue.
Line 1488 (in my version)
"sbc a,(hl)" shoud be "or (hl)"
Whether or not you see the bug will of course depend on how many tasks
and at what prio they run at, as well as what ucos2 features you are
using.
compliant with the uCOS interrupt handler spec. Stack corruptions
occurs whenever a nested interrupt causes a task switch. A typical case
is as follows:
1 the serlink driver (PPP) interrupts and starts processing
2 the serlink driver re-enables interrupts before completing
3 the rt clock interrupt fires
4 clock driver declares a task switch because some timer expired for a
higher prio task
5 clock driver completes and task switches
6 new task starts running with corrupted stack because the serlink
registers are still on the stack. often it is the xpc that is messed up
7 watchdog causes reboot
I see this a lot with serlink because it interrupts a lot and the
handler takes a long time to execute so the probability of corruption is
great (especially with large data packets), but other handlers
(RS232.lib, util.lib) are also capable of causing the same problem.
There is also a bug in the ucos2.lib that complicates the issue.
Line 1488 (in my version)
"sbc a,(hl)" shoud be "or (hl)"
Whether or not you see the bug will of course depend on how many tasks
and at what prio they run at, as well as what ucos2 features you are
using.
Reply by ●April 22, 20112011-04-22
sure the ucos and PPP over serial are not working together and you can find a
simple program that i posted previously in this thread which is demonstrating
the problem, you can check this thread history
--- In r..., "Joey" wrote:
> The major problem is with the interrupt handlers. They are not
> compliant with the uCOS interrupt handler spec. Stack corruptions
> occurs whenever a nested interrupt causes a task switch. A typical case
> is as follows:
>
> 1 the serlink driver (PPP) interrupts and starts processing
>
> 2 the serlink driver re-enables interrupts before completing
>
> 3 the rt clock interrupt fires
>
> 4 clock driver declares a task switch because some timer expired for a
> higher prio task
>
> 5 clock driver completes and task switches
>
> 6 new task starts running with corrupted stack because the serlink
> registers are still on the stack. often it is the xpc that is messed up
>
> 7 watchdog causes reboot
>
> I see this a lot with serlink because it interrupts a lot and the
> handler takes a long time to execute so the probability of corruption is
> great (especially with large data packets), but other handlers
> (RS232.lib, util.lib) are also capable of causing the same problem.
>
> There is also a bug in the ucos2.lib that complicates the issue.
>
> Line 1488 (in my version)
>
> "sbc a,(hl)" shoud be "or (hl)"
>
> Whether or not you see the bug will of course depend on how many tasks
> and at what prio they run at, as well as what ucos2 features you are
> using.
>
--- In r..., "Joey" wrote:
> The major problem is with the interrupt handlers. They are not
> compliant with the uCOS interrupt handler spec. Stack corruptions
> occurs whenever a nested interrupt causes a task switch. A typical case
> is as follows:
>
> 1 the serlink driver (PPP) interrupts and starts processing
>
> 2 the serlink driver re-enables interrupts before completing
>
> 3 the rt clock interrupt fires
>
> 4 clock driver declares a task switch because some timer expired for a
> higher prio task
>
> 5 clock driver completes and task switches
>
> 6 new task starts running with corrupted stack because the serlink
> registers are still on the stack. often it is the xpc that is messed up
>
> 7 watchdog causes reboot
>
> I see this a lot with serlink because it interrupts a lot and the
> handler takes a long time to execute so the probability of corruption is
> great (especially with large data packets), but other handlers
> (RS232.lib, util.lib) are also capable of causing the same problem.
>
> There is also a bug in the ucos2.lib that complicates the issue.
>
> Line 1488 (in my version)
>
> "sbc a,(hl)" shoud be "or (hl)"
>
> Whether or not you see the bug will of course depend on how many tasks
> and at what prio they run at, as well as what ucos2 features you are
> using.
>
Reply by ●April 22, 20112011-04-22
I have posted my changes in 4 files that have fixed this problem for me:
SERLINK.LIB
RS232.LIB
UCOS2.LIB
UTIL.LIB
This is based on DC 9.62. All my changes are marked with
"***** CHANGE *****".
Please let me know if they work for you also.
SERLINK.LIB
RS232.LIB
UCOS2.LIB
UTIL.LIB
This is based on DC 9.62. All my changes are marked with
"***** CHANGE *****".
Please let me know if they work for you also.
Reply by ●April 22, 20112011-04-22
Hi Joey,
Where have you uploaded the files?
I will be happy to test them for you on my hardware with the PPP connection
which sends data every few minutes.
Dave...
---
Very funny Scotty, now beam down my clothes!!!
---
From: r... [mailto:r...] On
Behalf Of Joey
Sent: 22 April 2011 19:07
To: r...
Subject: [rabbit-semi] Re: PPP while using ucos2
I have posted my changes in 4 files that have fixed this problem for me:
SERLINK.LIB
RS232.LIB
UCOS2.LIB
UTIL.LIB
This is based on DC 9.62. All my changes are marked with
"***** CHANGE *****".
Please let me know if they work for you also.
Where have you uploaded the files?
I will be happy to test them for you on my hardware with the PPP connection
which sends data every few minutes.
Dave...
---
Very funny Scotty, now beam down my clothes!!!
---
From: r... [mailto:r...] On
Behalf Of Joey
Sent: 22 April 2011 19:07
To: r...
Subject: [rabbit-semi] Re: PPP while using ucos2
I have posted my changes in 4 files that have fixed this problem for me:
SERLINK.LIB
RS232.LIB
UCOS2.LIB
UTIL.LIB
This is based on DC 9.62. All my changes are marked with
"***** CHANGE *****".
Please let me know if they work for you also.
Reply by ●April 22, 20112011-04-22
Hi Dave,
If you look in the files link on the left they are there. The list is in alphabetical order so you will have to search down near the end for most of them.
Regards,
Peter
--- In r..., "Dave McLaughlin" wrote:
>
> Hi Joey,
>
> Where have you uploaded the files?
>
> I will be happy to test them for you on my hardware with the PPP connection
> which sends data every few minutes.
>
>
> Dave...
> ---
> Very funny Scotty, now beam down my clothes!!!
> ---
>
> From: r... [mailto:r...] On
> Behalf Of Joey
> Sent: 22 April 2011 19:07
> To: r...
> Subject: [rabbit-semi] Re: PPP while using ucos2
>
>
> I have posted my changes in 4 files that have fixed this problem for me:
>
> SERLINK.LIB
> RS232.LIB
> UCOS2.LIB
> UTIL.LIB
>
> This is based on DC 9.62. All my changes are marked with
> "***** CHANGE *****".
>
> Please let me know if they work for you also.
>
If you look in the files link on the left they are there. The list is in alphabetical order so you will have to search down near the end for most of them.
Regards,
Peter
--- In r..., "Dave McLaughlin" wrote:
>
> Hi Joey,
>
> Where have you uploaded the files?
>
> I will be happy to test them for you on my hardware with the PPP connection
> which sends data every few minutes.
>
>
> Dave...
> ---
> Very funny Scotty, now beam down my clothes!!!
> ---
>
> From: r... [mailto:r...] On
> Behalf Of Joey
> Sent: 22 April 2011 19:07
> To: r...
> Subject: [rabbit-semi] Re: PPP while using ucos2
>
>
> I have posted my changes in 4 files that have fixed this problem for me:
>
> SERLINK.LIB
> RS232.LIB
> UCOS2.LIB
> UTIL.LIB
>
> This is based on DC 9.62. All my changes are marked with
> "***** CHANGE *****".
>
> Please let me know if they work for you also.
>
Reply by ●April 23, 20112011-04-23
You're welcome Dave!
I'll be interested in seeing how you get on with these as I use the RS232.LIB with ucos2 for the MS/TP support on the BACnet stack and it generates almost continuous serial traffic (token passing network so even when "nothing" is happening the token is whizzing back and forward).
Regards,
Peter
--- In r..., "Dave McLaughlin" wrote:
>
> Thanks Peter,
>
> As I get an email and don't use the web interface I didn't put 2 and 2
> together.
>
> I'll go online today and check them out.
>
> Dave...
> ---
> Very funny Scotty, now beam down my clothes!!!
> ---
>
> From: r... [mailto:r...] On
> Behalf Of petermcs
> Sent: 22 April 2011 23:45
> To: r...
> Subject: [rabbit-semi] Re: PPP while using ucos2
>
>
> Hi Dave,
>
> If you look in the files link on the left they are there. The list is in
> alphabetical order so you will have to search down near the end for most of
> them.
>
> Regards,
> Peter
>
I'll be interested in seeing how you get on with these as I use the RS232.LIB with ucos2 for the MS/TP support on the BACnet stack and it generates almost continuous serial traffic (token passing network so even when "nothing" is happening the token is whizzing back and forward).
Regards,
Peter
--- In r..., "Dave McLaughlin" wrote:
>
> Thanks Peter,
>
> As I get an email and don't use the web interface I didn't put 2 and 2
> together.
>
> I'll go online today and check them out.
>
> Dave...
> ---
> Very funny Scotty, now beam down my clothes!!!
> ---
>
> From: r... [mailto:r...] On
> Behalf Of petermcs
> Sent: 22 April 2011 23:45
> To: r...
> Subject: [rabbit-semi] Re: PPP while using ucos2
>
>
> Hi Dave,
>
> If you look in the files link on the left they are there. The list is in
> alphabetical order so you will have to search down near the end for most of
> them.
>
> Regards,
> Peter
>
