Shamelessly I copy something I found in the Blackberry forums. I don’t know what it means but I DO know it’s one of those things that you have to search far and wide for. Some guy wanted to get into some debug mode that I’d never heard of so he posted his question then later his own answer to the forum thread. Read the solution below:
1. Have a login/password to https://www.blackberry.com/EngineeringScreens/ (updated 5/30/2008)
2. On the BlackBerry pres ALT+CAP+H and leave it on this screen.
3. Once logged in to the link on #1, you will be asked to enter your PIN#, Uptime and Zip code of where your device is.
4. You will then receive a unlock code that is specific to this information (if you exit out of this help screen on the blackberry, the uptime number will be different thus your code will be different.)
5. Then enter the unlock code on the BlackBerry, holding the ALT key for numbers, capitals are not necissary.
6. This will give you access to the Trace Mode Engineering App
7. Select “Radio Engineering” screen
8. Select “CDMA Engineering” screen
9. Select “Operational Info” (2nd line ec/io, 3rd line rss)
10. Scroll down to “Neighbor Set Details” and get 1st line Active Pilot, 2nd through 20th will give Neighbor sites with ec/io for each.
*This code will only work for 30 days, then you will need to get a new code in the same way.
I just ran the Blackberry compiler from Maven… on my Mac. Two cans of Pabst Ice and one Mike’s hard cranberry lemonade into my dev cycle and I finally see a “.cod” file show from a pyx4Me project! It’s in the wrong folder, project root vs. projectroot/target but I can live with that for now. Anyone know a groovy way to set the working directory from a command string run by the overloaded String.execute() method? I don’t wanna call out to Runtime.exec and I don’t wanna write a bunch of platform checks in my plugin. Right now I’m one too many drinks swallowed to know whether or not String.execute() implies platform. In other words I don’t know if I need to code a prefixing “cmd /c ” on my string and check for Windows before calling String.execute(). I’m not happy with the impl because there were a few things I wanted to do better. Right now I’m spawning a java process because the GMaven plugin doesn’t set the rootLoader, which means I can’t dynamically append to my classpath. I’ll either have to set the rapc.jar as a dependency or figure something else out. I’m just glad I got this far! More updates later…
If you own a Blackberry device and you like to play with things, like ringtones or wallpapers, or games, or if you develop software for Blackberry devices like I do then listen up! That’s right, put your ear next to your web browser and listen! There’s a new threat for computer hardware and it effects you Blackberry users. It’s the white screen of death and it manifests as an infinite rebooting sequence. It’s scary as all heck, especially if you’re about to release Beta and have 160 manhours of testing to complete in the next day and a half and a strict policy on company issued Blackberrys that mandate you are not allowed to crack open the casing and tickle the electrons on the circuit board. (I know, what a dumb policy, right?) Here’s the solution I found while frantically scouring the web. The short answer is to use the application loader to perform a device wipe. You have to connect while the thing is on the white screen I think. However I kinda don’t think it matters because my (BB) screen went dark right after I entered my password, leaving me wondering what in the world the application loader was actually connected to since the phone was obviously dead. I would never have figured this out in a million years. I was going about it all wrong. In my dumb brain I thought, “Why not hook up to the backup and restore console in the Desktop manager? Because I wanna restore my Blackberry, right? I’m not trying to load applications, I wanna remove everything and start from scratch!” Well for what it’s worth hook up to the Desktop Manager application loader to fix a constantly rebooting Blackberry.
(Oh and here’s the best part! Right after I finally got it to start the wipe sequence a coworker asked me a question causing me to rotate my chair clockwise while the USB cord was threaded through the armrest resulting in a catastrophy that ended with the yoinking of my device from the desktop hitting the floor, and disconnecting the cable. I’m not sure what this is going to do to the restore because it’s still restoring as I update this post but I’m sure its not a good thing to disconnect the USB cord on an OS restore to an already malfunctioning device. It can’t be much better to rebound said device off of the floor.)