68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC

Many people have 9S12DP256 based EVBs, and they use d-bug12 for
debugging. This is especially popular with students and hobbiests, and
they normally don't use d-bug12 in the pod mode because they may only
have one board and they want to avoid the cost of a new one. So they
use a terminal window to do their debugging with one EVB board
connected to the PC serial port, whether it's done with AsmIDE,
EmbeddedGNU, Hyperterm, or another program.

My new Pluto debugger is a modern visual debugger and I can probably
make it work on 9S12DP256 based EVBs if I just modify the Serial
Monitor to run from RAM, instead of running from flash. Pluto can
automatically download the Serial Monitor to RAM along with a user
program. The DP256 has 12K of RAM and most people wouldn't complain
about using 2K of that for the Serial Monitor, and that would let them
use my visual debugger with only a serial cable between their board
and the computer.

Of course, people can replace d-bug12 with the Serial Monitor in
existing EVBs by re-burning the flash, but that's a bit risky for
students. So I devised a way to store the serial monitor in RAM
(without clobbering d-bug12), and still allow all debugging
functionality. I think I can even support writing user programs to an
unused flash bank.

Here are my ideas - please tell me if this makes sense, and if you
have any other ideas along these lines:

Serial Monitor changes
1) download it using d-bug12, and run from RAM. D-bug12 stays in place.
2) restrict flash programming code to avoid d-bug12 flash blocks (I
think we can find at least one free 16K block of flash; I think
d-bug12 is around 50K bytes?)
3) Upon writing a user program to flash, I also have to write a
startup thunk in EEPROM - see below. This lets a user program run
automatically upon power-up.

Reset procedure from Pluto:
1) Test to see if the Serial Monitor is responding at 115K, and if so,
skip to step 4
2) Drop baud to 9600 and try to talk to d-bug12.
3) If d-bug12 responds, bump baud up to the highest d-bug12 speed and
download the Serial Monitor to ram
4) Start the Serial Montior, which will then grab the serial port
vector, and the reset vector from the pseudo vector table in RAM

EEPROM Thunk
1) this is used to allow a user program to execute upon a cold start
2) this startup thunk routine will be stored in EEPROM
3) user has to change the DIP switch to select "jump to eeprom" mode
if he wants his pgm to start upon cold start or reset. Otherwise,
d-bug12 will start as usual.
4) upon reset, this sets PLL and stack, and maps the user flash bank
into the window, and jumps to user program in the flash window

Please weigh in with your thoughts!

My linux port will be delayed until later this year. I'll start work
on it after the release of Mono v1.2. This has taken longer than
expected because Novell has put a strong set of demands on it, but the
end result should be great.

gcc support is also on my plate, but I haven't got a timeline in mind
yet. Dwarf2 parsing is a bit demanding...

Eric
http://www.EricEngler.com/Pluto.aspx

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Dear Eric,

I have been using ICC12 and testing my C-programs in RAM mode on my
Minidragon+ board. What changes will I have to make in order to make use of
the Pluto debugger?
On 8/9/06, Eric Engler wrote:
>
> Many people have 9S12DP256 based EVBs, and they use d-bug12 for
> debugging. This is especially popular with students and hobbiests, and
> they normally don't use d-bug12 in the pod mode because they may only
> have one board and they want to avoid the cost of a new one. So they
> use a terminal window to do their debugging with one EVB board
> connected to the PC serial port, whether it's done with AsmIDE,
> EmbeddedGNU, Hyperterm, or another program.
>
> My new Pluto debugger is a modern visual debugger and I can probably
> make it work on 9S12DP256 based EVBs if I just modify the Serial
> Monitor to run from RAM, instead of running from flash. Pluto can
> automatically download the Serial Monitor to RAM along with a user
> program. The DP256 has 12K of RAM and most people wouldn't complain
> about using 2K of that for the Serial Monitor, and that would let them
> use my visual debugger with only a serial cable between their board
> and the computer.
>
> Of course, people can replace d-bug12 with the Serial Monitor in
> existing EVBs by re-burning the flash, but that's a bit risky for
> students. So I devised a way to store the serial monitor in RAM
> (without clobbering d-bug12), and still allow all debugging
> functionality. I think I can even support writing user programs to an
> unused flash bank.
>
> Here are my ideas - please tell me if this makes sense, and if you
> have any other ideas along these lines:
>
> Serial Monitor changes
> 1) download it using d-bug12, and run from RAM. D-bug12 stays in place.
> 2) restrict flash programming code to avoid d-bug12 flash blocks (I
> think we can find at least one free 16K block of flash; I think
> d-bug12 is around 50K bytes?)
> 3) Upon writing a user program to flash, I also have to write a
> startup thunk in EEPROM - see below. This lets a user program run
> automatically upon power-up.
>
> Reset procedure from Pluto:
> 1) Test to see if the Serial Monitor is responding at 115K, and if so,
> skip to step 4
> 2) Drop baud to 9600 and try to talk to d-bug12.
> 3) If d-bug12 responds, bump baud up to the highest d-bug12 speed and
> download the Serial Monitor to ram
> 4) Start the Serial Montior, which will then grab the serial port
> vector, and the reset vector from the pseudo vector table in RAM
>
> EEPROM Thunk
> 1) this is used to allow a user program to execute upon a cold start
> 2) this startup thunk routine will be stored in EEPROM
> 3) user has to change the DIP switch to select "jump to eeprom" mode
> if he wants his pgm to start upon cold start or reset. Otherwise,
> d-bug12 will start as usual.
> 4) upon reset, this sets PLL and stack, and maps the user flash bank
> into the window, and jumps to user program in the flash window
>
> Please weigh in with your thoughts!
>
> My linux port will be delayed until later this year. I'll start work
> on it after the release of Mono v1.2. This has taken longer than
> expected because Novell has put a strong set of demands on it, but the
> end result should be great.
>
> gcc support is also on my plate, but I haven't got a timeline in mind
> yet. Dwarf2 parsing is a bit demanding...
>
> Eric
> http://www.EricEngler.com/Pluto.aspx
>



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, "Mohammed El Korek"
wrote:

> I have been using ICC12 and testing my C-programs in RAM mode on my
> Minidragon+ board. What changes will I have to make in order to make
use of
> the Pluto debugger?

None, but it will only support assembler at first (using the open
source as12 assembler). I will work on adding gcc C language support
later.

I don't have any plans for ICC12 C language support, but I like
Imagecraft and I may look into it more if there's a demand for it.
They also have an Arm compiler now and my future direction will be
along those lines (Luminary Micro LM3S8xx and Philips LPC21xx).

Eric



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Unless you have written an ELF/DWARF reader, I can guarantee you that it
will take you many days/weeks/months to support that for GCC.

OTOH, anyone can probably write an ICC debug format reader in half a day :-)

At 10:39 PM 8/9/2006, Eric Engler wrote:

>None, but it will only support assembler at first (using the open
>source as12 assembler). I will work on adding gcc C language support
>later.
>
>I don't have any plans for ICC12 C language support, but I like
>Imagecraft and I may look into it more if there's a demand for it.
>They also have an Arm compiler now and my future direction will be
>along those lines (Luminary Micro LM3S8xx and Philips LPC21xx).
>
>Eric

// richard (This email is for mailing lists. To reach me directly, please
use richard at imagecraft.com)



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, Richard wrote:
>
> Unless you have written an ELF/DWARF reader, I can guarantee you
that it
> will take you many days/weeks/months to support that for GCC.

Yeah, it looks hard but I like the flexibility of the format.

> OTOH, anyone can probably write an ICC debug format reader in half a
day :-)

The hard part for me is to know about local vars, possibly being
stacked up inside recursive calls, and also register vars that might
be stored in a CPU register. A watch on a local variable may require
me to walk the stack to find the right occurance.

I don't want to even consider debugging of optimized code. The DWARF2
format has a lot of optional info that can help track optimized code,
but the trouble isn't worth the small benefit - especially when I can
just ask users to disable optimization if they have problems debugging
optimized code.

The last I heard you were looking for a low cost Arm debugger to
bundle with your Arm compiler. Did you find one?

I'm interested in 3 targets right now, and I've done some
proof-of-concept on all 3: hc12, msp430, and Arm. My C debugger will
have to work with all of these. Dwarf is the only thing holding me
back, and it's mostly a question of finding enough free time.

Eric



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, "Eric Engler" wrote:
> I don't want to even consider debugging of optimized code. The DWARF2
> format has a lot of optional info that can help track optimized code,
> but the trouble isn't worth the small benefit - especially when I can
> just ask users to disable optimization if they have problems debugging
> optimized code.

I wouldn't call it a small benefit. It is either can or cannot. The
reason I have for debugging optimized code is because I cannot fit the
unoptimized into the target. Therefore, either I can or cannot debug
my project depending on that one feature you thought was not worth the
trouble :-O



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

On Tue, Aug 15, 2006 at 02:20:14PM +0000, Jefferson Smith wrote:
> The reason I have for debugging optimized code is because I cannot fit the
> unoptimized into the target.

If you have a little free space, can you build selected files unoptimized
and with debugging info and the rest optimized and without debug?
(...if the IDE you're using supports that.) It can be tricky to debug
with only partial debug info, but it's better than no debug info.

Stephen

--
Stephen Trier
Technical Development Lab
Cleveland FES Center
s...@po.cwru.edu



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, "Stephen Trier" wrote:
>
> On Tue, Aug 15, 2006 at 02:20:14PM +0000, Jefferson Smith wrote:
> > The reason I have for debugging optimized code is because I
> > cannot fit the
> > unoptimized into the target.
>
> If you have a little free space, can you build selected files
> unoptimized
> and with debugging info and the rest optimized and without debug?
> (...if the IDE you're using supports that.) It can be tricky to debug
> with only partial debug info, but it's better than no debug info.
>
> Stephen

I use gdb and D-Bug12 BDM. That is able to debug optimized code. Of
course it's not always an issue. I just like to keep possiblilities open.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )