WipSoft has a link issue

Hello all,

I’ve been messing with a Fastrack Xtend modem based on the Q2687 (GPRS only) module. I’ve been having some success.

I am however hitting a build issue with the ready made sample project “WipSoft” which I believe to be the interpreter for the TCP/IP related commands. Now, I’m new to these modules but not a newbie to embedded programming. Compiling the ready made project leads to an error suggesting one section of code overlaps another.

I haven’t modified the code and I haven’t had any difficulties compiling any of the other samples. Indeed I have achieved my target results using the APIs. I would prefer to implement my work in AT commands instead though so that code is independent of the code on the modem for maintainability (and frankly, speed of implementation) since this is a one off project.

On the whole the results are good but this issue is a bit weird. I wouldn’t have expected it from an out of the box example and it’s quite a prominent module.

Here is the actual error message:
section i.wipint_smtpClientSendCommand loaded at [0028d188,0028d1eb] overlaps section .data loaded at [0028d188,0028de8f]

And the WipSoft package is version: 5.40.0.201007290812 (!)

I’d be interested to see what anyone has to say,

Thanks

I’m surprised that no one else has had this issue. The pre-compiled binary is okay but I am loathe to touch code which is likely to have shipped working!

Maybe just not many people use WIPsoft…

Maybe so:

  • if you’re creating an embedded application, I’d have thought it better to use the WIP API;
  • if you’re not creating an embedded application, why would you be rebuilding WIPSoft?

We’ve had the same issue, I think it got solved by changing a build target to ELF.

awneil: Why not? If you quickly want to set up a the modem to connect to a server with AT commands and then forward data from the USART to the server via GRRS, the “WipSoft application” seems like a good start.

I just don’t find that messing about with AT commands is a particularly “nice” way to do stuff programatically - I’d far rather use a proper API

See: New Features - Complete API

Also, with AT-commands being text-based, there are issues when dealing with binary data…

To the person who did comment about the building of WipSoft failing, thanks for the reassurance and I’ll investigate that ELF issues further. I wonder what I’m building currently. I want to be able to build it for my own peace of mind. I don’t actively plan to use my own builds if I can help it!

awneil,
As I mentioned, working through the AT command set is a bonus since it

  1. stops me from needing to maintain two toolchains and their histories for one project (one for the micro on the device and one for the modem) and indeed learning new hardware and the API associated with the modem.
  2. means that I only have one set of code to maintain for the project
  3. seems the AT command set is actually not that complicated. The manuals look awful because the functionality is so great but I have set up both UDP and FTP command sets that are actually only a tiny handful of commands.
  4. is the most industry standard way of communicating with modems. You stick a modem on a serial port and send it AT commands. That’s how it’s done!

I realise the Sierra modems are capable of much more than that and as I’ve read in a few other threads there are people who could actually transfer their entire project onto the modem and ditch the rest of their board(!) but for me, I just want a modem! And for code maintainability, everyone knows how to shove data out through a serial port on a microcontroller.

I feel quite bad for sounding so harsh but it’s simply a perfectly appropriate solution for this project! There are no compromises.

Yes that makes perfect sense if you’re just using the SiWi device as a normal, “dumb” modem - but, in that case, why would you be building WIPSoft?

Well I initially tried building WIPSoft because its existence as a pre-built binary is not documented. I found that by accident. The installation of WIPSoft in any situation is not documented. It was sometime before I even downloaded the developer tools to try get clues. Call me naive if you will but I didn’t feel the need to download a C compiler at roughly half a gig to install a pre-compiled 2MB binary that is mentioned on virtually every relevant page.

The getting started documentation on these is really poor. Infact it just doesn’t exist. Which is a shame because the modems themselves are incredibly good.