PPP while using ucos2

Hi All,

Does anybody faced a problem with using the PPP while using the ucos2?
i'm using DC10.64.

Best Regards
Mohamed Fawzy

Start a New Thread

Hi there,

What problems are you having with PPP with UCOS II? You question leaves us
with no clues to what your problems are?

I have it working with DC 10.64 but I had to make sure the IP address was
reset to ZERO each time before I called the PPP dialer otherwise it would
just fail to connected after the first attempt. First time after power on or
starting debug was OK but second and subsequent attempts failed. Resetting
the IP to zero sorted this.

Let me know what you issue is and I hope I or someone else can help?

Dave...
---
Very funny Scotty, now beam down my clothes!!!
---

From: r... [mailto:r...] On
Behalf Of mohamed
Sent: 11 February 2011 21:24
To: r...
Subject: [rabbit-semi] PPP while using ucos2

Hi All,

Does anybody faced a problem with using the PPP while using the ucos2?
i'm using DC10.64.

Best Regards
Mohamed Fawzy Start a New Thread

thank u for your fast reply

but i have a project that needs ppp connection to PC over serial port C, the PC will be a host for the incoming connection.
In the code such that i'm opening a UDP socket to receive a frame of 1100 byte every 3 seconds from a PC tool but after about 10 minutes, the code is crashing and the rabbit is rebooting.
by the way i'm using RCM4210.

--- In r..., "Dave McLaughlin" wrote:
>
> Hi there,
>
> What problems are you having with PPP with UCOS II? You question leaves us
> with no clues to what your problems are?
>
> I have it working with DC 10.64 but I had to make sure the IP address was
> reset to ZERO each time before I called the PPP dialer otherwise it would
> just fail to connected after the first attempt. First time after power on or
> starting debug was OK but second and subsequent attempts failed. Resetting
> the IP to zero sorted this.
>
> Let me know what you issue is and I hope I or someone else can help?
>
> Dave...
> ---
> Very funny Scotty, now beam down my clothes!!!
> ---
>
> From: r... [mailto:r...] On
> Behalf Of mohamed
> Sent: 11 February 2011 21:24
> To: r...
> Subject: [rabbit-semi] PPP while using ucos2
>
>
> Hi All,
>
> Does anybody faced a problem with using the PPP while using the ucos2?
> i'm using DC10.64.
>
> Best Regards
> Mohamed Fawzy
>

Start a New Thread

That sounds more like a bad pointer of of buffer overflow than a PPP connection fail to me. I'd be checking what your various buffer pointers and such look like at the 9 minute mark.

It's wild speculation I'll admit, but without more info, that'd be where I'd look first. You could change the data transmit rate, or your buffer sizes and see if the timing of the failure changes accordingly.
--- In r..., "mohamed" wrote:
>
> thank u for your fast reply
>
> but i have a project that needs ppp connection to PC over serial port C, the PC will be a host for the incoming connection.
> In the code such that i'm opening a UDP socket to receive a frame of 1100 byte every 3 seconds from a PC tool but after about 10 minutes, the code is crashing and the rabbit is rebooting.
> by the way i'm using RCM4210.
> --- In r..., "Dave McLaughlin" wrote:
> >
> > Hi there,
> >
> > What problems are you having with PPP with UCOS II? You question leaves us
> > with no clues to what your problems are?
> >
> > I have it working with DC 10.64 but I had to make sure the IP address was
> > reset to ZERO each time before I called the PPP dialer otherwise it would
> > just fail to connected after the first attempt. First time after power on or
> > starting debug was OK but second and subsequent attempts failed. Resetting
> > the IP to zero sorted this.
> >
> > Let me know what you issue is and I hope I or someone else can help?
> >
> > Dave...
> > ---
> > Very funny Scotty, now beam down my clothes!!!
> > ---
> >
> >
> >
> > From: r... [mailto:r...] On
> > Behalf Of mohamed
> > Sent: 11 February 2011 21:24
> > To: r...
> > Subject: [rabbit-semi] PPP while using ucos2
> >
> >
> > Hi All,
> >
> > Does anybody faced a problem with using the PPP while using the ucos2?
> > i'm using DC10.64.
> >
> > Best Regards
> > Mohamed Fawzy
>

Start a New Thread

Hi Mohamed,

I had something similar and looked at absolutely everything in my
code, that I initially suspected. In desperation I moved backwards in
DC versions and the PPP-related reset problem went away with DC 10.46.
The Rabbit engineers did send me a LIB patch for 10.62, which I tested
briefly, but I decided to stay with 10.46 due to time constraints. So
give 10.46 a try before looking elsewhere.

Checco

On Sunday, February 13, 2011, John wrote:
>
> That sounds more like a bad pointer of of buffer overflow than a PPP connection fail to me. I'd be checking what your various buffer pointers and such look like at the 9 minute mark.
>
> It's wild speculation I'll admit, but without more info, that'd be where I'd look first. You could change the data transmit rate, or your buffer sizes and see if the timing of the failure changes accordingly.
>
> --- In r..., "mohamed" wrote:
>>
>> thank u for your fast reply
>>
>> but i have a project that needs ppp connection to PC over serial port C, the PC will be a host for the incoming connection.
>> In the code such that i'm opening a UDP socket to receive a frame of 1100 byte every 3 seconds from a PC tool but after about 10 minutes, the code is crashing and the rabbit is rebooting.
>> by the way i'm using RCM4210.
>> --- In r..., "Dave McLaughlin" wrote:
>> >
>> > Hi there,
>> >
>> > What problems are you having with PPP with UCOS II? You question leaves us
>> > with no clues to what your problems are?
>> >
>> > I have it working with DC 10.64 but I had to make sure the IP address was
>> > reset to ZERO each time before I called the PPP dialer otherwise it would
>> > just fail to connected after the first attempt. First time after power on or
>> > starting debug was OK but second and subsequent attempts failed. Resetting
>> > the IP to zero sorted this.
>> >
>> > Let me know what you issue is and I hope I or someone else can help?
>> >
>> > Dave...
>> > ---
>> > Very funny Scotty, now beam down my clothes!!!
>> > ---
>> >
>> >
>> >
>> > From: r... [mailto:r...] On
>> > Behalf Of mohamed
>> > Sent: 11 February 2011 21:24
>> > To: r...
>> > Subject: [rabbit-semi] PPP while using ucos2
>> >
>> >
>> > Hi All,
>> >
>> > Does anybody faced a problem with using the PPP while using the ucos2?
>> > i'm using DC10.64.
>> >
>> > Best Regards
>> > Mohamed Fawzy
>> >
>>
Start a New Thread

Hi All,

actually, it tried to reduce the amount of the received data from 1100 to 100 byte but i'm still having the same problem and even i tried to use older DC 10.54 it still crashing and i didn't try DC 10.46 because it is not available on DIGI website.
but i tried the costate version of my code and it worked with no crashing, so is it may be something releated to ucos2 while using the PPP over serial port!!
Does anyone has a sample of PPP overserial while using the ucos2?

Best Regards
Mohamed Fawzy

--- In r..., Francesco Costella wrote:
>
> Hi Mohamed,
>
> I had something similar and looked at absolutely everything in my
> code, that I initially suspected. In desperation I moved backwards in
> DC versions and the PPP-related reset problem went away with DC 10.46.
> The Rabbit engineers did send me a LIB patch for 10.62, which I tested
> briefly, but I decided to stay with 10.46 due to time constraints. So
> give 10.46 a try before looking elsewhere.
>
> Checco
>
> On Sunday, February 13, 2011, John wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > That sounds more like a bad pointer of of buffer overflow than a PPP connection fail to me. I'd be checking what your various buffer pointers and such look like at the 9 minute mark.
> >
> > It's wild speculation I'll admit, but without more info, that'd be where I'd look first. You could change the data transmit rate, or your buffer sizes and see if the timing of the failure changes accordingly.
> >
> > --- In r..., "mohamed" wrote:
> >>
> >> thank u for your fast reply
> >>
> >> but i have a project that needs ppp connection to PC over serial port C, the PC will be a host for the incoming connection.
> >> In the code such that i'm opening a UDP socket to receive a frame of 1100 byte every 3 seconds from a PC tool but after about 10 minutes, the code is crashing and the rabbit is rebooting.
> >> by the way i'm using RCM4210.
> >>
> >>
> >>
> >>
> >> --- In r..., "Dave McLaughlin" wrote:
> >> >
> >> > Hi there,
> >> >
> >> > What problems are you having with PPP with UCOS II? You question leaves us
> >> > with no clues to what your problems are?
> >> >
> >> > I have it working with DC 10.64 but I had to make sure the IP address was
> >> > reset to ZERO each time before I called the PPP dialer otherwise it would
> >> > just fail to connected after the first attempt. First time after power on or
> >> > starting debug was OK but second and subsequent attempts failed. Resetting
> >> > the IP to zero sorted this.
> >> >
> >> > Let me know what you issue is and I hope I or someone else can help?
> >> >
> >> > Dave...
> >> > ---
> >> > Very funny Scotty, now beam down my clothes!!!
> >> > ---
> >> >
> >> >
> >> >
> >> > From: r... [mailto:r...] On
> >> > Behalf Of mohamed
> >> > Sent: 11 February 2011 21:24
> >> > To: r...
> >> > Subject: [rabbit-semi] PPP while using ucos2
> >> >
> >> >
> >> > Hi All,
> >> >
> >> > Does anybody faced a problem with using the PPP while using the ucos2?
> >> > i'm using DC10.64.
> >> >
> >> > Best Regards
> >> > Mohamed Fawzy
> >> >
> >>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>

Start a New Thread

On 2/11/2011 11:46 AM, Dave McLaughlin wrote:
> Let's say I'm chugging along in my mainloop. If I look at the IP (Interrupt Priority) register, then shouldn't I always see zero?
>
> And then wouldn't a non-zero value be indicative of some "unbalanced" combination of push ip/pop ip/ipset/ipres and interrupts?
>
> (This is assuming, of course, that I didn't just "intentionally" do something in my mainloop to cause IP to be non-zero.)
>
> Thanx People

The low 2 bits should always be 0.

--
------
Scott G. Henion, Consultant
Web site: http://SHDesigns.org
Rabbit libs: http://shdesigns.org/rabbit/
------

Start a New Thread

How large is the stack in each of your tasks that call tcp_tick()?

There's a chance you haven't provided a large enough stack to one of your tasks, and a stack overflow is corrupting data in another task's stack.

-Tom
On Feb 14, 2011, at 7:09 AM, mohamed wrote:

> actually, it tried to reduce the amount of the received data from 1100 to 100 byte but i'm still having the same problem and even i tried to use older DC 10.54 it still crashing and i didn't try DC 10.46 because it is not available on DIGI website.
> but i tried the costate version of my code and it worked with no crashing, so is it may be something releated to ucos2 while using the PPP over serial port!! Start a New Thread

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.
#define OS_MAX_EVENTS 2 // Maximum number of events (semaphores, queues, mailboxes)
#define OS_MAX_TASKS 4 // Maximum number of tasks system can create (less stat and idle tasks)
#define OS_MAX_QS 2 // Maximum number of queues in system

#define OS_TASK_CREATE_EN 1 // Enable normal task creation

#define STACK_CNT_512 10 // number of 512 byte stacks (application tasks + stat task + prog stack)
#define STACK_CNT_4K 2 // number of 512 byte stacks (application tasks + stat task + prog stack)
#define TASK_STK_SIZE 4096 // Size of each task's stacks (# of WORDs)

#define UDP_BUF_SIZE 4096//1024//tbc
#define MAX_UDP_SOCKET_BUFFERS 1
#define DISABLE_TCP
#define TCPCONFIG 0 // set to 0 since we configure our PPP session at runtime
#define USE_PPP_SERIAL 0x20 // 0x02 for B, 0x04 for C, 0x08 for D, .....
#define IF_PPPz IF_PPP5 // IF_PPP0 for A, IF_PPP1 for B, IF_PPP2 for C, .....
#define MODEMBAUD 9600L // If using Enfora use 115200, if using WAVECOM use 9600
// the dialup login is usually not needed if you are on a network that requires a SIM card
#define DIALUP_LOGIN "user" // LOGIN FOR DIALUP
#define DIALUP_PASSWORD "123" // PASSWORD FOR DIALUP

#define PAP_USER "" // PAP Athentication user
#define PAP_PASSWORD "" // PAP Athentication password

#define DIALUP_SENDEXPECT "#CLIENTCLIENT CLIENTSERVER" //DIALUP_AUTH

#memmap xmem
#use "dcrtcp.lib"
#use "ucos2.lib"

//#use rcm43xx.lib
//************************* STRUCTURES & GLOBAL VAIRABLES **********************
typedef struct {
int ifx,attmpt;
int state;
}IfaceType;
longword destIP;

IfaceType iface;

int BringUpIface(IfaceType *);
int checkRx(IfaceType *pt_iface);

void task0()
{
INT8U err;

while(1)
{
while(!BringUpIface(&iface)); // attach to the GPRS network, & get an IP Address
while(checkRx(&iface))
{
OSTimeDly(1);
}

}
}
void task1()
{
INT8U err;

while(1)
{
OSTimeDly(10);
}
}
char u8RX_MsgBuf[1200];
static udp_Socket PPP_RAD_Sock;
void main()
{
iface.ifx = IF_PPPz;
iface.attmpt=0;
OSInit(); // Initialize uC/OS-II
sock_init(); //initialize TCP/IP
printf("Dynamic C CC_VER: 0x%04x.\n", CC_VER);
OSTaskCreate(task0, (void *)0, TASK_STK_SIZE, 4);
OSTaskCreate(task1, (void *)0, TASK_STK_SIZE, 5);
OSStart(); // Start multitasking
}

int BringUpIface(IfaceType *pt_iface)
{
if(pt_iface->attmpt >= 3)
exit(0); // currenlty, we just exit the program if modem fails to respond

tcp_tick(NULL);
switch(ifpending(pt_iface->ifx))
{
case IF_COMING_UP:
// wait for interface to up, chat will timeout if modem does not respond correctly
break;
case IF_UP:
printf("BringUpIface: Interface is up!\n");
pt_iface->attmpt=0;
ip_print_ifs();
return 1;
default:
printf("BringUpIface: Pending... attmpt = %d\n",++(pt_iface->attmpt));
ifconfig(pt_iface->ifx,IFS_PPP_INIT,
IFS_IPADDR , aton("100.1.0.5"),
IFS_PPP_SPEED,MODEMBAUD,
IFS_PPP_FLOWCONTROL,0,
IFS_PPP_USEPORTD,1,
IFS_PPP_SENDEXPECT, DIALUP_SENDEXPECT,
IFS_PPP_REMOTEAUTH, DIALUP_LOGIN, DIALUP_PASSWORD,
IFS_PPP_MODEMESCAPE,0,
IFS_UP,IFS_END);
break;
}
return 0;
}
int checkRx(IfaceType *pt_iface)
{
static int state;
unsigned long u32RX_IPaddr;
unsigned int u16RemPort;
int result;
#GLOBAL_INIT{state = 0;};
if(ifpending(pt_iface->ifx) != IF_UP)
{
printf("\nInterface is not up!!!!");
return 0;
}
switch(state)
{

case 0:
if (!udp_extopen(&PPP_RAD_Sock,pt_iface->ifx, 9000L, - 1, 0, NULL,0,0))
{
printf("\nCan't open socket");
return 0;
}
else
{
printf("\nPPP SOCK Opened\n");
state = 1;
}
break;

case 1:
result = udp_recvfrom(&PPP_RAD_Sock,u8RX_MsgBuf, 1200, &u32RX_IPaddr, &u16RemPort);
if (result < - 1)
{
printf("\nSock Error");
}
else if (result > 0)
{
printf("\nPPP_RAD RX : %d bytes\n",result);
}
break;
}
tcp_tick(&PPP_RAD_Sock);
return 1;
}
--- In r..., Tom Collins wrote:
>
> How large is the stack in each of your tasks that call tcp_tick()?
>
> There's a chance you haven't provided a large enough stack to one of your tasks, and a stack overflow is corrupting data in another task's stack.
>
> -Tom
> On Feb 14, 2011, at 7:09 AM, mohamed wrote:
>
> > actually, it tried to reduce the amount of the received data from 1100 to 100 byte but i'm still having the same problem and even i tried to use older DC 10.54 it still crashing and i didn't try DC 10.46 because it is not available on DIGI website.
> > but i tried the costate version of my code and it worked with no crashing, so is it may be something releated to ucos2 while using the PPP over serial port!!
>

Start a New Thread

Hello,

Thursday, February 17, 2011, 8:51:05, mohamed wrote:

I got the same recently when tried to build pretty simple app on Rabbit 3000 with DC 9.62 (three simple uC/OS tasks, only one uses TCP/IP). Spent 2 days trying to find problem, then switched to internal TCP/IP stack of GPRS modem.

-- 

Best regards,

 Yuri                          mailto:y...@ostry.ru

__._,_.___




















__,_._,___
Start a New Thread