Standardised Debug IF

New system HW independent debug module:
– would be same on all HW iyonix, a8, a9 etc
– small amount of physical memory would be reserved eg 64k or some small % and not initialised over reset
– header plus circular buffer
– new module with various swi’s
– all swi’s would be flags and register preserving
– init swi r0 contains your app number developer allocated or 16 user alloc
– swi’s to write to buffer each register / flags
– swi’s to write data pointed to by reg [one for 4 bytes, 8, 16, 64, 128 bytes]
– swi to write token numbers 0 to 15 – added to init alloc number (4bytes written) or what ever is left in swi block
– swi to log accurate time eg us/ns
– on boot contents written to new log
– simple app for inspecting contents / enabling app specific filters

The DebugLog module that I have written(/evolved?) over the years, and which I mentioned to you at the RISC OS South West Show does much of the above, and I know I said I would send you a copy. I’m aware it’s been a while, but having returned to it I decided it was best to tidy it up and release it as open source. It is happening, and I’ve already done its companion ProfileMod which gather profiling information using the XScale’s CCNT (CPU cycle counter) register. These could perhaps, at least, serve as a starting point for what you want.

In the mid/late 90s I wrote another module which dumps the application space to disk when the two ALT keys are pressed; useful if your Wimp application throws up a fatal error box. Bear with me; in the absence of a (good) low-level debugger, I am trying to make my ad hoc solutions available for the benefit of others…

Hi Adrian, thanks for the update those all sound like excellent tools – will there be possibility of them working on the newer machines I’m not sure how much more life my 2nd and 3rd Iyonix’s have got left in them. The second one is starting to show signs of age. My 1st one is a pile of spares the main board has failed.

Have you had a look at my Reporter ? It may not do all that you want, but it does enable debugging of register values and strings from assembler. And many other things! Plus it works on all known machines. Happy to discuss via PM if you want.

DebugLog works on all machines, theoretically at least. I’ve used it on everything from RiscPC through to i.MX6, but it is the messiest and most hacked code I’ve ever written, having been adapted for this and that purpose/machine over the years! Hence the need for a bit of a spring clean. As a point of interest, before discovering that the NVidia graphics memory is preserved over reset, I built a small podule that just contained a static RAM chip and thus guaranteed preservation of log data. I used that on the RiscPC and later the IYONIX pc; that’s another option if you have electronics skills. I like the suggestion of having the HAL reserve a small buffer at a known physical address, provided that its contents won’t become (too) corrupted during the absence of DRAM refresh during refresh, and that the bootloaders used on later SoCs don’t make it infeasible/impossible.

ProfileMod may be trivially adapted for newer ARM targets, I’m sure, and the CoreDump module has been used from A3000 (RISC OS 3.11) onwards and is portable.

Hi Martin, I was aware of Reporter but wasn’t aware of the assembler macros: I’ve had a quick go and it now won’t build:

Reporter 2.67a (22 Aug 2012) List Sat 11th Apr 2015 00:41

00:41:09.75 * ReportClear * from Menu
00:41:18.03 TaskClose &272038EC
Basic Stack

• Basic Error ** ERR=29 No such function/procedure ERL=60
  Basic Stack
  60 PROCVars
  LOCAL ERROR was line 50 ErrStk 01287FD8
• Basic Error ** ERR=29 No such function/procedure ERL=1140 [in “<Imp$Dir>.NewVars”]
  Basic Stack
  60 PROCVars
  LOCAL ERROR was line 50 ErrStk 01287FD8
• Basic Error ** ERR=29 No such function/procedure ERL=1170 [in “<Imp$Dir>.NewVars”]
  Basic Stack
  60 PROCVars
  LOCAL ERROR was line 50 ErrStk 01287FD8
• Basic Error * ERR=29 No such function/procedure ERL=1200 [in “<Imp$Dir>.NewVars”]
  Basic Stack
  00:41:18.75 * Error **
  Error : &80000001
  Message: Internal error: abort on instruction fetch at &FFFC58AC

Reporter 2.67a (22 Aug 2012) Listed 20 lines

Hi Adrian, good news that the modules can be used on other platforms – I’m just doing a backup of my Iyonix and it has started doing disc error 13 18 23 – not seen those before seams ok after a reboot and discknight can find no issues? ShareFs is giving lots of strange errors.

On my day job LPC43xx cortex m4 board the dram is still refreshed at 12mhz by the physical crystal rather than the 96mhz of operation so ram contents are never lost even over a reset? Just don’t put it in deep sleep. :-)

I was aware of Reporter but wasn’t aware of the assembler macros: I’ve had a quick go and it now won’t build:

If you PM me at the Reporter address with some details I am sure that problem can be resolved!

Hi Martin I have PM’d you to your Webmaster address.

Thank’s martin for your help – I have got it working.

I wonder how difficult it would be to create a debug interface using SPI. I.e. just connect the SPI interface of one Raspberry Pi to the SPI interface of your target board (R-Pi, OMAP, iMX6, etc). That way you can get a nice high speed debug interface (compared to serial), and don’t have to worry about losing your log data over a reset. There’s also the possibility for interactive debugging (something I’ve occasionally thought about implementing for serial).

Of course one slight wrinkle with this plan is that the OMAP uses 1.8V IO while the Pi uses 3.3V. Good job I have multiple of each, right? ;-)

Of course one slight wrinkle with this plan is that the OMAP uses 1.8V IO while the Pi uses 3.3V

Perhaps someone with a hardware bent could make a debug interface board for the Pi which did level shifting with a variety of levels available (let’s not limit the debug facility to just OMAP and Pi compatability)
IIRC a number of the level shifters take the voltage level on each side by sensing the supply lines.

IIRC a number of the level shifters take the voltage level on each side by sensing the supply lines

Quick check, first one I tripped over :- TI do the PCA9306 and someone did a concept design

I wonder how difficult it would be to create a debug interface using SPI.

Wouldn’t that require VideoCore-side firmware changes in the debuggee? Either to handle SPI commands and control/co-operate with the ARM, or to hand over control of that hardware interface to the ARM?

The SPI interface is already under ARM control. Unless you’re thinking of another one to the one that’s listed in the public datasheet!

IIRC it is a PCA9301 we use to do the level shifting for I2C on our PandaBoard and IGEPv5. We don’t use a level shifter on the Pi because we run everything at 3v3 on the it.
If you don’t mind using flying leads to and from a board with the level shifters on them, I suspect there is a board available.
Edit.
Transistor? based:http://www.ebay.co.uk/itm/181275880556
Chip based:http://www.ebay.co.uk/itm/151476141769