WiFi connection lost after time

[Sailing_Nut]

Did some more testing and I got the board connecting to my AP again. (One with a stronger signal than the original one that I had been connecting to.) This test yields the same result as I was getting before. I connect to the AP then the test runs for a bit and hangs. (It stops producing serial output as well as stops responding to pings.)

I'm trying to set up an AP right next to the board to eliminate any possible interference problems, but I'm having some of my own network challenges.

[Sailing_Nut]

So I FINALLY had some time to mess about with this again.

I got an AP set up right next to the board and I'm still seeing it hang. I have seen it fail on 3 separate runs. The last one I captured a Wireshark trace of the port 1900 traffic. The board with your UDP sample never printed to the serial port that it saw a single UDP packet. However my Wireshark trace shows 3 messages came across the wire around the time of the hang.

I'll send you the Wireshark trace in a PM (If that is allowed by your forum software.)

[Sailing_Nut]

So I've finally gotten back to testing on this and found what I believe to be the smoking gun!

I started slowly moving my SSDP code over into the working example and found a point where it broke. This time it was reliably breaking at the same point. I narrowed the problem down to creating a char[1024] buffer in a function in which I was storing a message to be sent. If I increased it to char[2048] (to ensure that I was not running off the end) the program did not run at all. I then changed it to a char[512] and it now works reliably! I then moved the buffer to be a global and at the 2048 size I was getting compiler errors. At 1024 no errors, but the program locked up. At 512 it works reliably.

So, there seems to be a lot of memory being used up by static buffers. I'm not sure what memory space the compiler is using for these but I think it's time to put the program on a diet!

@Carl

Any suggestions as to where I might be able to trim memory out of any of the libraries?

[Carl-SolderSplash]

Creating large local buffers is something to be avoided as they use the stack. Compilers handle the stack in different ways, some the stack works down from the top of RAM and if the stack is large enough it will then start to overwrite your global's causing all sorts of random issues. These issues are hard to find with a jtag, so without is even harder!

The CC3000 library has a few buffers you can tweak to save space as we have discussed previously

The LPC1347 has Two other RAM banks that are not powered by default. Details here : http://developer.mbed.org/teams/Solder- ... -with-mbed (in the Tips section)

Try putting some of your large buffers in one of these RAM sections

[Sailing_Nut]

Carl,

Thanks!

It is still somewhat "bumpy" as to when I make changes if it works or not, but I think I have a handle on that.

It appears that all of the original work you did with these projects were done as a Keil uVision project and then imported into the online compiler, is that correct? The reason that I ask is because I am trying to export to another offline toolchain and most of the options are grayed out. I was able to export to Em::Blocks but the resulting project does not function properly because (based on the hunch of someone at Em::Blocks) of the project originally being a Keil UVision project. Is there any way that you can create a project directly in the online compiler that can then be exported to other toolchains?

Thanks!

[Carl-SolderSplash]

I've only used the mbed compiler for the mbed stuff. I think one of the guys that worked on the CC3000 library had access to keil license. He might have used that.

I tried to use the free lpcxpresso but the compiler wasn't as good as mbeds/keil. Keil's compiler gets the same optomisations as the mbed one does.

I don't know of a free offline compiler that will allow offline mbed use.

[Sailing_Nut]

Carl,

Thanks for the response.

I did a test after posting this and I created a project from scratch and it seems to have the same limitations.

I also did a test with just the mbed libraries and it seems to be a limitation of the mbed export for the WiFi DipCortex. The folks at Em::Blocks said that if the GCC export was disabled that it would not work properly and that is the case when choosing the WiFi DipCortex as the target.

Any clue how we can get better exporter support from the mbed team?

[Carl-SolderSplash]

They pull changes in via their Github so if we wanted an exporter for gcc/lpc xpresso that's the place to start.

It's only worth the effort though if the latest lpc xpresso/gcc optimiser has improved enough to be able to fit the output on the processor.

I would have another look but I am a bit short on time.

[Sailing_Nut]

OK, thanks for the info.

I'm really jonesing for an offline toolchain so that I can actually do some debugging with a proper debugger.