EmbeddedRelated.com
Forums

Problem debugging firmware generated by Processor Expert

Started by cwching.rm April 14, 2005
Hi all,

I am using the M68KIT912DP256 development kit from Freescale to
develop the firmware for MC9S12A64CPV microcontroller. I am using the
Processor Expert within Metrowerks Codewarrior for HCS12 to build an
initial startup project, with the target CPU of MC9S12DP256BCPV. As I
tried to debug my firmware using the Hi-wave debugger, I experienced
problem in setting breakpoints. I keep getting illegal breakpoint
message as I placed my breakpoint in my main function and tried to
reach the breakpoint. From the assembly window, I see that the
assembly codes displays BGND codes like below

00C6 BGND
00C7 BGND
00C8 BGND
00C9 BGND
00CA BGND

this occurs as I pressed F5 to reach my breakpoint.

I am using banked memory model for my project. I hope someone can
kindly enlighten me on this as I thought that the Processor Expert
should generate an initial project that runs and allows me the debug
properly.Thank you very much for your help.

Regards,
Chee Wee
Hi Chee.

If you can download/flash your application, proceed simply by stepping your
code from reset. Then see on which instruction/where the code get lost.

Apparently, your code is lost and breaks due to BGND instruction hit.
Therefore, no chance to reach any breakpoint.

Also remind that the MC9S12A64 resources mapping is not similar to
MC9S12DP256.

Please indicate if you apply mapping rules described in:
EB386/D
Rev. 3, 07/2002
HCS12 D-family Compatibility Considerations

Also please indicate which version of the debugger you have, and which
debugging (BDM, I guess) cable you use.

Regards,
Gilles
Hi Gilles,

Thanks for you reply. I created a new project by selecting New->HCS(12) Project wizard and selecting MC9S12DP256 as my target CPU, not MC9S12A64. So the project is targeted at the same processor as my eval board.

I am using Processor Expert v2.92 shipped with Codewarrior for HCS12 v3.1.I am using the USB HCS08/HCS12 Multilink Rev B for my BDM. The debugger used is the Hiwave debugger that comes with Codewarrior for HCS12 v3.1. I did not make any changes to the memory layout for the project as i just create a new project, setting the CPU characteristic like CPU to single chip mode and setting PLL clock to 25MHZ.

The point is the firmware can run properly when run out of flash, as I added codes for SCI communication to display data to Hyperterminal to PC later to determine whether it is coding problem.I can receive data from SCI once I run the firmware out of flash. But when I used the debugger to step through the program, I experience problem once I tried to step through the following codes

__asm jmp _Startup; /* Jump to C startup code */

in the default file CPU.c.

once i tried to step this statement the assembly window shows
0xC060 BGND

I hope that you can help me on this. Thank you very much.

Regards,
Chee Wee
Hi Chee Wee.

For sure, running from flash (I guess you mean, in stand alone, without BDM
cable), the BGND instruction will not halt the CPU.
However, when running the chip with a BDM cable like P&E Multilink, the
BGND instruction (Enter Background Debug Mode) is handled and the core stops.

BGND instruction is "00" hex. If the memory is filled with "00", if the
core PC is executing from this location, it will "see" a suite of BGND's.

So either your application is not correctly flashed, or there is really
something setting BGND's or a field of 0's in your code.

Question: Did you install the service pack to support the "HCS12 Multilink
Rev B" cable? It is a USB 2.0 cable, and this cable got released after the
Codewarrior for HCS12 v3.1.

It is required to support this new cable. You can get the service pack from
Metrowerks web site.

ftp://ftp.metrowerks.com/pub/updates/CWHC12/CW12_V3_1_ICD12_USB2_0_Sim_patch
.exe

However, if you can, you can send me directly your project, or a sample of
your project.
I could try to reproduce and sort the problem off list.


Regards,
Gilles
Hi Gilles,

Thank you for your reply. I just found out that it is due to the usage of PLL clock that is causing the debugger to function incorrectly and giving me BGND codes. For the Hiwave debugger,in the IDC-12 menu,I need to select Communication->Special Setup, and check the box marked 'Set CLKSW bit in BDM control register' for BDM to run in sync with the PLL clock.

I purchased the M68KIT912DP256 development kit from Freescale to develop the firmware for MC9S12A64CPV microcontroller. If I created a new project selecting Target CPU as MC9S12A64CPV with Processor Expert, I have problem running the firmware on the development kit. Is there any way I can tweak the project created by Processor Expert for MC9S12A64CPV such that it can work for the development kit? I hope you can give me some advice on this. Thank you very much.

Regards,
Chee Wee
Hi Chee Wee,

I propose you first to apply "Figure 7 Example 1 Layout" described in p.17
and p.18 in:
http://www.freescale.com/files/microcontrollers/doc/eng_bulletin/EB386.pdf

Note that models for HCS12 "D" series apply also to "A" series.

So in your code (startup) move your chip resources like this:

initrg = 0x00;
initrm = 0x39;
initee = 0x09;

In your linker project PRM file, change the RAM settings to match this
model. Like:

RAM = READ_WRITE 0x1000 TO 0x2FFF;

The flash should be Ok, as A64 is fully inside DP256 size/range/map.

You also need to change some debugger ini files keys:

In your project, in Debugger Project File folder, "P&E_ICD.ini" file:

Set the DP256 derivative instead of A64 (MCUID=0x3CC):

[ICD12]
MCUID=0x3C6

In your Debugger Project File called "Simulator.ini" file:

[Simulator HC12]
FCS=MC9S12DP256B


Note that .ini files and .prm files are not setup by ProcessorExpert. So
What we simply do here is route the HI-WAVE debugger to another derivative.

I hope this help.

Regards,
Gilles
Hello
In fact I'm not sure, if the A64 and DP256 have identical register
structure. So just setting the mapping of memory may not be enough.

The PE generates setting of the initrg, initrm and initee. These
registers are write once in normal mode.
In order not to loose custom modification I would recommend to have a
look at the "User Initialization" property in the Build options of the
CPU bean. Click on the "User code before PE initialization". In the
opened window put the following code and press OK:
initrm = 0x01;
initee = 0x09;
Repeat the same procedure with "User code after PE initialization".
Next time you generate code your code will be included on the beggining
and the end of _EntryPoint function.

This will ensure that the RAM on DP256 will be mapped from 0x1000 to 0x4000.

In the properties of the cpu bean set "Internal RAM mapping" to $1000.
This will also modifies the Build options and consequently *.prm file
(it is also generated by PE).

>
> So in your code (startup) move your chip resources like this:
>
> initrg = 0x00;
> initrm = 0x39;
> initee = 0x09;
>
> In your linker project PRM file, change the RAM settings to match this
> model. Like:
>
> RAM = READ_WRITE 0x1000 TO 0x2FFF;
>

In fact I'm not sure about this. The A64 has 4kB of RAM, but this
setting is for 8kB RAM.

Personally, I would recommend to do the development directly with DP256
cpu bean. To port the code to A64 is just matter of adding appropriate
cpu bean and selecting it as a target.
Of course few adjustments would be required. E.g. the PE may complain
about different names of peripherals. You can even rename the
peripherals of DP256 to match the names of A64.
Regards
Petr
Hi Petr,

Thank you very much for your advuce.Sorry for the late reply. :).

Regards,

Chee Wee