Disabling BDM interface on MCF5484

[gpe]

Hello!

I would like to turn off the PSTDDATA[7..0] and PSTCLK lines to reduce EMI emission of my device.To turn these off, I know you can execute WDEBUG command to set the PCD bit of CSR register but I don't know how to do that.

Please, do you know if there is a convenient flag to set in Linux Kernel configuration ?

Thanks

Greg

[TomE]

Don't know about linux. This is probably something you're going to ahve to add to the board or CPU customisation source files.

I'm using an MCF5329 and the code to do this for that chip looks like this:

  /*   * 36.4.1.5.15 Write Debug Module Register (WDMREG)   *   * Bit 17: PCD: PSTCLK disable.   * 0 PSTCLK is fully operational   * 1 Disables the generation of the PSTCLK and PSTDDATA output signals,   * and forces these signals to remain quiescent   * Note: When PCD is set, do not execute a wddata   * instruction or perform any debug captures. Doing so, hangs the device.   */  .align  4debug:  .word   0x2C80    /* write to CSR */  .word   0x0002    /* Upper 32 bits, default 0, setting PCD */  .word   0x0000    /* Lower 32 bits, default 0 */  .word   0x0000/*Write to CSR register to turn off PST pins (for EMC reasons)    The PST pins are only turned off when the loader has been loaded out    of flash so that the BDM can still be used to bootload */  move.l  #debug, a0  wdebug (a0)

Tom

[Mayer]

Hi TomE,

I have also EMC problem with my board based on MCF5329 - 120MHz on pin  24 BDM programmer

(PSTCLK disable)

Where should I put that code - which file (maybe mcf532x_lo.s) or other place ?

Thanks,

Mayer

[TomE]

> Where should I put that code - which file (maybe mcf532x_lo.s) or other place ?

I don't know what OS or source code base you're using so I can't give a precise answer. You may be running code based on whatever CodeWarrior or one of the other Freescale software products. We're not.

It doesn't matter where this code is, as long as it gets executed somewhere at startup.

Depending on your system, it might be easier to add it to the lowest-level startup code, just after the chip selects, SDRAM and I/O pins have been set up. Or you might create an assembly function that can be called from some C code if that makes more sense for your design.

Do you have separate Bootstrap and Application code?

How are you going to handle running the code under the debugger? The way we do it here is to have the Bootstrap in FLASH set up the chip selects and the SDRAM controller, set up the Watchdog, disable the Debug pins and then copy itself to RAM. When running under the debugger, we load the Bootstrap into the normal target SDRAM location and run it from there. The code "knows" when it has started from SDRAM (by checking its program counter) and bypasses the SDRAM setup, Debug disabling, and programs the Watchdog differently so it pauses when the debugger stops the code.

Tom

[Mayer]

Hi Tom,

I put the code in mcf532x_lo.s  just before main and all the configuration of fbcs and SDRAM - it's looks like it work

but I have  a problem that  all the application stuck

I got mcf5xxx_exception_handler interrupt  all the time

I don't have OS - regular big loop

This firmware version is for release - for Client, no need to debug it any more - just to work

We have bootloader but not implemented in that application

What can I do ?

Thanks,

Mayer

[TomE]

I've been thinking about your problem. You didn't say that adding the "wdebug()" has CAUSED the "exception" problem, but I'm guessing it has.

So if you remove the "wdebug" the problem goes away?

That makes debugging very simple as we know exactly where the problem is - with the debug.

Assuming you know nothing about assembly coding and have just dropped the "wdebug" into the middle of some other code, there are two things that you might have got wrong.

Firstly, the syntax of the wdebug instruction from CFPRM>PDF is "WDEBUG.L <ea>y". In the example I gave it is using an address register to point to the debug data. So you have to select a register to use that is not being used for anything else in the code at the point where you added the instruction. So it is possible that the code is doing something like:

    <Load something important into register A0>    /* Newly added code */    move.l  #debug, a0    wdebug (a0)    <Now try to use previous important data in A0>

If that is what has happened you should choose a different register that is not currently in use to replace "a0" in the added wdebug code, or move the code somewhere else.

The other possibility is that you've dropped the "debug data" into the middle of the code. Assembly isn't like "C", where the compiler knows that something like "int nValue" is a declaration of a variable. So if you put the "debug:" and the "wdebug" in line and next to each other it would result in the CPU is trying to execute the 0x2c80, 0x0002, 0x0000, 0x0000" data as instructions. That would be interpreted as "move.l d0, (d6)" followed by 3 unassigned instructions, which would trigger an illegal instruction exception. Is that what you did? If so, move the "debug:" data up higher in the file to where other data is being declared, and before where the code starts.

Tom

[Mayer]

Hi Tom,

First - Thanks for your time and effort to solving my problem

I took your code "as is" and put it in my  asm_code routine

align  4debug:  .word   0x2C80    /* write to CSR */  .word   0x0002    /* Upper 32 bits, default 0, setting PCD */  .word   0x0000    /* Lower 32 bits, default 0 */  .word   0x0000   move.l  #debug, a0  wdebug (a0)

The codewarrior didn't warn any thing - and compile it

when I run the debuger step by step and it got to those lines :

  .word   0x2C80    /* write to CSR */  .word   0x0002    /* Upper 32 bits, default 0, setting PCD */  .word   0x0000    /* Lower 32 bits, default 0 */  .word   0x0000

right away got exception interrupt handler - and stuck 

when I take the code to above the asm_code routine in the segment of .data  and than every thing worked fine

the code line:

  move.l  #debug, a0  wdebug.l (a0)

Stay in the asm_code routine

I changed wdebug to wdebug.l

Thank for your help

Mayer

Attached my file - for example change the extension  to .s

[TomE]

> I got mcf5xxx_exception_handler interrupt  all the time

That is the name of a function in your code. It is not the name of a specific ColdFire exception.

So I have no idea which interrupt is causing it. By the name I would guess that all unhandled interrupts (all interrupts that your code doesn't handle) end up in that routine.

> What can I do ?

Debug it. Normal simple program debugging.

You need to enable the debugger, attach it to the board, and then put a breakpoint on that function before starting the code.

From the debugger you should be able to inspect registers to find WHICH exception it is. It might be a divide-by-zero. It might be an address or instruction error.

Even better, the "stack trace" function of the debugger should show you which instruction in your code caused the problem. From there it should be obvious what caused the problem and how to fix it.

Tom