topic BDM / Debug impact going from 144pins to 100? Some debug signals missing. in ColdFire/68K Microcontrollers and Processors

BDM / Debug impact going from 144pins to 100? Some debug signals missing.

circuitMaker — Sat, 07 May 2011 04:50:31 GMT

Hello and thanks in advance.

I've been using the MCF52258 144pin CPU and the P&E microcomputer BDM pod with the CodeWarrior IDE with great success. Now I'd like to migrate to a smaller part and the MCF52254 would work nicely. I noticed that some of the pins that were dropped for the 100 pin part are the DDATA0-3 and PST0-3. Will the debugger still work? Will I be able to see variables and breakpoint?

Thanks again

Re: BDM / Debug impact going from 144pins to 100? Some debug signals missing.

TomE — Sun, 08 May 2011 21:49:51 GMT

Does the following help:

http://www.pemicro.com/faqs/faq_view.cfm?id=90

That says to connect the "ALLPST" pin to "all the PST pins on the debugger". That matches the following description in the MCF52258 Reference Manual:

Table 33-2. Debug Module Signals (continued)

ALLPST is a logical AND of the four PST signals and is provided on all packages. PST[3:0] and
DDATA[3:0] are not available on the low cost (less than 100 pin) packages. When asserted, reflects that the core is halted.

Also read section "1.5.2 Integrated Debug Module" in the Reference Manual.

I'd suggest checking the FAQs and Forums at PE Micro for this. Searching for "ALLPST" finds:

http://www.pemicro.com/forums/index.php?showtopic=2801

http://www.pemicro.com/forums/lofiversion/index.php?t3157.html

http://www.pemicro.com/forums/lofiversion/index.php?t3222.html

http://www.pemicro.com/forums/index.php?showtopic=3222&mode=linearplus

From what (little) I know about the debug interface, the PST and Data pins are only needed for:

36.4.4 Real-Time Trace Support
Real-time trace, which defines the dynamic execution path and is also known as instruction trace, is a
fundamental debug function. The ColdFire solution is to include a parallel output port providing encoded
processor status and data to an external development system. This port is partitioned into two 4-bit nibbles:
one nibble allows the processor to transmit processor status, (PST), and the other allows operand data to
be displayed (debug data, DDATA).

Separate to this the debug interface supports "Background Debug mode" and "Real Time Debug Support".

So you don't get "Real Time Trace" on the 100 pin, but I've never seen a debugger that supports that anyway.

Tom

Re: BDM / Debug impact going from 144pins to 100? Some debug signals missing.

scifi — Mon, 09 May 2011 00:50:12 GMT

I started with the 80-pin parts from the MCF5223x family. The BDM pod only needs the signals BKPT, DSI, DSO, DSCLK, ALLPST. Tested this with P&E Parallel (DIY) and USB Multilink adapters. When I started using the 144-pin MCF5225x parts, I used the same signals.

Re: BDM / Debug impact going from 144pins to 100? Some debug signals missing.

ChrisJohns — Mon, 09 May 2011 06:18:43 GMT

> From what (little) I know about the debug interface, the PST and Data pins are only needed for:
>
> 36.4.4 Real-Time Trace Support
> Real-time trace, which defines the dynamic execution path and is also known as instruction trace, is a
> fundamental debug function. The ColdFire solution is to include a parallel output port providing encoded
> processor status and data to an external development system. This port is partitioned into two 4-bit nibbles:
> one nibble allows the processor to transmit processor status, (PST), and the other allows operand data to
> be displayed (debug data, DDATA).
>
> Separate to this the debug interface supports "Background Debug mode" and "Real Time Debug Support".
>
> So you don't get "Real Time Trace" on the 100 pin, but I've never seen a debugger that supports that anyway.

All debuggers need the pins to support all families of Coldfires. The P&E pod makes use of them. You can run the BDM protocol on a V2 core with I think debug B hardware using just software and this is what the GDB BDM package can do. This was needed for the older 5203e (?) type devices that shared the PST? pins with I/O. How-ever bugs in the V3 debug hardware meant this feature did not work as Greg found out getting the uCLinix kernel to work on it. The read once HALT bit in the CSR register failed to get set sometimes so you never saw the processor had halted. You need all PST signals to be high to indicate the processor has halted. To save pins this has been moved into the device and single pin provided that you wire to all PST pins on the BSP connector.

Re: BDM / Debug impact going from 144pins to 100? Some debug signals missing.

circuitMaker — Wed, 18 May 2011 00:51:16 GMT

Thank you all for the answers!!