portdd in mcf5213 programming

[maksimzykov]

Hi,

code for PORTC , found in CW examples works :

/* Enable signals as GPIO */

    MCF_GPIO_PTCPAR = 0

        | MCF_GPIO_PTCPAR_DTIN3_GPIO

        | MCF_GPIO_PTCPAR_DTIN2_GPIO

        | MCF_GPIO_PTCPAR_DTIN1_GPIO

        | MCF_GPIO_PTCPAR_DTIN0_GPIO;

     /* Set output values */

    MCF_GPIO_PORTTC = number;

    /* Enable signals as digital outputs */

    MCF_GPIO_DDRTC = 0

        | MCF_GPIO_DDRTC_DDRTC3

        | MCF_GPIO_DDRTC_DDRTC2

        | MCF_GPIO_DDRTC_DDRTC1

        | MCF_GPIO_DDRTC_DDRTC0;

But I can not manage how to do the same with PORTDD

Tried :

/* Enable signals as _GPIO_ */

    MCF_GPIO_PDDPAR = 0

        | MCF_GPIO_PDDPAR_PDD3_GPIO

        | MCF_GPIO_PDDPAR_PDD2_GPIO

        | MCF_GPIO_PDDPAR_PDD1_GPIO

        | MCF_GPIO_PDDPAR_PDD0_GPIO;

    /* Set output values */

    MCF_GPIO_PORTDD = number;

    /* Enable signals as digital _outputs_ */

    MCF_GPIO_DDRDD = 0

        | MCF_GPIO_DDRDD_DDRDD3

        | MCF_GPIO_DDRDD_DDRDD2

        | MCF_GPIO_DDRDD_DDRDD1

        | MCF_GPIO_DDRDD_DDRDD0;

No luck, it seems that PORTDD still in input state.

Any help will be highly appreciated.

Thanks in advance.

[TomE]

Search for "PORTDD" in this forum and find:

https://community.freescale.com/message/75180#75180

That is for an MCF5282, but it is the same series.

Does the above article answer your question?

Tom

[maksimzykov]

Hi.

thank you for reply, will try tomorrow if this works(I hope it will :).

Thanks again,

Max.

2014-09-27 18:51 GMT+03:00 Tom Evans <admin@community.freescale.com>:

<https://community.freescale.com/>

portdd in mcf5213 programming

reply from Tom Evans

<https://community.freescale.com/people/TomE?et=watches.email.thread> in *ColdFire/68K

Microcontrollers and Processors* - View the full discussion

<https://community.freescale.com/message/439660?et=watches.email.thread#439660>

[TomE]

You have added a reply to the MCF5282 thread:

Using Port DD as GPIO on MCF5282

I'm assuming that the pins are configured for PST and DDATA rather than the code to write the Pin Assignment registers not working.

You should disassemble the code that you provided above to see exactly what data is being written to which addresses. This is to make sure that there isn't an error in the header file definitions that you're using.

Now assuming that you've done that (and it is writing to the right registers), can you read the Pin Assignment and Direction registers back? Are they taking the values you're writing or are they read-only for some reason?

Having got the obvious bugs out of the way, and assuming the port is "stuck" in Debug mode against your wishes...

Reading the manuals I find that the MCF5282 has a PSTEN bit in the CCR register to enable the PST and DDATA functions on the pins. The MCF5213 does not have this control bit.

The Debug CSR Register has a "PST" bit in it which "Disables the PST/DDATA output signals". That MAY allow them to be used as GPIO pins. This is all undocumented, so you have to reverse engineer these things out for yourself unless someone else remembers how to do this.

You have to use the somewhat bizarre WDEBUG instruction to get to these bits.

Search this forum for "WDEBUG" to find references to this. Search this forum for "DDATA".

How are you going to program the chip without the debug pins?

Even if you can change the pins to GPIO, they're probably going to "flap about" in Debug mode until your code can get around to changing them. Are you sure the external hardware connected to those pins can handle this on Reset?

But people have been having trouble with these pins since 2009, finding that the control bits didn't work. There hasn't been an answer on these.

We even contacted Freescale through our rep to find out how to fix the problems we were having. The advice from Freescale was "the control bits work", but they

Disable PST/DDATA signals on MCF5274

> And yes, I have to use these pins as GPIO, because hardware is done, not by me, and I have to use it.

So yes, you may need to scrap the boards and redo all the hardware. You shouldn't commit to hardware until you have all the required functions working on the prototype.

We had similar problems with the MCF5235. It has both the CCR:PSTEN and CSR:PST bits, but no software can disable the 150MHz Radio Transmitter that is the PSTCLK pin. Fortunately for this problem, strapping the CPU to JTAG mode (with a resistor that the debugger can override back to Debug mode) reduced the EMC problem.

Tom

[maksimzykov]

don't know what was wrong, but this code works:

	/* Enable signals as _GPIO_ */
	MCF_GPIO_PDDPAR = 0
	| MCF_GPIO_PDDPAR_PDD7_GPIO
	| MCF_GPIO_PDDPAR_PDD6_GPIO
	| MCF_GPIO_PDDPAR_PDD5_GPIO
	| MCF_GPIO_PDDPAR_PDD4_GPIO
	| MCF_GPIO_PDDPAR_PDD3_GPIO
	| MCF_GPIO_PDDPAR_PDD2_GPIO
	| MCF_GPIO_PDDPAR_PDD1_GPIO
	| MCF_GPIO_PDDPAR_PDD0_GPIO;

	/* Set output values */
	MCF_GPIO_PORTDD = number;

	/* Enable signals as digital _outputs_ */
	MCF_GPIO_DDRDD = 0
	| MCF_GPIO_DDRDD_DDRDD7
	| MCF_GPIO_DDRDD_DDRDD6
	| MCF_GPIO_DDRDD_DDRDD5
	| MCF_GPIO_DDRDD_DDRDD4
	| MCF_GPIO_DDRDD_DDRDD3
	| MCF_GPIO_DDRDD_DDRDD2
	| MCF_GPIO_DDRDD_DDRDD1
	| MCF_GPIO_DDRDD_DDRDD0;