topic TWR-MCF54418 DAC Module in ColdFire/68K Microcontrollers and Processors

TWR-MCF54418 DAC Module

usmansaeed — Fri, 26 Apr 2013 17:21:03 GMT

Hi,

I am working on various peripherals of the tower board (TWR-MCF54418).

But for now, I am stuck at DAC (Digital to Analog Converter).

The problem is that when I try to read the DAC related registers (MCF_DAC0_CR, MCF_DAC0_STEP, MCF_DAC0_MIN, MCF_DAC0_MAX, and MCF_DAC0_DATA) as mentioned in section 30.3 of the MCF54418RM (http://cache.freescale.com/files/32bit/doc/ref_manual/MCF54418RM.pdf), they all return 0xFFFF.

Even when I configure them, they don't retain their states and immediately over-written as 0xFFFF.

I have configured the MISCCR2 as 0xE861 to enable both the DAC modules and disable the ADCs.

My configuration of tower module contains, TWR-MCF54418 and TWR-SER2, attached with the TWR-ELEV modules.

I am running Linux 2.6.29 on the said board.

I have tried configuring those registers on the bare board, but it returned the same behavior as well.

Can anyone please point out what I am missing, or where I am doing wrong?

Here is the code for the bare board on Code Warrior ProfessionalEditionMCU 10.0:

#include "support_common.h" /* include peripheral declarations and more */

#if (CONSOLE_IO_SUPPORT || ENABLE_UART_SUPPORT)

/* Standard IO is only possible if Console or UART support is enabled. */

#include <stdio.h>

#endif

#define MISCCR2 (*(unsigned short*)(0xEC09001A))

#define ADCTSR (*(unsigned short*)(0xEC09001C))

#define DACTSR (*(unsigned short*)(0xEC09001E))

#define ADC_CAL (*(unsigned short*)(0xFC094054))

#define PPMHR0 (*(unsigned int*)(0xFC040030))

enum STATES

{

STATE1,

STATE2,

STATE3,

STATE4,

};

int main(void)

{

int counter = 0;

unsigned char state = STATE1;

#if (CONSOLE_IO_SUPPORT || ENABLE_UART_SUPPORT)

//printf("Hello World in C++ from MCF54418 derivative on TWR-MCF5441X board\n\r");

#endif

for(;;)

{

switch(state)

{

case STATE1:

MISCCR2 = MISCCR2 & 0xFFE1; //0xEC09001A

MISCCR2 = MISCCR2 | 0x0060; //0xEC09001A

printf("Register states in STATE1\n");

printf("MISCCR2: %d\n", MISCCR2); //0xEC09001A

printf("ADCTSR: %d\n", ADCTSR); //0xEC09001C

printf("DACTSR: %d\n", DACTSR); //0xEC09001E

printf("ADC_CAL %d\n", ADC_CAL); //0xFC094054

printf("PPMHR0 %d\n", PPMHR0); //0xFC040030

printf("MCF_DAC0_CR: %d\n", MCF_DAC0_CR); //0xFC098000

printf("MCF_DAC0_STEP: %d\n", MCF_DAC0_STEP); //0xFC098004

printf("MCF_DAC0_MIN: %d\n", MCF_DAC0_MIN); //0xFC098006

printf("MCF_DAC0_MAX: %d\n", MCF_DAC0_MAX); //0xFC098008

printf("MCF_DAC0_DATA: %d\n", MCF_DAC0_DATA); //0xFC098002

state = STATE2;

break;

case STATE2:

printf("Configuring Registers\n");

MCF_DAC0_CR = 0x1101; //0xFC098000

ADC_CAL = ADC_CAL | 0x03; //0xFC094054

MCF_DAC0_STEP = 0x0004; //0xFC098004

MCF_DAC0_MIN = 0x0745; //0xFC098006

MCF_DAC0_MAX = 0xFE8A; //0xFC098008

MCF_DAC0_DATA = MCF_DAC0_MAX; //0xFC098008

state = STATE3;

break;

case STATE3:

printf("Setting PDN low to activate DAC\n");

MCF_DAC0_CR = MCF_DAC0_CR & 0xFFFE;

state = STATE4;

break;

case STATE4:

printf("MISCCR2: %d\n", MISCCR2);

printf("ADCTSR: %d\n", ADCTSR);

printf("DACTSR: %d\n", DACTSR);

printf("ADC_CAL %d\n", ADC_CAL);

printf("PPMHR0 %d\n", PPMHR0);

printf("MCF_DAC0_CR: %d\n", MCF_DAC0_CR);

printf("MCF_DAC0_STEP: %d\n", MCF_DAC0_STEP);

printf("MCF_DAC0_MIN: %d\n", MCF_DAC0_MIN);

printf("MCF_DAC0_MAX: %d\n", MCF_DAC0_MAX);

printf("MCF_DAC0_DATA: %d\n", MCF_DAC0_DATA);

break;

}

And here is the output of the bare board:

MISCCR2: 59489

ADCTSR: 0

DACTSR: 0

ADC_CAL 65535

PPMHR0 2115943423

MCF_DAC0_CR: 65535

MCF_DAC0_STEP: 65535

MCF_DAC0_MIN: 65535

MCF_DAC0_MAX: 65535

MCF_DAC0_DATA: 65535

Configuring Registers

MISCCR2: 59489

ADCTSR: 0

DACTSR: 0

ADC_CAL 65535

PPMHR0 2115943423

MCF_DAC0_CR: 65535

MCF_DAC0_STEP: 65535

MCF_DAC0_MIN: 65535

MCF_DAC0_MAX: 65535

MCF_DAC0_DATA: 65535

MISCCR2: 59489

ADCTSR: 0

DACTSR: 0

ADC_CAL 65535

PPMHR0 2115943423

MCF_DAC0_CR: 65535

MCF_DAC0_STEP: 65535

MCF_DAC0_MIN: 65535

MCF_DAC0_MAX: 65535

MCF_DAC0_DATA: 65535

MISCCR2: 59489

ADCTSR: 0

DACTSR: 0

ADC_CAL 65535

PPMHR0 2115943423

MCF_DAC0_CR: 65535

MCF_DAC0_STEP: 65535

MCF_DAC0_MIN: 65535

MCF_DAC0_MAX: 65535

MCF_DAC0_DATA: 65535

MISCCR2: 59489

ADCTSR: 0

DACTSR: 0

ADC_CAL 65535

PPMHR0 2115943423

MCF_DAC0_CR: 65535

MCF_DAC0_STEP: 65535

MCF_DAC0_MIN: 65535

MCF_DAC0_MAX: 65535

MCF_DAC0_DATA: 65535

MISCCR2: 59489

ADCTSR: 0

DACTSR: 0

ADC_CAL 65535

PPMHR0 2115943423

MCF_DAC0_CR: 65535

MCF_DAC0_STEP: 65535

MCF_DAC0_MIN: 65535

MCF_DAC0_MAX: 65535

MCF_DAC0_DATA: 65535

Re: TWR-MCF54418 DAC Module

antonio_agenjo — Wed, 16 Sep 2015 11:45:18 GMT

I believe there is a mistake in Table 9-5 of the MCF5441x Reference Manual, where PPMHR0[CDn] assignments are enumerated. You are resetting CD39, which is associated to DAC0 in the table, and I have checked that it is CD38 which enables DAC. There is also a mistake with ADC, which is enabled by CD37 instead of being enabled by CD38. I have not checked all of the rest, but it is possible that more mistakes could exist. If you reset CD38 in PPMHR0 you will notice that DAC0 registers return values different than 0xFFFF.

Re: TWR-MCF54418 DAC Module

TomE — Fri, 30 Oct 2015 10:28:45 GMT

> I believe there is a mistake in Table 9-5 of the MCF5441x Reference Manual,

Well spotted. If you want to use DMA you'll want the PREVIOUS version of the manual. They managed to take a good version 3 of the manual and add lots more errors in Version 4. And then never fixed them or released any Addenda for those. I've checked Version 3 and it has the same PPMHR assignments. This is "normal" with these manuals. I'm still finding bad bugs in the 1993 68000 User\'s Manual. "Table A-1. MC68010 Loop Mode Instructions" omits the "memory move" mode documented (with a bad typo) in "Figure A-1. DBcc Loop Mode Program Example".

Old version of the manual available here:

Re: MCF54415 eDMA help

Unless you are running on a battery and have to save power, or you want it to run cooler, or you want to reduce EMC, or you just want to program it the way it is documented, it might be worth turning EVERYTHING on in all four control registers. That's probably how it was tested, and may be the only way it works.

We might be able to work it out without resorting to trial-and-error with the hardware though. The manual says:

9.2.4 Peripheral Power Management Registers (PPMHR{1,0}, PPMLR{1,0})

The PPMR registers provide a bit map for controlling the generation of the peripheral clocks for each

decoded address space. Recall each peripheral module is mapped into 16 kByte slots within the memory

map. The PPMR registers provide a unique control bit for each address space that defines whether the

module clock for the given space is enabled or disabled.

So assuming they got the address map tables correct, we just have to find which 16k slot those peripherals are actually in, which is:

Table 1-3. Peripheral Bus Controller 0 Memory Map (continued)

0xFC08_0000 32 PIT 0

0xFC08_4000 33 PIT 1

0xFC08_8000 34 PIT 2

0xFC08_C000 35 PIT 3

0xFC09_0000 36 Edge port 0

0xFC09_4000 37 ADC

0xFC09_8000 38 DAC 0

0xFC09_C000 39 DAC 1

0xFC0A_8000 42 Robust real-time clock

Here you can see where this table gets it wrong, as it completely misses DAC1:

Table 9-5. PPMHR0[CDn] Assignments

32 CD32 PIT 0

33 CD33 PIT 1

34 CD34 PIT 2

35 CD35 PIT 3

37 CD37 Edge Port

38 CD38 ADC

39 CD39 DAC0

42 CD42 Robust RTC

This is likely to be a cut/paste/edit mistake when composing the manual from another one for a similar chip. For instance, the MCF54455's Memory Map has the "Edge Port" in a different slot to the MCF54418, but it in the same place as in the mistaken MCF54418's PPMHR0 Table:

MCF54455 Reference Manual, Rev 5

Table 1-3. Internal Peripheral Space Memory Map (continued)

0xFC08_0000 32 PIT 0

0xFC08_4000 33 PIT 1

0xFC08_8000 34 PIT 2

0xFC08_C000 35 PIT 3

0xFC09_4000 37 Edge Port

0xFC0A_0000 40 CCM, Reset Controller, Power Management

Tom