gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Debugging with GDB/Insight with masscat's stub and DSerial2

#128090 - kansado - Tue May 08, 2007 3:18 pm

Since debugging with wifi was quite slow, I bought DSerial2 and tried to use it with masscat's GDB stub, expecting to get a lower packet latency.

I've developed a replacement for serial_comms to work with DSerial2 instead of masscat's proposed circuits (mainly because I don't know too much about electronics.)

When the debug test program linked against my serial_comms reaches debugHalt(), Insight and the stub interchange debug packets for a while, after which they get stuck in nonsense dialogues.

This is the cable schematic:

Code:
PC side (DB-25)         DSerial2 side (IO2)

  2  TD  .______  _______. RS-232 TX
                \/
  3  RD  .______/\_______. RS-232 RX

  4  RTS .__
  5  CTS .__|
  6  DSR .__|____________. Vdd
  8  DCD .__|
 20  DTR .__|


Probably I've misunsderstood something (or perhaps a lot of things) in the RS-232 specification, but this way I was able to send and receive data correctly with the DSerial2's firmware test program.

I've updated masscat's code with the template for ARM7 in devKitPro r20.

This is the debug_serial.c I've made:

Code:
#include <stdlib.h>
#include <stdint.h>

#include "debug_stub.h"

#include "dserial.h"

#define BUFFER_SIZE 2048

char rxBuffer[BUFFER_SIZE];
int head, byteCount;

static void receiveHandler(char * data, unsigned int size)
{
   unsigned int i, pos = head + byteCount;
   for (i = 0; i < size; i ++) {
      rxBuffer[pos % BUFFER_SIZE] = data[i];
      pos ++;
   }
   byteCount += size;
}

static int
init_fn( void *data __attribute__((unused))) {

   while(!dseInit());
   dseBoot();
   swiDelay(9999); /* Wait for the FW to boot */
   dseSetModes(ENABLE_RS232);
   dseUartSetBaudrate(9600);
   head = 0;
   byteCount = 0;
   dseUartSetReceiveHandler(receiveHandler);

  return 1;
}

static void
writeByte_fn( uint8_t byte) {
  dseUartSendBuffer(&byte, 1, true);
}

static void
writeData_fn( uint8_t *buffer, uint32_t count) {
  dseUartSendBuffer(buffer, count, true);
}

static int
readByte_fn( uint8_t *read_byte) {
  if (byteCount > 0) {
    *read_byte = rxBuffer[head];
   head ++;
   head %= BUFFER_SIZE;
   byteCount --;
   return 1;
  } else {
    return 0;
  }
}

static void
poll_fn( void) {
}

static uint32_t
irqs_fn( void) {
  return IRQ_CARD_LINE;
}

/** The instance of the comms function interface */
struct comms_fn_iface_debug serialCommsIf_debug = {
  .init_fn = init_fn,
  .readByte_fn = readByte_fn,
  .writeByte_fn = writeByte_fn,
  .writeData_fn = writeData_fn,
  .poll_fn = poll_fn,
  .get_IRQs = irqs_fn
};


I hope I've not forgotten anything.

By the way, I've not noticed a lower packet latency compared to wifi, but I won't trust this result until I achieve a complete debug session. Perhaps the botteneck isn't in the wifi element as I thought.

Are people out there interested in debugging with DSerial2? Anybody knows what I'm doing wrong? Any help would be appreciated.

#128108 - masscat - Tue May 08, 2007 5:50 pm

Good to see you using and extending the stub.

I found it easier to test the stub using the command line version of GDB rather than Insight as you have more control over the commands the debugger is sending out. For example Insight can issue lots of memory reads commands.

I have not worked on the stub for a while and cannot remember what state I left it in. If I can get it running under the Desmume emulator I may try to complete it (debugging the debugger stub on the hardware is not much fun).

Since you are getting some communication between the NDS and PC I would think the hardware side is fine.
As you get rubbish comms after some correct messages you may be overwriting the read buffer (or a write buffer inside the DSerial2 code?) before you have used it.

You can enable a debug log function which you can send the output to the screen. Have a look in monitor/main.c for an example function (logFn_debug()). If you have a look through the stub source code you will see lots of LOG calls, which if DO_LOGGING is defined, gets directed to logFn_debug(). Enabling these or adding some to your comms code may help you find the problem.

#130794 - natrium42 - Fri Jun 08, 2007 1:09 am

Hardware should be connected as follows:

Pin 2 at DB9 ----- RS232_TX at IO2
Pin 3 at DB9 ----- RS232_RX at IO2
Pin 5 at DB9 ----- GND at IO2 or IO1

Most modern computers use DB9 for serial port and DB25 for parallel port. Make sure you are using the right port :)

The problem in your code is that dseUartSendBuffer() is currently limited to sending up to MAX_DATA_SIZE (32). So you need to break up the message into chunks of 32 bytes.

Dovoto actually started doing the DSerial stub for masscat's code too before he found your post. Here is his port with minor bug fixes: http://www.natrium42.com/temp/dserial-debug.zip

You can connect to it with gdb using commands:
(gdb) set remotebaud 9600
(gdb) target remote COM1

Upping the baudrate to 115200 shouldn't be a problem; or higher if your COM port supports it.
_________________
www.natrium42.com

#130821 - dovoto - Fri Jun 08, 2007 2:26 pm

Note that the zip natrium provided contains masscats code slightly restructured and not entirely without issues do to this restructuring. Specifically the communications stub for masscat's original spi/uart bridge serial port is disabled (due to me not including the spi/uart source in that zip).

Masscat, if you have more updates it would be great if you could take a look at the zip. The structure is a bit more devkitpro standardized (and results in a little bit less hassel while using in libnds projects with template makefiles) so it might be worth continuing.
_________________
www.drunkencoders.com

#130849 - masscat - Fri Jun 08, 2007 6:37 pm

There is not much of a problem not including my spi/uart bridge code as I think that there is about one of them in existence and that is built on some prototype board and sat on my shelf (did anybody else build one?). I will have to think about getting a DSerial, it is a little bit more compact and probably requires less wiggling to get a good connection.

I have had a look at the zip file. Looks like the code for interfacing to DSerial fitted well within the debug stub comms functions interface. Were there any problems?
The new layout seems fine too.

This recent talk has re awoken my interest in the stub so I may do some more work on it. One feature I did want to implement was to ability to break a running target.

#130857 - dovoto - Fri Jun 08, 2007 7:14 pm

I would love to see work continue on the project. A decent debugger would be a great adition to the homebrew scene.
_________________
www.drunkencoders.com

#130888 - josath - Sat Jun 09, 2007 12:32 am

as soon as i hear there's a decent working debugger over serial, i'm using that as an excuse to buy a dserial :P

#130904 - wintermute - Sat Jun 09, 2007 3:09 am

This also seems to work quite well with the current Insight build provided by devkitPro with the minor caveat that you'll need to set up the initial connection using the console window rather than the target settings dialog. I have a build of 6.6 which will work as expected and I'll release that after a little more testing.

Masscat, if you're interested I'd like to offer the debug stub as a devkitPro module downloadable via the installer as per libnds, dswifi etc. Obviously I'd prefer the standardized format Dovoto used to build your code so that it fits in with the rest of the libraries. I can add an install target & give you CVS access if you're up for maintaining the lib as part of devkitPro.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#130943 - masscat - Sat Jun 09, 2007 1:53 pm

Moved stub talk over to the A Debugger Reborn thread.