AVR128DA TCD port alternate problem

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried to use the AVR128DA32 TCD in the alternate position (PF0-PF3).

TCD used only WOA (waveform output A), others were GPIO.

However, the TCD waveform is output on all pins from WOA to WOD.

Also, if WOA is disabled and WOB to WOD are enabled, nothing will be obtained.

 

This looks like everything in CMPxEN is wrongly connected to CMPAEN.

The standard position does not have this problem.

The same problem was reproduced on the DA28.

The DA48 and DA64 have more alternate positions, but I can't see because I don't have them.

I will post the reproduction code.  what's your opinion.

#include <avr/io.h>
#include <stdbool.h>
#include <avr/interrupt.h>

#define F_CPU   4000000UL
////////////////////////////////////////////////////////////////
// CODE
////////////////////////////////////////////////////////////////
int16_t main(void){

    // ALL input disable
    PORTA.PINCONFIG = PORT_ISC_INPUT_DISABLE_gc;
    PORTA.PINCTRLUPD = 0xFF;
    PORTC.PINCTRLUPD = 0xFF;
    PORTD.PINCTRLUPD = 0xFF;
    PORTF.PINCTRLUPD = 0xFF;

    // OUTPUT DIR
    PORTA.DIR = PIN4_bm | PIN5_bm | PIN6_bm | PIN7_bm;  // TCD0 Normal position(PA4-PA7)
    PORTF.DIR = PIN0_bm | PIN1_bm | PIN2_bm | PIN3_bm;  // TCD0 Alternate position(PF0-PF3)

    // TCD init(PER:1KHz, Duty WOA:10%, WOB:90%)

    // TEST parameter -----------------------------------------------------------------
    PORTMUX.TCDROUTEA = PORTMUX_TCD0_ALT2_gc;           // ALTERNATE TCD
    _PROTECTED_WRITE(TCD0_FAULTCTRL, TCD_CMPAEN_bm);    // WOA Output enable(result : WOD-WOD all output enable)
//  _PROTECTED_WRITE(TCD0_FAULTCTRL, TCD_CMPBEN_bm);    // WOB Output enable(result : all no output)
//  _PROTECTED_WRITE(TCD0_FAULTCTRL, TCD_CMPCEN_bm);    // WOC Output enable(result : all no output)
//  _PROTECTED_WRITE(TCD0_FAULTCTRL, TCD_CMPDEN_bm);    // WOD Output enable(result : all no output)
    // TEST parameter end -----------------------------------------------------------------

    TCD0.CMPASET = 3599;
    TCD0.CMPACLR = 3999;
    TCD0.CMPBSET = 399;
    TCD0.CMPBCLR = 3999;
    while (!(TCD0.STATUS & TCD_CMDRDY_bm));
    TCD0.INTFLAGS = TCD_OVF_bm;
    TCD0.INTCTRL = TCD_OVF_bm;
    TCD0.CTRLB = TCD_WGMODE_ONERAMP_gc;
    while (!(TCD0.STATUS & TCD_ENRDY_bm));
    TCD0.CTRLA = TCD_CLKSEL_CLKPER_gc | TCD_ENABLE_bm;

    // MAIN LOOP ---------------------------------------------
    sei();
    while (1);
}

////////////////////////////////////////////////////////////////
// TCD interrupt
////////////////////////////////////////////////////////////////
ISR(TCD0_OVF_vect){
    TCD0.INTFLAGS = TCD_OVF_bm;

    // PORT Toggle(500Hz)
    PORTA.OUTTGL = PIN4_bm | PIN5_bm | PIN6_bm | PIN7_bm;
    PORTF.OUTTGL = PIN0_bm | PIN1_bm | PIN2_bm | PIN3_bm;
}

 

Further sadness

This time, I noticed that PF6 is fixed in the input direction.
I think it's a better change, but I can't replace some of my mega0 projects with DA. ;-(

Last Edited: Fri. Aug 28, 2020 - 05:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I confirm your observations (tested on AVR128DA28).

Clearly this is not the intended behaviour, the alternate pins should behave the same as the default ones. Another item to the errata list of the DA series, they really messed up the I/O pin functionality of several peripherals.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was too lazy to report to the global site.
Instead, I reported to "Microchip Japan", is that okay?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kabasan wrote:
I reported to "Microchip Japan", is that okay?

 

I think so. Anyway, people from former Atmel read the forum so maybe they already reported internally.

 

It seems to me the AVR-DA series is the first integrating tech from both Atmel and Microchip, so some problems are to be expected, I guess.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The DB series has not solved this problem either.
Please be careful.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kabasan wrote:
The DB series has not solved this problem either.

 

Really? It's not even reported in the errata yet, even though it was published in August and you detected the bug in June.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just checked the operation with AVR128DB28 that arrived yesterday.
Is Microchip busy with other things?