Page 1 of 1

Degugging and single-stepping in VSIDE

Posted: Mon 2012-01-09 12:02
by Panu

Let's discuss a little about single-stepping and debugging in VSIDE. We've done some improvements in the VSIDE and the newer VSIDE versions seems to be more stable than previous ones.

Debugging with a ROM monitor and UART connection is always tricky, and much more prone to connection errors than for example JTAG debugging. So, we know that we need to be careful not do do anything which would cause the UART connection to break. But what exactly must we do and what must we avoid? Please share your experiences and comments. I'll write what I know, but please note that I am not the original programmer of the ROM monitor or the emulator.

I will try to maintain a list of tricks, pitfalls and issues here, together with Lasse and Pasi.

Serial Port
Target Speed: If the UART speed is other than what the emulator expects, the emulator connection breaks. In VS1053 it can happen when a call to InitHardware is executed somehow. It will drop the serial port speed to 9600. If you have problem with debugging in VS1053, try setting the Target Speed to 9600 in Solution Options -> Debugging. If it helps, you can set the UART speed back high after the call to InitHardware, but note that single-stepping at the call to InitHardware will then break the connection.

Binary Data: The emulator has a powerful file input/output library, which allows you to read and write files in the PC by the VS10xx device. But binary data will confuse the ROM monitor interrupt. If you need to read/write files which contain binary data, you need to surround the read/write operations with "Disable()" and "Enable()" so that the interrupts are disabled for the duration of the transfer. (See all our prommer examples for an example).

File Names
Some tools in some environments have problems with file names that contain spaces. For example you may be unable to set a breakpoint in a file which has a space in the path. In that case, try if it works if your solution is in a folder which doesn't have spaces, such as "c:\solutions\mysolution1".

Also if you want to try to compile code using the vcc compiler instead of the lcc (default), it helps to have the vside also in a path without spaces, such as "c:\vside".

Inspecting memory
If a location in memory is not declared to be in use in the memory map, it will not be read back from the IC by the monitor, and it will show as zero. To overcome this, you can set the memory map file for the debugger to be other than that of the linker, so you can allow reading of other memory locations, such as stack, stream buffer etc.

Tracking values of variables
The compiler tries to keep the values of local variables in registers as much as possible. Unfortunately this hides the variables' values from the debugger. Debuggers in PC software world often say "Variable inaccessible here due to optimization". This is the same thing. To track values of variables in an algorithm you're debugging, you can move them outside the function so they will be globals, for the duration of debugging. Global variables are not placed in registers, so the code will be slower than usual, but you'll be able to debug the values.

Please report your own findings!

Debugger/Emulator memory description

Posted: Sat 2012-06-30 9:33
by Panu
Today I was busily making an interrupt handler for VS1053. But the interrupt didn't seem to be doing anything, except for slowing the core just a little bit. The problem was that in the Project Properties (Project Options) I had different memory description files for the Linker and the Debugger. I noticed this when I opened the debugger console for debugging the program, and it said, among others:

Code: Select all

Section 35: InitFileSystem  page:0 start:1410 size:116 relocs:27
Section 36: int1        page:0 start:38 size:1 relocs:1 fixed
Write to unconnected memory! Skipping this section..
Section 37: int2        page:0 start:39 size:1 relocs:1 fixed
Write to unconnected memory! Skipping this section..
Section 38: my_timer_interrupt_handler  page:0 start:1526 size:21 relocs:1
Section 39: ReadDiskSector  page:0 start:1547 size:36 relocs:9
which means that the interrupt vector was not set by loading the code via the UART. So the core was using the default null interrupt handler, which doesn't do anything but allows the code to run. I had added the interrupt vector address to the memory description of my project, but not into the memory description of the debugger...

After setting the same memory description file for Linker and Debugger, the interrupt started working fine.