lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] PPPos problem LWIP2.1


From: arsz6733
Subject: Re: [lwip-users] PPPos problem LWIP2.1
Date: Sat, 15 Dec 2018 08:32:54 -0700 (MST)

I really appreciate your help by now 
Patrick Klos-2 wrote
> On 12/15/2018 12:21 AM, arsz6733 wrote:
>> here is my polling while()
> 
> So you are running on a multi-threaded processor with one thread 
> handling your poll loop?  How many other threads are running on your
> system?
> 
>>
>>
>>              // *** LOOP: Handle GSM modem responses & disconnects ***
>>              while(1) {
>>                      memset(data, 0, BUF_SIZE);
>>                      int len = uart_read_bytes(GSM_UART_Port, 
>> (uint8_t*)data, BUF_SIZE, 30
>> /
>> portTICK_RATE_MS);
> 
> If uart_read_bytes() is WAITING to get BUF_SIZE bytes, then you need to 
> change this to only request 1 byte at a time.
> 
> What is your timeout value (30/portTICK_RATE_MS)?
> 
> Also, where is uart_read_bytes() getting the data from??
> 
>>                      //DEBUGOUT("\n\r%s\n\r",data);
>>                      if (len > 0)    {
>>                              pppos_input_tcpip(ppp, (u8_t*)data, len);
>>                      }
>>              }
>>
>> and this is with interrupt I enabled PPP_INPROC_IRQ_SAFE
>>
>>
>> void UART3_IRQHandler(void){
>>              char ch;
>>              ch=UARTGetChar(LPC_UART3);
>>                      UARTPutChar(UART_0,ch);
>>      }
> 
> This doesn't make sense.  Why are you reading from one serial port and 
> sending the byte to another serial port?  Where do you buffer the data 
> that is received???
> 
>> and here is the log more or less
>>
>> pppos_input[1]: got 1 bytes
>> }pppos_input[1]: got 1 bytes
>> #pppos_input[1]: got 1 bytes
>> Àpppos_input[1]: got 1 bytes
>> !pppos_input[1]: got 1 bytes
>> }pppos_input[1]: got 1 bytes
>> !pppos_input[1]: got 1 bytes
>> }pppos_input[1]: got 1 bytes
>> !pppos_input[1]: got 1 bytes
>> }pppos_input[1]: got 1 bytes
>>   pppos_input[1]: got 1 bytes
>> }pppos_input[1]: got 1 bytes
>> 2pppos_input[1]: got 1 bytes
>> }pppos_input[1]: got 1 bytes
>> "pppos_input[1]: got 1 bytes
>> }pppos_input[1]: got 1 bytes
>> ~pppos_input[1]: got 1 bytes
>> pppos_input[1]: Dropping bad fcs 0x2a65 proto=0xc021
>> pppos_input_drop: pbuf len=11, addr 10000098
>>
>> any new suggestion? I wonder where I'm doing wrong
> 
> Depending on how your debug output is handled, your printf()'s could be 
> taking too much time and causing the overrun on your PPP serial port?
> 
>> I commented the ppp debug that was showing the buffer length and now I
>> see
>> new actions are happening
> 
> As I suspected.
> 
>> let me know if I'm in the right way of I'm fully out
>>
>> ppp phase changed[1]: phase=0
>> initialized PPPoSppp_connect[1]: holdoff=0
>> ppp phase changed[1]: phase=3
>> pppos_connect: unit 1: connecting
>> ppp_start[1]
>> ppp phase changed[1]: phase=6
>> pppos_send_config[1]: out_accm=FF FF FF FF
>> ppp_send_config[1]
>> pppos_recv_config[1]: in_accm=FF FF FF FF
>> ppp_recv_config[1]
>> ppp: auth protocols: PAP=1 CHAP=0 CHAP_MD5=0
>> sent [LCP ConfReq id=0x1 
> <asyncmap 0x0>
>  
> <magic 0xcac73227>
>  
> <pcomp>
>  
> <accomp>
> ]
>> Outputcallbacklenght44
>> pppos_write[1]: len=24
>> ppp_start[1]: finished
>> rcvd [LCP ConfReq id=0x1 
> <asyncmap 0xa0000>
>  
> <auth pap>
>  
> <pcomp>
>  
> <accomp>
> ]
>> sent [LCP ConfAck id=0x1 
> <asyncmap 0xa0000>
>  
> <auth pap>
>  
> <pcomp>
>  
> <accomp>
> ]
>> Outputcallbacklenght42
>> pbuf_free: p->ref > 0:753 in file
>> ..\..\..\..\..\..\software\lwip\lwip\src\core\pbuf.c
> 
> That's better.  What happens next?
> 
> How much memory do you have available on this processor?  Maybe you can 
> set aside some memory to store debug messages rather then trying to 
> print them in real time?  Then you can view the messages later where 
> viewing them won't have an impact on the PPP link??
> 
> It seems I now have a memory problem it may takes me  1 day to be able to
> test it again 
> I will tell you about that
> 
> Patrick Klos
> Klos Technologies, Inc.
> 
> 
> _______________________________________________
> lwip-users mailing list

> lwip-users@

> https://lists.nongnu.org/mailman/listinfo/lwip-users





--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]