Hi, I re-implemented on Unix system with threading, the code is basically 99% identical as the one I'm running on stm32. I double checked the priorities, and they are the same as on unix system. All relative to default thread priority
Also I only used tcpip_init() to initialize it, as far as I know I never touched raw LwIP API after that. However, by saying that, I just managed to get it working on stm32, by transferring my unix lwipopts.h config file to the stm32 and adding some stm32 specific defines to it. Honestly I'm not sure why it works, and what caused the issue, maybe you as an expert can get an idea why it works by quickly glancing at the two config files: Here is the original stm32 lwipopts.h: https://pastebin.com/LEueShJv And here is the one which started working https://pastebin.com/6E2mXCXr Thanks Best Regards. Raivis Strogonovs On Fri, Nov 3, 2017 at 6:17 PM, Sylvain Rochet <grada...@gradator.net> wrote: > Hi, > > On Thu, Nov 02, 2017 at 11:15:18PM +0000, Raivis wrote: > > Hi, > > > > I tested with UDP, and it didn't work. > > > > But, whole day, I've been working on porting the PPP GSM interface to > unix > > system. Took me a while since, I hadn't worked with LwIP at this detail > > before. > > > > Thankfully, I can confirm it works on my linux machine, but not on stm32. > > So I've probably made a mistake somewhere with stm32. > > > > Now that I have a working system, I can compare it to stm32 and see > > what goes wrong, and try to solve it. My main suspect is the way I'm > > using HAL layer for serial transmission. (which is still odd, since > > PPP get's the IP) > > This is not necessarily odd, the stack path is totally different between > a tx packet which source is the PPP stack itself and a tx packet which > source is external to lwIP such as a UDP or a TCP packet generated from > your user code. If you look closely at the PPP source you will see that > the path distinction actually goes down to the PPP low level protocol > (oS,oE,oL2TP). > > And it matters, it matters a lot, frames sent by the PPP stack itself > are mostly driven by received packets (we are negotiating with a > classical do-don't-will-won't manner), meaning tx caller is called in > the exact same context of the rx context. Rationale is the same for > packets sent from user applications, they are sent from the current user > application context (unless you are using one of messagebox driven APIs > indeed). Context for both output paths *MUST* *BE* the same. > > The more you say, the more I am suspecting a usual violation of lwIP > contexts (threads, interrupt handlers) requirements. Are you sure you > are using the proper PPPoS input API for your case ? Are you sure you > are not using lwIP RAW API outside your lwIP core context ? > > Sylvain > > _______________________________________________ > lwip-users mailing list > lwip-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
