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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

993 Views
circuitMaker
Contributor I

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

Labels (1)
0 Kudos
4 Replies

462 Views
scifi
Senior Contributor I

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.

0 Kudos

462 Views
TomE
Specialist II

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

 

0 Kudos

462 Views
ChrisJohns
Contributor I

 

> 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.

0 Kudos

462 Views
circuitMaker
Contributor I

Thank you all for the answers!!

0 Kudos