Dear all,
I am now using DC 8.30 (PPP 1.04), R3000 CPU with 512KB FLASH
and 512KB SRAM.
My application is a GPRS device.
I found a strange problem in my application:
When I debugged my application with download cable, the
application can establish PPP connection (dail-up) quickly (in about
30 Seconds). But after I programed the application to FLASH, and make
it run freely, it would take about at lease 1 or more minutes
to establish the PPP connection.
I tried and tried but it is still there, I don't know the answer
for it.
Would you like to help me with it?
Thank you and regards,
SiMitel
12/22/2003
Strange Problem in GPRS(PPP) device ???
Started by ●December 20, 2003
Reply by ●December 20, 20032003-12-20
You have to see where is the problem. Try to see what’s happening on the serial line wyhen the communication is stablished. Look for an application note by Microchip, available in their web site, as how a PPP connection is stablished. I can tell you there are three basic negotiation, before the IP link is stablished .
LCP (Link Control Porotocol), PAP or CHAP depending on the authentication method and IPCP (Internet Protocol Control Protocol). If you can see exactly what’s happening in the serial line, using some serial analyzer, you can see exactly what’s happening.
If you don’t have a serial analyzer but some available serial port in your applicatrion to connect to the PC, there is a way to enable the PPP printf debug messages. Use the macro #PPP_DEBUG or something like that, an then a macro in which you can redirect the printf messages to a serial port, I don’t remember which is it, but you can see it in thde Dynamic C user’s manual. Then you can see exactly where is the delay in the PPP negotiation.
Dynamic C PPP stack is very unefficient, so we had to develop our own PPP stack, due problems we’ve had with Dynamic C stack. If you can afford it, consider it as an option.
Hope this helps
Juan Pablo Nari M
-----Mensaje original-----
De: simitel0299
[mailto:s...@yahoo.com]
Enviado el: Sado, 20 de
Diciembre de 2003 08:41 a.m.
Para: r...@yahoogroups.com
Asunto: [rabbit-semi] Strange
Problem in GPRS(PPP) device ???
Dear all,
I am now using DC 8.30
(PPP 1.04), R3000 CPU with 512KB FLASH
and 512KB SRAM.
My application is a GPRS
device.
I found a strange problem
in my application:
When I debugged my
application with download cable, the
application can establish PPP connection (dail-up)
quickly (in about
30 Seconds). But after I programed the application
to FLASH, and make
it run freely, it would take about at lease 1 or
more minutes
to establish the PPP
connection.
I tried and tried but it
is still there, I don't know the answer
for it.
Would you like to help me
with it?
Thank you and
regards,
SiMitel
12/22/2003
To
unsubscribe from this group, send an email to:
r...@egroups.com
Yahoo! Groups Links
To
Reply by ●December 20, 20032003-12-20
Message
You need PPP_VERBOSE turned on to get the debug (PPP_DEBUG just allows
the debugger in.) You should also set the debug level on that interface
using the appropriate ifconfig option. I believe 6 works well. This
is with DC733, so things may have changed in 8.x.
Take the time to read the RFCs on PPP if you're doing work
there.
-----Original Message-----
From: Juan Pablo Nari M [mailto:j...@etb.net.co]
Sent: Saturday, December 20, 2003 7:10 AM
To: r...@yahoogroups.com
Subject: RE: [rabbit-semi] Strange Problem in GPRS(PPP) device ???You have to see where is the problem. Try to see what’s happening on the serial line wyhen the communication is stablished. Look for an application note by Microchip, available in their web site, as how a PPP connection is stablished. I can tell you there are three basic negotiation, before the IP link is stablished .
LCP (Link Control Porotocol), PAP or CHAP depending on the authentication method and IPCP (Internet Protocol Control Protocol). If you can see exactly what’s happening in the serial line, using some serial analyzer, you can see exactly what’s happening.
If you don’t have a serial analyzer but some available serial port in your applicatrion to connect to the PC, there is a way to enable the PPP printf debug messages. Use the macro #PPP_DEBUG or something like that, an then a macro in which you can redirect the printf messages to a serial port, I don’t remember which is it, but you can see it in thde Dynamic C user’s manual. Then you can see exactly where is the delay in the PPP negotiation.
Dynamic C PPP stack is very unefficient, so we had to develop our own PPP stack, due problems we’ve had with Dynamic C stack. If you can afford it, consider it as an option.
Hope this helps
Juan Pablo Nari M
-----Mensaje original-----
De: simitel0299 [mailto:s...@yahoo.com]
Enviado el: Sado, 20 de Diciembre de 2003 08:41 a.m.
Para: r...@yahoogroups.com
Asunto: [rabbit-semi] Strange Problem in GPRS(PPP) device ???
Dear all,
I am now using DC 8.30 (PPP 1.04), R3000 CPU with 512KB FLASH
and 512KB SRAM.
My application is a GPRS device.
I found a strange problem in my application:
When I debugged my application with download cable, the
application can establish PPP connection (dail-up) quickly (in about
30 Seconds). But after I programed the application to FLASH, and make
it run freely, it would take about at lease 1 or more minutes
to establish the PPP connection.
I tried and tried but it is still there, I don't know the answer
for it.
Would you like to help me with it?
Thank you and regards,
SiMitel
12/22/2003Yahoo! Groups Links
To
Yahoo! Groups Links
To
Reply by ●December 21, 20032003-12-21
Thanks all for help!
But I think my problem is special, so I need to repeat it here!
I did use VERBOSE and DEBUG to debug my application, and it is OK and
establish the PPP connection very quickly. But when I disabled all
debuging options(breakpoints, watches, INT 28, etc), programed the
*.bin file to the FLASH via RFU, and poweron, my application started
to run from FLASH. In this case, I found it took much more time (than
in debugging mode) to established the PPP connection !
The application is the same, the difference is debugging it and let
it run freely.
Would you like to help me with it?
Thank you and regards,
SiMitel
22/12/2003
But I think my problem is special, so I need to repeat it here!
I did use VERBOSE and DEBUG to debug my application, and it is OK and
establish the PPP connection very quickly. But when I disabled all
debuging options(breakpoints, watches, INT 28, etc), programed the
*.bin file to the FLASH via RFU, and poweron, my application started
to run from FLASH. In this case, I found it took much more time (than
in debugging mode) to established the PPP connection !
The application is the same, the difference is debugging it and let
it run freely.
Would you like to help me with it?
Thank you and regards,
SiMitel
22/12/2003
Reply by ●December 21, 20032003-12-21
Message
You can also enable the debug with the program running from
flash. Just disable the insert INT 28 stuff, reroute the printf to the
port using the appropriate #defs:
/* Add
these line to redirect printf output at 57600 baud to serial port A.
*/
#if 1
#define STDIO_DEBUG_SERIAL SADR
#define STDIO_DEBUG_BAUD 57600
// Add this line to add carriage returns ('\r') to each newline
// char ('\n') when sending printf output to a serial port.
#define STDIO_DEBUG_ADDCR
#endif
#if 1
#define STDIO_DEBUG_SERIAL SADR
#define STDIO_DEBUG_BAUD 57600
// Add this line to add carriage returns ('\r') to each newline
// char ('\n') when sending printf output to a serial port.
#define STDIO_DEBUG_ADDCR
#endif
Then just download to the unit using DC. You'll
disconnect the programming cable and put the DIAG connector on and reset the
board manually. You'll then get debug out (just capture it using
Hyperterm or something.)
-----Original Message-----Thanks all for help!
From: simitel0299 [mailto:s...@yahoo.com]
Sent: Sunday, December 21, 2003 3:37 PM
To: r...@yahoogroups.com
Subject: [rabbit-semi] Re: Strange Problem in GPRS(PPP) device ???
But I think my problem is special, so I need to repeat it here!
I did use VERBOSE and DEBUG to debug my application, and it is OK and
establish the PPP connection very quickly. But when I disabled all
debuging options(breakpoints, watches, INT 28, etc), programed the
*.bin file to the FLASH via RFU, and poweron, my application started
to run from FLASH. In this case, I found it took much more time (than
in debugging mode) to established the PPP connection !
The application is the same, the difference is debugging it and let
it run freely.
Would you like to help me with it?
Thank you and regards,
SiMitel
22/12/2003
Yahoo! Groups Links
To
Reply by ●December 22, 20032003-12-22
Hi,
I encountered the same problem.
I think is a library problem!
In order to solve this I introduce a delay
between two successive append of TCP_TICK function but I cannot explain what
happened.
Below you have a samples cod that do
this!
....
while(ifpending(IF_PPP2) % 2)
{
tcp_tick(NULL);
{
tcp_tick(NULL);
ATime1 = MS_TIMER;
while(ATime1 + 80 > MS_TIMER);
if (MS_TIMER > (ATime+80000) )
{
debug_printf("PPP Connect timeout, failed");
return 0;
}
}
while(ATime1 + 80 > MS_TIMER);
if (MS_TIMER > (ATime+80000) )
{
debug_printf("PPP Connect timeout, failed");
return 0;
}
}
----- Original Message -----From: simitel0299To: r...@yahoogroups.comSent: Monday, December 22, 2003 1:36 AMSubject: [rabbit-semi] Re: Strange Problem in GPRS(PPP) device ???Thanks all for help!
But I think my problem is special, so I need to repeat it here!
I did use VERBOSE and DEBUG to debug my application, and it is OK and
establish the PPP connection very quickly. But when I disabled all
debuging options(breakpoints, watches, INT 28, etc), programed the
*.bin file to the FLASH via RFU, and poweron, my application started
to run from FLASH. In this case, I found it took much more time (than
in debugging mode) to established the PPP connection !
The application is the same, the difference is debugging it and let
it run freely.
Would you like to help me with it?
Thank you and regards,
SiMitel
22/12/2003
Yahoo! Groups Links
To
Reply by ●December 22, 20032003-12-22
Correct me if I'm wrong but I thought the printf redirect
does NOT use the interrupt serial lib so it slows your app
down the what ever baud rate your using?? --Original Message Text---
From: Dave Moore
Date: Sun, 21 Dec 2003 18:40:42 -0800
Message You can also enable the debug with the program running from flash. Just disable the insert INT 28 stuff, reroute the printf to the port using the appropriate #defs:
/* Add these line to redirect printf output at 57600 baud to serial port A. */
#if 1
#define STDIO_DEBUG_SERIAL SADR
#define STDIO_DEBUG_BAUD 57600
// Add this line to add carriage returns ('\r') to each newline
// char ('\n') when sending printf output to a serial port.
#define STDIO_DEBUG_ADDCR
#endif
Then just download to the unit using DC. You'll disconnect the programming cable and put the DIAG connector on and reset the board manually. You'll then get debug out (just capture it using Hyperterm or something.)
-----Original Message-----
From: simitel0299 [mailto:s...@yahoo.com]
Sent: Sunday, December 21, 2003 3:37 PM
To: r...@yahoogroups.com
Subject: [rabbit-semi] Re: Strange Problem in GPRS(PPP) device ??? Thanks all for help!
But I think my problem is special, so I need to repeat it here!
I did use VERBOSE and DEBUG to debug my application, and it is OK and
establish the PPP connection very quickly. But when I disabled all
debuging options(breakpoints, watches, INT 28, etc), programed the
*.bin file to the FLASH via RFU, and poweron, my application started
to run from FLASH. In this case, I found it took much more time (than
in debugging mode) to established the PPP connection !
The application is the same, the difference is debugging it and let
it run freely.
Would you like to help me with it?
Thank you and regards,
SiMitel
22/12/2003 Yahoo! Groups Links
To
Yahoo! Groups Links
To
does NOT use the interrupt serial lib so it slows your app
down the what ever baud rate your using?? --Original Message Text---
From: Dave Moore
Date: Sun, 21 Dec 2003 18:40:42 -0800
Message You can also enable the debug with the program running from flash. Just disable the insert INT 28 stuff, reroute the printf to the port using the appropriate #defs:
/* Add these line to redirect printf output at 57600 baud to serial port A. */
#if 1
#define STDIO_DEBUG_SERIAL SADR
#define STDIO_DEBUG_BAUD 57600
// Add this line to add carriage returns ('\r') to each newline
// char ('\n') when sending printf output to a serial port.
#define STDIO_DEBUG_ADDCR
#endif
Then just download to the unit using DC. You'll disconnect the programming cable and put the DIAG connector on and reset the board manually. You'll then get debug out (just capture it using Hyperterm or something.)
-----Original Message-----
From: simitel0299 [mailto:s...@yahoo.com]
Sent: Sunday, December 21, 2003 3:37 PM
To: r...@yahoogroups.com
Subject: [rabbit-semi] Re: Strange Problem in GPRS(PPP) device ??? Thanks all for help!
But I think my problem is special, so I need to repeat it here!
I did use VERBOSE and DEBUG to debug my application, and it is OK and
establish the PPP connection very quickly. But when I disabled all
debuging options(breakpoints, watches, INT 28, etc), programed the
*.bin file to the FLASH via RFU, and poweron, my application started
to run from FLASH. In this case, I found it took much more time (than
in debugging mode) to established the PPP connection !
The application is the same, the difference is debugging it and let
it run freely.
Would you like to help me with it?
Thank you and regards,
SiMitel
22/12/2003 Yahoo! Groups Links
To
Yahoo! Groups Links
To
Reply by ●December 22, 20032003-12-22
Message
Oh, it's slow. If you really want to do it right, you
rewrite to use your own serial functions. It does work as is though (well,
at least for me in 733).
-----Original Message-----Correct me if I'm wrong but I thought the printf redirect
From: Matt Linder [mailto:m...@micro-controls.com]
Sent: Monday, December 22, 2003 10:39 AM
To: r...@yahoogroups.com
Subject: RE: [rabbit-semi] Re: Strange Problem in GPRS(PPP) device ???
does NOT use the interrupt serial lib so it slows your app
down the what ever baud rate your using??--Original Message Text---
From: Dave Moore
Date: Sun, 21 Dec 2003 18:40:42 -0800
Message You can also enable the debug with the program running from flash. Just disable the insert INT 28 stuff, reroute the printf to the port using the appropriate #defs:
/* Add these line to redirect printf output at 57600 baud to serial port A. */
#if 1
#define STDIO_DEBUG_SERIAL SADR
#define STDIO_DEBUG_BAUD 57600
// Add this line to add carriage returns ('\r') to each newline
// char ('\n') when sending printf output to a serial port.
#define STDIO_DEBUG_ADDCR
#endif
Then just download to the unit using DC. You'll disconnect the programming cable and put the DIAG connector on and reset the board manually. You'll then get debug out (just capture it using Hyperterm or something.)
-----Original Message-----
From: simitel0299 [mailto:s...@yahoo.com]
Sent: Sunday, December 21, 2003 3:37 PM
To: r...@yahoogroups.com
Subject: [rabbit-semi] Re: Strange Problem in GPRS(PPP) device ???Thanks all for help!
But I think my problem is special, so I need to repeat it here!
I did use VERBOSE and DEBUG to debug my application, and it is OK and
establish the PPP connection very quickly. But when I disabled all
debuging options(breakpoints, watches, INT 28, etc), programed the
*.bin file to the FLASH via RFU, and poweron, my application started
to run from FLASH. In this case, I found it took much more time (than
in debugging mode) to established the PPP connection !
The application is the same, the difference is debugging it and let
it run freely.
Would you like to help me with it?
Thank you and regards,
SiMitel
22/12/2003Yahoo! Groups Links
To
Yahoo! Groups Links
To
Yahoo! Groups Links
To
