I’ve just gone through the (5 hour) process to upgrade DS to 2.3.0 and set up all my projects with new toolchains, and get target management working*, but I’m having a problem I can’t solve with hardware compatibility.
The DS application seems to be based on Q2698 hardware - it only allows this selection in the project build settings, even though when I create a new project it can detect I am using SL6087.
But it won’t let me change the firmware package on my SL6087; when I try it claims “there are no firmware packages compatible with SL6087 connected Embedded module”
The SL6087 is currently running R7.46.0.201108091301, the latest firmware I had downloaded before my upgrade. The latest/only firmware package I have installed with the upgrade is 7.50.0.A1 (from application framework package 2.50.0.A1)
I thought all the packages were supposed to be compatible? If not, how do I know which package to download that supports my modem?
Or am I missing something?
the upgrade is not straightforward because there’s nothing in DS to indicate it doesn’t have a standard uninstall - you need to root around on forums to discover its a plain delete, then verify in the registry what depends on the folder tree and carefully delete only the DS components. That’s not very user friendly, and assumes a certain knowledge of the product’s design.
Changing toolchains is fair enough - at least the requirement to - but its not exactly just a selection from a drop-down. Once again you need to import a new toolchain type if you’ve never used it before (I only used the old ELF_GCC one before).
Target management is now super-packed with new features (I preferred the older view - too complex now) and as you might expect nothing “just works” - it throws up all sorts of obscure errors when trying to connect to the modem or change port values. The only way I could get it to work was to use autobaud (my modem runs at 19200) - manually selecting the baud rate just failed originally, something about “HAPC tests failing”, but it works now that its connected once. Not exactly confidence inspiring; I’d go for fewer features and higher reliability, but I’m probably one of a very few with that preference.
Spoke to my local agent and he suggested trying a different package (which was really the only option left).
So I installed the only package available from the default repository that was newer than what was already in the modem: framework package 2.51.0
This does in fact support the other modem types, and after adding this firmware to the projects I can select the SL6087 (which is included in a list of modems).
So I was using a package which seems to be strictly for the Q2698? And I guess that begs a repeat of the original question: How would you know which packages are for which modems?
I now bypass the original issue with downloading to a compatible modem - BUT, the download no longer works. It runs a series of checks, which all pass (they are detailed in the error dialog) then “switching in AT+WDWL mode” and fails on the first block.
Once again, you gotta love how this stuff just works… not. Does anybody know what I’m missing now?
So I’ve gotten through the last problem - seems you have to download a new version of the bootloader first. So there are various compatibility issues with this software architecture that the average user has no way of understanding.
Would it be too much to ask for at least some clues in the error messages as to why stuff isn’t working? You have to be a detective to use this software, and have very good instincts, and more than a few clues how DS is built. Not very helpful if you’re not sitting behind a desk playing with DS every day…
So having updated the firmware do you think it would “just work” now? No - can’t download an application. Having set up a new run configuration for the Open AT application on the target, rebuilt the app and tried to run it - the usual complex set of checks, all of which pass, then an obscure error dialog:
“Preparing the target for launch => ERROR. Timeout while handling command: blah, blah, blah.AtWdm2Callback”
What am I supposed to do with that? Post it here, in the vague hope that a Sierra engineer knows what it means. Wouldn’t it be great to have decent documentation, so you don’t have to be a complete optimist and hope to get problems solved on a forum…
Please can you elaborate a little on your environment before running the upgrade?
(because your comments trend to let us think you were using a pretty old release of DS: Target Management hasn’t change that much since DS 2.2.X for instance…)
Let’s just try to give you some useful clues:
concerning uninstall, there should be nothing else to do that remove the directory (OK, except the shorcuts in the Start menu and in the desktop). If you find something, please just tell, because we don’t see what it can be.
DS is not specific to a given hardware, and is completely driven by what is installed in the Package Manager. To let it run correctly, you need to at least install the Open AT Application Framework container package, plus the depending Firmware and OS packages. You may have troubles (e.g. in the project creation wizard) if you don’t install the container package.
concerning the Target Management, it’s true that there are many exchanges which are made with the device, requiring some bandwidth… You said you’re running the connection at 19200 bauds, and if you try to connect with DS at this speed, you will certainly have troubles. What we usually recommend is (of possible) to use the USB connectivity for DS. That’s the use case where we get the best experience. Maybe you can give a try?
It seems that you have many concerns, and we can support you to fix them, but please let’s take them one by one, following (your) priority order.
Have just spent about an hour trying to get the Sierra DS software to simply open the COM port to talk to the modem - with constant failures, even after shutting down both the software and modem.
I was able to ‘clear’ the modem port by connecting through hyperterminal, and then it connects in DS.
What the heck is Sierra doing with this comms interface ?!? It seems to be hopelessly unreliable now, unless there’s some new instruction required, which would amount to the same thing (hopelessly unreliable) since SiWi don’t publish instructions.
STill can’t download an application though - even doing a manual download in the target management view. It did give me a dialog saying the target seems to be blocked in bootloader mode, so no checks could be performed - it asked me to press OK to proceed, which of course I did, then it tried to do the checks anyway and failed.
What the?
What is “bootloader mode” and why would anybody want to be stuck in it?
Why would you turn this mode on by default (I certainly didn’t do it intentionally)?
How do you get this software to work!!!
Right now I just want to get my hands on a Sierra engineer; happily go to jail for life - it’d be better than working on this rubbish.
I * think* I was using about V2.0 - not sure without reinstalling it. It was still a very complex program but the target management just worked and worked well. I could download firmware, applications, never a problem.
I searched the regsitry and found a couple of references to installed plugins using the same directory as DS. Without any way of uninstalling them I have to accept a little registry pollution in deleting the old app - less than ideal but better than having two apps installed concurrently. I also have an “expresso” application installed in the same directory - just had to test to see it didn’t use any components outside its own folder, which you certainly can’t assume UNLESS YOU ACTUALLY WROTE THE SOFTWARE. Software that requires users to learn how it works is bad software.
I’ve installed the container package in each case. Don’t know hwo you would do it otherwise, and if its going to cause problems you probably shoudln’t allow the option
I need to switch to 19200 for my application, but not until i’s fully configured (UART1 is shared - because the hardware designers painted me into a corner with the selection of voltages and functionality on the UARTs). I can switch to 115200 for programming and configuring the modem, but DS won’t even reliably open the port at this speed. Well, it does sometimes. The older version of DS used to work fine - SO WHY DID YOU BREAK IT WITH NEW FEATURES. Here’s a good rule to follow: “if it aint broke, dont fix it”
I can’t use the USB, my hardware is not designed for it. It would be nice if we all just played around with dev kits all day, but I’ve actually designed this device into a real circuit (that doesn’t have and shoudln’t need USB).
OK, lets ditch all my gripes about too-many-pointless-features or the really poor documentation. I really just need the modem to accept the application. What do I have to do to the bootloader/firmware/configuration to get it to talk reliably?
First of all, if you don’t need to go to 7.51, you should go back to your former configuration (7.46 if I read correctly)
To achieve this, we need to communicate again with the device.
As long as the communication is not back to stable state, I would suggest you to use the “Open (production mode)” action instead of the standard “Open” action.
This will just open the port, nothing more.
From there, you can give a try to send AT commands to the console. Don’t hesitate to manually reset the device if you’re not sure of the state where it is.
Do this at several speeds (you’ll need to close/reopen (in production mode) the port each time) to find the speed your target is using.
Once AT commands are answering, we have to check if you’re really in bootloader mode.
–> This can be verified with ATI command for instance. If it answers ERROR, you’re locked in bootloader mode (meaning that the FW is corrupted on the device, and can’t boot).
From there, you can download the 7.46 firmware to restore your initial functioning.
This can be done by browsing the 7.46 firmware files (you have a button for that in the Package Manager) to find the DWL file for your SL6087.
Once you’ve located the file, launch a download operation in DS and point on this file.
DS will probably tell you that you’re blocked in bootloader mode (if it’s the case) because it can’t load information from the Firmware: confirm that you want to run the download.
Please give a try and tell if you can restore the 7.46 firmware to normal functioning.
We’ll continue from there.
I think this modem has been bricked by downloading the latest firmware/bootloader. I can’t open the port at all in DS anymore, and I have to power cycle the modem to get it to talk to hyperterminal.
In hyperterm, its outputting garbage characeters (development mode?) - there’s no AT command to switch off dev mode, at least none published. But it still responds to At commands.
Downloading the application DWL using XMODEM fails.
The reason I upgraded in the first place (call me a hypocrite) is to get a memory map of my application - the compiler should give an idea of how much program space you’re using but it was nowhere to be found in the older version of DS. Right now I’m thinking of scrapping the board and reverting the software; but that limits my upgrade options unless you guys fix this stuff. I don’t know how well tested your latest package is…
But opening the port in production mode DOES NOT just “open the port, nothing more”. It goes and tries to query a bunch of target information, including the IMEI, and blocks the port then throws an error.
Wish I knew where this option to browse for packages was - in the package manager I see a default repository which contains the 2.51 package and prior to this some really old stuff like 2.35. I don’t see a complete listing of firmware packages.
At least the interface gives me some clues - theres an AT+WDM=0 issued when I open in production mode…
Why does this software keep turing on DTR in the port monitoring section? Who asked it to do that? Is this another one of those aspects that assumes you have a dev board plugged in?
Yes, using the AT+WDM=0 (+ device reset) will restore it to production mode (should not answer garbage chars anymore in HyperTerminal)
So this means that you were not bricked in bootloader mode.
One important thing to notice about 7.51 (if you want to keep it) is that is may sometime fall in a frozen state where it doesn’t answer to DS commands anymore (in Development Mode). To workaround this behavior, you’ll need to uncheck the “Send AT commands requests in Development Mode” option in the Window > Preferences > Developer Studio > Target Management preference page.
Yeah, marginally helpful, since I did search the AT commands manual (7.43) - but I don’t make a habit of checking for new manuals when I can’t find a command I need. Would have thought development mode warranted being in there from the start, but we digress…
I have it in production mode (via hyperterm) and its reliably talking. Note that DTR seems to have been enabled; AT&V returns D:2, while my configuration always sets it to 0 - is this part of the connection in DS, noting that it seems to always turn on DTR in port monitoring (is there a way to disable this, can’t imagine why it would be default behaviour)
This last item is useful - Disabling AT Command requests; sounds like a good default position. Which AT command requests is it disabling - the stuff it uses to fill in the target details screen?
I am going to attempt connection in DS, and download the 7.46 firmware
Back on the road !!! - I have reverted to 7.46 and its working far more reliably, so I won’t be upgrading to 7.51 again.
Some observations here:
with the AT command requests disabled it appears to leave the target details all blank (as suspected) even in production mode, though the option mentions “development mode”. In this state the firmware package download option is not enabled (as firmware version is not known), so you need to manually find and download the correct firmware dwl. Guess you can’t have your cake and eat it.
as soon as you start a package download it reverts to development mode, and seems to do the queries as the target management details are all populated. I note the DTR function is turned back on too, though I can’t say for sure if I wrote it when I last changed it back to 0.
the size of the 7.51 firmware is reported as only about 660KB, while 7.46 is reported as 2200KB; thats a pretty significant difference?
there are differences in the start address for the application, for the two firmware versions. How does 7.51 handle an existing application using a 7.46 start address? Should the application be deleted before updating the firmware, or in fact a complete erase and build from the ground up (bootloader, firmware, application)
application size appears to have reduced by about 15% using the EABI_GCC toolchain over the ELF_GCC toolchain.
I can now build and download the application also; so there’s some pretty stark differences between firmware 7.46 and 7.51 on the SL6087 - well, one works and one just breaks in every conceivable way, but at least I can start moving forward again. Thanks for the help
FW 7.51 architecture changed: it is now composed of two binaries (cf new “Modem” section for the new secondary binary). FW 7.4X size is somehow equivalent to 7.5X FW + Modem size.
Yes the start addresses are not the same.
FW 7.5X is not able to handle the application located at 7.4X address: you’ll have to delete it and download the application built with the relevant address in order to let it run correctly.
- I have reverted to 7.46 and its working far more reliably, so I won’t be upgrading to 7.51 again.