I tried various way's compile and update the firmware on my CC2650 Sensortag, more or less failed that.
Now I want the original functionality back. So I went to where I installed BLE 2.02 (simplelink\ble_sdk_2_02_01_18\examples\hex) and fetched the cc2650stk_sensortag_rel.hex. Programmed that with SmartRF. Now the Sensor tag is back in "near" normal operation. If I detach the programmer, remove the battery, then attach battery. The Simplelink on my Iphone can see a Sensortag 2.0. It notice when I push the buttons, but I can't see anything when using/pushing Sensor view or service explore. What can I do to get it back in it's original working state?
I don't know if I somewhat bricked the device trying to go over to Zigbee OTA and then trying to build/debug the IT resource explorer CC26xx Bluetooth Smart.
This is embarrassing. The SensorTag was working all along, a very important step was missed. Since I already tried uninstall/install the iPhone app I didn't think of switching off/on my bluetooth. The last step fixed the issue. Somehow settings where cashed there.
I've run into a funny problem. Our app, which was working prior to Saturday, can't connect to the server to get the necessary data. The server is fine, everything is up and running and I have rebooted it. The Support Tech has said the same. So it points to either the code having something that didn't change, or the ip/database info changed and the code is using the old info; as far as I know, we've changed nothing. Will I have to check the code?(I didn't write it, someone was hired to do it) or is there something else that could be causing the problem?
The error message:
"The app is currently unable to connect to the server. Please try again."
It's a very unspecific error message so I'm assuming the developers of the app put that specific message in themselves.
Assuming you have the app on an iPhone you may be able to diagnose (but not necessarily fix) this without getting into the code. Download Fiddler and use this tutorial to setup the iPhone so you can watch the network traffic. This will allow you to see exactly what requests the app is making to the server and you may be able to figure out the problem. Either your request isn't making it to the server or the server is returning an error message. Either way Fiddler should be able to give you that answer.
EDIT:
HTTP Scoop is a pretty easy to use client for the Mac that does what Fiddler does for PC. You can use it for free for 2 weeks so that should be enough to help you out.
Charles would also work. I know you can get a free trial for that as well.
I would like to profile a running app without a computer attached. Pretty much what the sample command does on Mac OS X. Is it possible ?
I would like to do this without any computer attached because my app gets into an endless loop only at certain GPS locations. I tried reproducing the problem by faking GPS fixes but I couldn't. Yet the issue is 100% reproductible in the field…
You can try logging suspected method and loop entry/exits to a file, and recover the file later using iTunes Document sharing or Xcode.
No - I'm pretty sure it isn't, as Apple does not allow developers to use any iOS-development tools on the platform itself. You might be able to build analytical stuff into your own app (RAM monitor etc.), but not by using another app.
Anyway, your computer is much better suited to the task than a device - so sick with it.
Maybe some day Apple will let us test/write iPhone apps from iPads...
Hey everyone, I'm in a bit of a pickle and am looking for some advice.
I have an app that's been released to the app store..nothing special just a first time sort of thing. The app runs perfectly fine on my device(s) but a couple buddies always get a crash.
So here's the details:
It crashes by sometimes stalling and other times by just exiting to the main screen.
I've tried to replicate the crash (or any crash) using
the same iPhone generation/model
on an ipod touch as well
the same OS
different OS
using debug/release/distribution/downloading from app store builds
since it's an app that connects to a google maps service, I've tried with both
a wifi connection and the att network.
The only thing that MAY be different is any other apps on their phones that are not on mine.
The fact that I cannot replicate with exactly the same setup leads me to believe it's a memory issue, maybe uninitialized variables or incorrect cleanup at some point (i'm from C++, so I know this sort of thing can vary from machine to machine). I'm somewhat new to obj C and may very well be missing something there. I'm just curious to hear what others have to say, does this sound like a memory issue with the info I've provided? Any other ideas to test/suggestions come to mind to try and reproduce the crash?
Thanks!
One possibility is that it's a backgrounding issue. You don't say whether your app tries to use those features or whether your friends experience the crash in that context, so it's hard to say.
I would provision your friends with a beta that logs verbosely if you can't pin it down.
Has anybody had any success ever attaching a debugger to a tethered device? I am able to debug my j2me application in the emulator, but have a lot of trouble sorting out phone-specific problems when they come up. The phone I'm using is a Nokia N95, but ideally the debug process would work on any phone.
Is this possible? If so does anyone have steps they've used to set it up?
Sony Ericsson supports debugging on ebery phone at least since K700, this is done by using KDWP. UIQ 3 communicators also can be debugged the same way.
By the way, it the latest phones by SE it is even possible to monitor memory consumption and CPU profiling. So if you wanna debug your apps on real phones, I would suggest also using SE phones, they are really good at it. I use Netbeans, and it works without any problems with any SE phone.
Motorola phones support a debugging interface called KDWP(Motodev registration required).Their MIDway tool can also be useful for getting debug trace information from a midlet running on a device.
As other stated, on device debug is something that strictly depends on manufacturer's will and often it's nearly impossible. However, i can address you to Gear Java Mobile Framework that gives you the opportunity to use an on-device debug console to print your messages and thus read phone specific issues. If you need some explanation on how to use it, take a look to this tutorial
Unfortunately this is not generally possible. Some makers (like Sony-Erricson) support this on some of their phones but not all. I am not sure if there is on-device-debugging tool for N95 but you can use Nokia's emulator which should be pretty close to the device. The new Java ME SDK comes with promise of real ODD in near future. But it still very much depends on OEM cooperation.
I find a good debugging method is to control a string value which gets painted on top of everything else when it is not null. This will work anywhere, though obviously isn't ideal, but can be used to catch Exceptions, print values etc. Of course you're limited to the small screen, but in theory you could even code some scrolling functionality.
Some people use RMS logging but personally I could never be bothered.
As others have said here, Motorola have Midway which I think is great.
Others are correct here in that on-device debugging is very much device specific. I haven't done anything with Series 60, but at least on Series 40 phones, I had to open up a CommConnection and write out to it in order to see much of anything going on. The device emulators are again a mixed bag, but you usually can get 90% of the way to your application working on them and can usually get your debugger connected to them. If you aren't making use of any of the hardware on the phone, that should get you most of the way there.
I've used the Blackberry tools on occasion to debug J2ME applications (without using RIM APIs) but it is very slow and still is only emulation, not the actual device (but it sometimes does help to shake the odd thing out). I agree it is frustrating when you have something running on an emulator only to find that it doesn't run on the hardware.
You can not debug step by step like android or other SDK.
In J2ME you can trace the error by adding the log statement in the code and add another midlet and display that log screen in that midlet.
Example: add Log.p("Log statement.....");
LogMidlet.java
// Add the following line in the startup method of this midlet.
Log.getInstance().showLog();
This way you can somehow track the error in j2me.
I think it is possible to add additional debugging information on preprocess step. Like this:
public void myMethod() {
Debug.traceMethod("myMethod");
int var = 1;
Debug.newLine();
var++;
Debug.newLine();
...
}