MCF5213 and BDM

[Dietrich]

This message contains an entire topic ported from the WildRice - Coldfire forum.  Freescale has received the approval from the WildRice administrator on seeding the Freescale forum with messages.  The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value as you search for answers to your questions.  Freescale assumes no responsibility whatsoever with respect to Posted Material.  For additional information, please see the Terms of Use - Message Boards and Community Forums.  Thank You and Enjoy the Forum!

Feb 18, 2006, 4:41 PM

Post #1 of 4 (27 views)
Copy Shortcut
 [ColdFire] MCF5213 and BDM  Can't Post 

--------------------------------------------------------------------------------
 
This feels like a dumb question, but here goes anyway:

I'm working on a design with the MCF5213, having previous experience
with the 5307 and 5407.

The 5213 documentation explicitly says that pin 26 of the BDM connector
is to be hooked to the TA signal. The problem is that (as far as I can
tell) there *IS* no TA signal on the 5213, since there is no external
bus. What are we supposed to do with pin 26? Open? Pulled up?

For awhile we were looking at using a 5212 instead. The BDM situation
is even more confusing there since a number of the normal BDM signals
are not present on the processor. Fortunately for me, that's no longer
an issue on this project.

The documentation for the "EzPort" also seems a little bit sparse. Is
there a standard connector? If I pin out an EzPort connector, I see
four EzP signals, and ground, but what else should be there? RSTI?

This all makes me think I may be missing some important piece of
documentation for this stuff. If someone can point me this information,
I would be grateful.
--
Jonathan Griffitts
AnyWare Engineering Boulder, CO, USA
303 442-0556
--------------------------------------------------------------------

Feb 19, 2006, 2:22 PM

Post #2 of 4 (27 views)
Copy Shortcut
 Re: [ColdFire] MCF5213 and BDM [In reply to]  Can't Post 

--------------------------------------------------------------------------------
 
Hi Jonathan,

I recently did a PCB design that utilized the Mod5213 microcontroller module from NetBurner, which is based on the MCF5213. Needing a BDM solution, I purchased a USB BDM interface from P&E Microcomputer Systems. Like you, I was a bit unsure about how to hook it up, as several of the signals that are present in the standard 26-pin Berg connector used by BDM interfaces are absent from the 5213, at least in some packages.

It turns out that only a few of the signals are absolutely necessary for a working BDM solution. While I can't claim to have penetrated all the details of BDM, this is my take on the situation:
-The DSCLK, DSI and DSO signals are absolutely vital.
- The PST0 ... PST3 signals encode the core status. However, on some 5213 packages there aren't sufficient pins to bring out all these signals, and instead a signal ALLPST (logical AND of PST0 ... PST3) is provided. This at least allows a debugger to know whether the core is running or halted, which is all that's necessary for basic functionality.
- The BKPT signal is perhaps not absolutely necessary, but it's hard to see how any worthwhile debugging solution could do without it (it allows the core to be halted manually, typically as a result of the user clicking the "stop" or "halt" button in his debugger).
- Similarly, the RESET signal may not be absolutely necessary, but of course it would be very awkward if the debugger was unaware of a target reset.
- The DDATA signals provide additional information that can be used by a debugger to implement enhanced functionality, but they aren't essential. For example, availablity of all 4 PST and all 4 DDATA signals allows a real-time trace function to be implemented.
- The TEA (pin 26 in the Berg connector) signal is only necessary if you need to monitor external bus activity through your debugger.
- Not quite sure what the PSTCLK signal does, but I don't think it's essential for basic BDM functionality.

For what it's worth, here is how I wired my connection between the Mod5213 and the P&E interface's Berg connector:

5213 P&E
---- ---
BKPT BKPT (pin 2)
DSCLK DSCLK (4)
RSTI RESET (7)
DSI DSI (8)
DSO DSO (10)
ALLPST PST0 (15), PST1 (14), PST2 (13), PST3 (12)
PSTCLK CLK (24)

Plus, of course, GND and Vcc. Everything else I left open.

This works quite well with the P&E interface and P&E's debugger. I haven't tried it with any other debugging software.

Regarding the EZPort, I haven't delved into it. In my case, a Flash programming tool was supplied as part of the P&E package, and it works just fine using the same interconnect that also serves for BDM. For field updates, I have implemented my own software functions which rely on asynchronous serial communication (to receive new data from outside) and the functionality supplied by the CFM module (chapter 15 in the manual) for erasing and programming the Flash. I'm not sure in what situations you'd prefer to use the EZPort.

HTH,
Harald Hallen

*********** REPLY SEPARATOR ***********

On 2006-02-18 at 17:41 Jonathan Griffitts wrote:

>This feels like a dumb question, but here goes anyway:
>
>I'm working on a design with the MCF5213, having previous experience
>with the 5307 and 5407.
>
>The 5213 documentation explicitly says that pin 26 of the BDM connector
>is to be hooked to the TA signal. The problem is that (as far as I can
>tell) there *IS* no TA signal on the 5213, since there is no external
>bus. What are we supposed to do with pin 26? Open? Pulled up?
>
>
>
>
>For awhile we were looking at using a 5212 instead. The BDM situation
>is even more confusing there since a number of the normal BDM signals
>are not present on the processor. Fortunately for me, that's no longer
>an issue on this project.
>
>The documentation for the "EzPort" also seems a little bit sparse. Is
>there a standard connector? If I pin out an EzPort connector, I see
>four EzP signals, and ground, but what else should be there? RSTI?
>
>This all makes me think I may be missing some important piece of
>documentation for this stuff. If someone can point me this information,
>I would be grateful.
>--
> Jonathan Griffitts
>AnyWare Engineering Boulder, CO, USA
>303 442-0556
>--------------------------------------------------------------------

Feb 20, 2006, 12:39 AM

Post #3 of 4 (26 views)
Copy Shortcut
 Re: [ColdFire] MCF5213 and BDM [In reply to]  Can't Post 

--------------------------------------------------------------------------------
 
As far as I understand it (and hopefully the more experianced folk will
correct me if I'm wrong), the explaination below is almost correct. The
signal on pin 26 should be TEA, not TA - i.e., Transaction Error Acknowledge
rather than Transaction Acknowledge, and is an input to the ColdFire, not an
output to be monitored. Bringing the pin low during a bus cycle cuts the
cycle off short and causes an exception. It can be used if the ColdFire is
stuck accessing non-existant addresses. It's not an essential signal, so if
you don't have it, don't worry.

mvh.,

David

----- Original Message -----
From: "Harald Hallen"
Sent: Sunday, February 19, 2006 11:22 PM
Subject: Re: [ColdFire] MCF5213 and BDM

> Hi Jonathan,
>
> I recently did a PCB design that utilized the Mod5213 microcontroller
module from NetBurner, which is based on the MCF5213. Needing a BDM
solution, I purchased a USB BDM interface from P&E Microcomputer Systems.
Like you, I was a bit unsure about how to hook it up, as several of the
signals that are present in the standard 26-pin Berg connector used by BDM
interfaces are absent from the 5213, at least in some packages.
>
> It turns out that only a few of the signals are absolutely necessary for a
working BDM solution. While I can't claim to have penetrated all the details
of BDM, this is my take on the situation:
> -The DSCLK, DSI and DSO signals are absolutely vital.
> - The PST0 ... PST3 signals encode the core status. However, on some 5213
packages there aren't sufficient pins to bring out all these signals, and
instead a signal ALLPST (logical AND of PST0 ... PST3) is provided. This at
least allows a debugger to know whether the core is running or halted, which
is all that's necessary for basic functionality.
> - The BKPT signal is perhaps not absolutely necessary, but it's hard to
see how any worthwhile debugging solution could do without it (it allows the
core to be halted manually, typically as a result of the user clicking the
"stop" or "halt" button in his debugger).
> - Similarly, the RESET signal may not be absolutely necessary, but of
course it would be very awkward if the debugger was unaware of a target
reset.
> - The DDATA signals provide additional information that can be used by a
debugger to implement enhanced functionality, but they aren't essential. For
example, availablity of all 4 PST and all 4 DDATA signals allows a real-time
trace function to be implemented.
> - The TEA (pin 26 in the Berg connector) signal is only necessary if you
need to monitor external bus activity through your debugger.
> - Not quite sure what the PSTCLK signal does, but I don't think it's
essential for basic BDM functionality.
>
> For what it's worth, here is how I wired my connection between the Mod5213
and the P&E interface's Berg connector:
>
> 5213 P&E
> ---- ---
> BKPT BKPT (pin 2)
> DSCLK DSCLK (4)
> RSTI RESET (7)
> DSI DSI (8)
> DSO DSO (10)
> ALLPST PST0 (15), PST1 (14), PST2 (13), PST3 (12)
> PSTCLK CLK (24)
>
> Plus, of course, GND and Vcc. Everything else I left open.
>
> This works quite well with the P&E interface and P&E's debugger. I haven't
tried it with any other debugging software.
>
> Regarding the EZPort, I haven't delved into it. In my case, a Flash
programming tool was supplied as part of the P&E package, and it works just
fine using the same interconnect that also serves for BDM. For field
updates, I have implemented my own software functions which rely on
asynchronous serial communication (to receive new data from outside) and the
functionality supplied by the CFM module (chapter 15 in the manual) for
erasing and programming the Flash. I'm not sure in what situations you'd
prefer to use the EZPort.
>
> HTH,
> Harald Hallen
>
> *********** REPLY SEPARATOR ***********
>
> On 2006-02-18 at 17:41 Jonathan Griffitts wrote:
>
> >This feels like a dumb question, but here goes anyway:
> >
> >I'm working on a design with the MCF5213, having previous experience
> >with the 5307 and 5407.
> >
> >The 5213 documentation explicitly says that pin 26 of the BDM connector
> >is to be hooked to the TA signal. The problem is that (as far as I can
> >tell) there *IS* no TA signal on the 5213, since there is no external
> >bus. What are we supposed to do with pin 26? Open? Pulled up?
> >
> >
> >
> >
> >For awhile we were looking at using a 5212 instead. The BDM situation
> >is even more confusing there since a number of the normal BDM signals
> >are not present on the processor. Fortunately for me, that's no longer
> >an issue on this project.
> >
> >The documentation for the "EzPort" also seems a little bit sparse. Is
> >there a standard connector? If I pin out an EzPort connector, I see
> >four EzP signals, and ground, but what else should be there? RSTI?
> >
> >This all makes me think I may be missing some important piece of
> >documentation for this stuff. If someone can point me this information,
> >I would be grateful.
> >--
> > Jonathan Griffitts
> >AnyWare Engineering Boulder, CO, USA
> >303 442-0556
> >--------------------------------------------------------------------

Feb 20, 2006, 3:43 PM

Post #4 of 4 (26 views)
Copy Shortcut
 Re: [ColdFire] MCF5213 and BDM [In reply to]  Can't Post 

--------------------------------------------------------------------------------
 
David Brown wrote:
> As far as I understand it (and hopefully the more experianced folk will
> correct me if I'm wrong), the explaination below is almost correct. The
> signal on pin 26 should be TEA, not TA - i.e., Transaction Error Acknowledge
> rather than Transaction Acknowledge, and is an input to the ColdFire, not an
> output to be monitored.

Correct.

> Bringing the pin low during a bus cycle cuts the
> cycle off short and causes an exception. It can be used if the ColdFire is
> stuck accessing non-existant addresses.

You would think this would be case, how-ever on V2 core devices I have
tested this is not the case. If a BDM cycle occurs to an address that
will not generate a TA signal the core will lock up. The v4e cores with
the latest version of the debug module have a command that can be used
to recover from this situation. I have also tried the bus hardware
timer, break signal etc. Reset worked but had other side effects.

If my testing was wrong I would be happy to hear of a solution or better
see a patch.

> It's not an essential signal, so if you don't have it, don't worry.

The GDB BDM driver does assert the signal if no response is detected,
but it does not help as stated above.

Regards
Chris
 
 
 

Message Edited by Dietrich on 04-01-2006 11:30 AM

Message Edited by Dietrich on 04-04-2006 09:27 PM