S60 Open to new features

The Carbide team worked closely with the N-gage SDK team on Carbide 1.3 to try to meet the demands of getting a workable development environment for a unique set of developers. But, I admit, we fell a bit short in a couple of key areas that we plan to look at fixing so we'll have a more complete solution. So I'ld like to talk about these shortcomings and some ideas on what we might do in our next release, Carbide 2.0 since some of these improvements will benefit all developers who do on-device debugging with Application TRK.

The feedback that we are getting from users when they try to debug with TRK over Bluetooth is rather unsatisfactory. One requirement is to have a serial port service over the Bluetooth is confusing, since by default it doesn't come with many Bluetooth enabled devices and users have to go to manufacturers sites to get it. The second one is to specify "Port" number on device to connect to. This is not really a port but rather service index on the host PC.

In Carbide 1.3 we now display information when a panic has occurred when doing on-device debugging.

The user will now see the stack crawl display that a panic has occurred. The panic number is shown in the StackCrawl-Thread information at the top. The top frame will be the User::Panic() code. It will have source if Euser has symbolics and disassembly otherwise. The next frame will be the caller of User::Panic() only if symbolics exist for that location. Otherwise it will be in disassembly. The application will exit and the debug session will terminate when the user resumes.

CodeWarrior has a great feature in the debugger view to display the program under debugging in 'Source' mode, 'Disassembly' mode and "Mixed" mode. When your breakpoints are not hit or when the stepping in your program seems bogus (stepping causes program counter to jump up or down in the source file under debugging) it is invaluable to switch to debugging in 'Mixed' mode and see if the C++ sources match the ARM disassembly code. Sometimes the code is optimized and program counter will jump up and down then you can verify whether the debugger is doing the right thing by looking into the ARM code to determine the root of the problem.

We always try to improve and/or simplify debugging experience for our users and there was quite a few entries about this subject already. But the topic of ROM vs RAM debugging wasn't covered yet.
You will get the most benefits when debugging with TRK by downloading your program in RAM or installing .sis file onto the phone. This is because the typical development cycle - modify code, build project, download binaries to the phone via TRK - is very short. Some power users however prefer to debug their binaries from ROM. Usually this is only available to OEM developers and contractors - people who can flash their phone with the OS image. In this case the development cycle is longer, since after modifying and building their program users need to build the phone image as well as flash it on the phone, not to mention make sure that the symbolics files on the PC is matching the binary that they are going to flash on the phone.

The executables view was a great addition to the tool by providing a dymanic list of executables and their source files in an easily accesible area. We've had a few customers who asked for some clarifications on how they can use this view to help them hit breakpoints in DLL's that are launched by their executable.

When using on device debugging in the previous versions of Carbide, there were quite a few limitations when debugging libraries. Almost all these limitations are addressed in 1.3 release. By default, all the executables from the SDK for a particular build configuration will be targeted automatically for debugging. To further illustrate, lets say you have the application main executable "app1.exe" which links against multiple libraries like lib1.dll and lib2.dll. Lets assume that lib1 is a static dll and links against another static dll say lib2.dll and lib3 is a polymorphic dll. Also assume that you have a ECOM plugin say plugin1.dll as part of this application.

In Carbide 1.2, you were able to debug lib1 and lib2 fine since lib1 is a direct static dependency and is available from the dependent library list of the main executable that is being launched. Since lib2 is a polymorphic dll, the debugger would get a notification when the dll is loaded. It was not possible to debug lib3.dll in 1.2. Also it was not possible to debug plugin1.dll. The limitation was that nested static dependent libraries were not targeted for debugging and there was no library load notification for ECOM plugins, even if there is one, it would have been missed anyway since the ECOM plugins are loaded at OS bootup time.

In 1.3, we have added support in Carbide where Carbide debugger would try to get the load address of all the executables either built as part of the project or imported into executables view. The load address of the static libraries is available as soon as the process is launched, so lib1 and lib3 would be targeted right after the process is launched. Like before, lib2.dll would be targeted when the dll loaded notification comes from the target. Carbide debugger would be able to get the load address of the ECOM plugin as well since it is loaded at bootup time and so it will also be targeted.

Also another addition in 1.3 is that when you attach to a process, then also the Carbide debugger would try to get the load address of the untargeted executables. This is very useful if you are debugging a client server application, where the client launches the server or the server is already running. In this case, once you start debugging the client application, you can attach to the server at which time the Carbide debuggerwould try and get the load address of the dependent libraries of the server application.

The Carbide debugger team is working on improvements to on-device debugging in the next several releases. Our ultimate goal is plug-and-play. In other words, you connect your device, Carbide detects it and you can debug your projects on that device. We're not there yet, but we would like to make your on-device debugging life easier along the way to that goal.

We've identified many little things that bug people in our many debugging user interface elements such as the launch wizard pages, lauch configuration tabs, data views, etc. If you have anything you would want to add to our list, we want to get your suggestions. For example, is there a list or table that isn't sorted like you would like? Is there an option that's misnamed or in the wrong place? Are there options that are missing? Is your debugging work-flow hampered because the UI is not arranged in the most natural way for how you work? What is your pet-peeve about the way we present on-device debugging?

You can add comments to this entry or log them as enhancement requests to our bugzilla.

I really like debugging with TRK but everytime i leave TRK running on device, my phone battery is ehxasted in ~10-12 hours!
This could be the internal TRK power drain or simply the fact that when TRK stays in front, phone doens't enter power-saving mode(the screen is always lit). The former would be really difficult to isolate/fix and the later is rather easy to fix! Need to investigate how to enable power-save mode when running trk.

I want to start by stating that I am not part of the debugger team, so my experiences with on-device debugging are more from the point of view of a Carbide user. Recently, I had reason to do some on-device debugging. I decided to try using bluetooth to connect my release phone to the debugger. Since this was a release phone and not an RnD phone, I used Application TRK rather than System TRK. I understood I would be limited to debugging my own application, but that was fine for my purposes.

Reading the Carbide.c++ help on run-mode debugging, I found Application TRK in the plugin directory mentioned in the help (plugins\com.nokia.carbide.trk.support_<version>\trk) and installed it using Nokia PC suite. However, I had a difficult time getting my serial port over bluetooth up and working, so I'd like to give some tips on how I got it to work.

First, I had to install the general bluetooth drivers for my lenovo ThinkPad. I already had PC suite running, but I needed the machine's manufacturer driver package in order to have serial over bluetooth. Apparently, the microsoft drivers don't provide serial emulation over bluetooth, so I needed the full WIDCOMM package from the manufacturer.

The way that TRK currently works with bluetooth is that it has a setting labeled "port." However, this is not the COM port on the host machine, but rather an internal index to the serial over bluetooth service. Which index is assigned to which bluetooth service is not exactly visible, so you may have to try many different "port" settings on the TRK interface on the phone. I start with 1 and go up from there, but more on that later.

When I opened the bluetooth configuration dialog on the machine, I found a tab for local services and on it there was a bluetooth serial port service assigned to COM port 7.

Tip 1: I could never connect to this COM port, so I found that deleting the preassigned one and creating a new one seems to yield better results. My new one was assigned to COM port 9.

Tip 2: Since I had to try different "port" settings on the TRK interface on the phone, and each time I had to wait to see which one it tried to connect to, I found it was better to set all of the local bluetooth services except the serial service to "manual" rather than "automatic." This way, when I connected to the wrong service, it failed right away and I didn't have to look on my machine to see which service I had connected to and wait for the connection to timeout.

Tip 3: Once you connect to the serial port, don't test the viability of the connection using the debugger. The first time I tried to connect to the serial port, I could not debug and it was not clear why. I kept getting the message that the port was in use. In any case, using the debugger to drive the testing of the COM port means you have to actively do something. On the other hand, you can use HyperTerminal (Start/Programs/Accessories/Communications/HyperTerminal) to listen to the COM port for you. And when you try to connect from TRK, a successful connection will cause the TRK message to appear on the HyperTerminal screen.

Now, you are ready to debug. Just make sure that you disconnect HyperTeminal first, or you'll get a message that the COM port is in use. And this time, you can actually do something about it.