lwIP mailbox issue on initialization

[zeroping]

Hi, I'm trying to get something (anything) working with lwIP on a custom board with an STM32F107 using the stable_3.0.x branch. I've mostly built it off of the STM32F407 lwip demp. I'm now stuck, as I'm trying to debug in the middle of some rather large pieces that I don't fully understand, name lwIP and ChibiOS's mailboxes.

Once I call lwipInit(NULL), which then kicks off the lwip_thread, I see lwIP bailing out with "tcpip_thread: invalid message". It looks like the tcpip_thread is calling sys_timeouts_mbox_fetch and getting back a message which is trash (random-ish message type, etc). I can't figure out exactly what makes this mbox think that it has a message, but I'm trying to piece together how it's getting triggered (I'm learning how the mbox'es work).

Things that I checked that might be important:
- sys_mbox_new is getting called, and the mbox structure looks sane enough (to my untrained eye).
- doubling or quadrupling the stack sizes of lwIP doesn't seem to help.
- I haven't seen any calls to post to that mbox yet, but I might be failing to watch those calls.
- mbox->mb_fullsem.s_cnt goes from 0 to -1, then back to 0, but never goes positive.
(In fact, that semephore is incremented from -1 to 0 in chSemFastSignalI, triggered from a wakeup from a timer, even though that macro says "This macro can be used when the counter is known to be not negative". Should I be worried about that?)

Now, here's the really strange part. I have a very similar demo (basically the old ARMCM3-STM32F107-LWIP webdemo) from sometime in the ChibiOS 2.7.x range, and it works fine. It initializes lwIP, brings up the PHY, and serves packets, all on the exact same hardware.

So, I don't think it's my hardware (it works with this 2.7.x code), and I don't think that lwIP is the issue (the source is the same), and I don't think it's ChibiOS's mbox or semaphore code (or else everyone would have issues), so I'm out of ideas. How much changed with lwIP when we went to 3.0? From what I saw it was pretty minimal. Has anyone else had similar issues?

Any thoughts on where to look would be appreciated. I'm somewhat lost when watching all these calls go past - debugging a timed out mbox fetch is a rough way to learn how mbox'es and semaphores work in ChibiOS.

[Giovanni]

Hi,

What is the mailbox returning? could it be a MSG_TIMEOUT? please also enable the assertions, checks and state checker in chconf.h and see if something is caught.

Giovanni

[steved]

Very little changed in the lwip code between 2.x and 3.x AFAIK; there have been some recent changes simplifying initialisation, which are largely cosmetic. There are also a couple of recent threads in the General Support forum, although don't think they'll be directly relevant to your problem.

Have you checked stack allocations? I found that the defaults were too small if certain options were enabled - on the 32F4 I've set 672 bytes as the minimum (needed with DHCP); 1400 bytes if using SNMP as well. And possible that stack requirements might vary for the same code from processor to processor, and also due to driver differences on different platforms.

[zeroping]

Just to give a quick update, it look like sys_arch_mbox_fetch is returning 0xffff, not 0xffffffff (SYS_ARCH_TIMEOUT).

I'm on an STM32F107, so I don't have any 32-bit timers sitting around, and thus CH_CFG_ST_RESOLUTION is 16, not 32. This is a big change that came with tickless in 3.0, right? I suspect this is how I've ended up with something untested, and I bet that building the ST32F407 lwIP demo with 16-bit timer resolution would cause the same bug.

I'm still running down the right fix, but I'm not there yet, any may not get back to it until tonight (GMT-4). At least now I have a big hint about where to look.

-Scott

[Giovanni]

Please keep us updated, this looks like an error or wrong assumption is sysarch somewhere.

Giovanni

[zeroping]

It turned out to be an issue due to 16-bit vs. 32-bit systick counter resolution. I found a one-line fix.

Juv1228 helped me find a second bug where the vector name for the Ethernet interrupt doesn't get #defined for STM32F107, so the Ethernet interrupt just ends up being _unhandled_exception. That took me a while to find.

My hardware is now working nicely, and I'll get real bug reports and patches in sometime this weekend. If you think it's a good idea, I can try to package up a demo for STM32F107 using lwIP, but it would rely on my funny custom hardware. I don't even think there are any STM32F107 dev boards with Ethernet.

-Scott

[Giovanni]

Great, waiting for the patches

Giovanni