RENAMED: xmega32E5 Peripheral confusion

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

Hey all,

In my experimentation I have set my sights on the USARTC0 unit and I am hitting a wall of sorts.

 

I configured the USART in Atmel START to use the 32Mhz clock and a baud rate of 9600 yet I get NOTHING out of the PC7 pin.  The LED's connected to PORTA are doing their thing, but I see nothing from the USART.  

 

The manual for the E5 looked pretty straightforward and the settings in the config files look correct.

 

My simple code:

#include <atmel_start.h>

volatile uint16_t count;

int main(void)
{
	/* Initializes MCU, drivers and middleware */
	atmel_start_init();
	uint16_t foo = 1;
	USARTC0.DATA = 0X55;	//SEND SOME DATA
	/* Replace with your application code */
	while (1) {
		while(foo < 128)
		{
			if(count == 10)
			{
				PORTA.OUT = ~(foo);

				foo = foo * 2;
				USARTC0.DATA = 0X55;	//SEND SOME DATA
				count = 0x00;

			}
		}//end of while

		while(foo > 1)
		{
			if(count == 10)
			{
				PORTA.OUT = ~(foo);

				foo = foo / 2;
				USARTC0.DATA = 0X55;	//SEND SOME DATA
				count = 0x00;

			}
		}

	}//end of while(1)
}//end of main

I have attached the project in case someone wants to look at the config files as well.

 

Jim

Attachment(s): 

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Last Edited: Sat. Feb 24, 2018 - 04:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't see where you initiliase PC3 as output.

 

// USARTC0 driver

#include "xm_usartc0_s.h"

// Make  sure that the TX pin is an output in the init sequence
void USARTC0_init(void)
{
	PORTC_DIR |= (1<<PIN3_bp);	// Set TX pin for output

	USARTC0.BAUDCTRLB = (uint8_t) ((F_CPU / (16UL * baud_USARTC0)) - 1) >>8; // baud register high
	USARTC0.BAUDCTRLA = (uint8_t) (F_CPU / (16UL * baud_USARTC0)) - 1;	// baud register low
  	USARTC0.CTRLB = (1<<USART_RXEN_bp | 1<<USART_TXEN_bp ); 		// enable receive and transmit
}

int USARTC0_putchar(char c, FILE *stream)
{
	while (!(USARTC0.STATUS & (1 << USART_DREIF_bp)));
	USARTC0.DATA = c;
	return 0;
}

int USARTC0_getchar (FILE *stream)
{
	while(! (USARTC0.STATUS & (1 << USART_RXCIF_bp)));  // wait for data
	return USARTC0.DATA;
}

int	USARTC0_unbuffered_getchar(FILE *stream)
{
	uint8_t c = 0;	//Default return value if no char received

	if (USARTC0.STATUS & (1<<USART_RXCIF_bp))
		{
		c = USARTC0.DATA;
		}
	return c;
}

and watch the evil tabs in my code.....

 

project files for 2 USART, you need to import from AS4.18

 

Attachment(s): 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Wed. Feb 21, 2018 - 05:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
I don't see where you initiliase PC3 as output.

I used START to configure the USARTC0 module, and in the pin map it labeled the assocoated pins, BUT I admit I did not look to see if they were configured as outputs...will check in the morning.  

 

Dumb noob question....The XMEGA does not automatically take over the associated pin and set it accordingly as the AVR does?

 

I also noticed an issue in START that I will bring up in the ASF forum in the morning as well.

 

Thanks John

 

JIm

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

The XMEGA does not automatically take over the associated pin and set it accordingly as the AVR does?

NO! Big gotcha.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Also, if Atmel START is anything like the older ASF, it disables all the peripheral clocks. So you have to enable the clock for USARTC0 or it won't work.

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

js wrote:

The XMEGA does not automatically take over the associated pin and set it accordingly as the AVR does?

NO! Big gotcha.

Well I looked at START and according to the pinmap START set the pins to Digital inputs and outputs.  I changed them to Peripheral I/O but Start refuses to change the pin designation:

 

I checked the clock and it is connected to the same one that Timer4 is connected and I know the clock is working as the Timer is doing its thing:

 

And here is my USART configuration.  It all looks good.  9600 baud rate so not a speed demon.  I just get nothing out of PortC.7

 

 

Very frustrating....

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

I haven't used START.

 

Perhaps, however, it is confused if you tell it you want to use the USART and you tell it to assign the pins as general I.O pins.

 

In my code I just assign the TxData pin as an output and configure the USART.

 

Remember the Xmegas have a lot of options for the I/O pins, and you are simply telling the chip specifically how to configure the final output stages of the pin handler.

 

JC

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

Jim USARTC0 defaults to PC2 and PC3 (like my code), PC6 and PC7 are the alternate pin that you need to set a bit somewhere to use. They are otherwise used for SPIC Miso and Mosi. Don't know if START is clever enough that will change the pins default.

 

The same goes for USARTD0, the lower pins are the default.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Wed. Feb 21, 2018 - 09:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hear what you are saying Doc, and according to the datasheet I think I set things up correctly.  I am half tempted to move this thread to the ASF forum and see if one of the gurus at the home office knows anything.  I am doubting myself somewhat as I cannot think that NO ONE has never set up a 32e5 usart through START.

 

Grrrrr  Try to do things according to "the book" and it no workie!

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

SOOOOO 1 hour later I finally find the bit that controls the USART pins position!! Bit4 in the pin remap register. They could have AT LEAST indicate this in the USART section.

 

 

EDIT in the ASM .inc file they are:

equ PORTC_REMAP = 1614        // Pin Remap Register

.equ PORTD_REMAP = 1646        // Pin Remap Register

in the C structure something like PORTC.REMAP = xx; I don't know if the PORTC_REMAP direct addressing is also supported and too lazy to find out.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Wed. Feb 21, 2018 - 10:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The remap is in START albeit not explicitly stated.

So much for this being a simple test.

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

I feel your pain.

 

Sometimes a quickie test / project turns into a major struggle.

 

But, the up side is this:

 

The Xmega has the pin re-mapping capability, and frequently that is a life-saver!

 

JC 

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

Thats all well and Good Doc, but the point of all of this is I followed the START system and the XMEGA is sitting in my STK-600 with nothing connected to it other than my logic analyser and it sees nothing out of the TXD pin that should be PORTC.7.

 

GRRRRRRRRRRRRRRRRRRRRRRRRRRRR

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

Well I have tried everything I can think of to get this to work using START and its an epic fail.

 

I just looked and my Codevision IDE can create the INIT files for the XMEGA I am using so I shall try that and see what happens.

 

Beyond frustrated at this point.

 

JIm

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

I wouldn't bother with START. It doesn't support XMEGA very well anyway. The peripherals are easy enough to operate yourself.

 

By the way, be careful with any init code. I don't know what the Codevision stuff is like, but if it does more that set up the basic C environment it might be doing something like turning off the peripheral clocks.

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

Thanks for the update.

 

On the PLUS side, I used the CodeVision Wizard and set up the USART for 9600 8-N-1 and had it send the letter A every 500ms...IT WORKED!

 

I did notice in the Wizard though that it mentions the re-mapping which I picked the pins I chose in START.  I also noticed something in the output type CV does regarding totem pole that I need to compare against what START put out.

 

What I need to get to work is seeing how to set the x2 bit as it's not obvious in the CV wizard.  I also want to see this thing run at 2.5Mbaud as thats what I need in the end for this thing to hit.

 

Progress.

 

it was recommended I start a support ticket, but I fear that it would be another lesson in frustration.  Might start a thread in the ASF forum and see if something bubbles to the top.

 

Progress!!! Progress I say!!

 

JIm

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

Jim, your Start based project needed this line of code in main.c.  This does the actual remap and is independent of the USART initialization routines.

	PORTC.REMAP |= PORT_USART0_bm;

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

So my working project didn't work for you?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

larryvc wrote:

Jim, your Start based project needed this line of code in main.c.  This does the actual remap and is independent of the USART initialization routines.

	PORTC.REMAP |= PORT_USART0_bm;

I really think that this should be handled automatically by the Start USART configurator whenever alternate SIGNAL pins are selected for the USART RXD and TXD.  This line of code would then be inserted in the USART initialization function in driver_init.c.  The selected alternate Signal pins are correctly initialized in driver_init.c, but without this line of code they will not be used.  Note this line only needs to be added when alternate Signal pins are used.

 

​This is a bug that should be addressed by Microchip|Atmel ASAP as it appears to affect all XMEGA based Start projects.  Anyone want to write a support ticket? 

 

​EDIT: Just confirmed that without this line of code, the default USART RXD and TXD pins, PORTC pins 2 and 3 respectively, are still used.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Thu. Feb 22, 2018 - 11:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

larryvc wrote:
I really think that this should be handled automatically by the Start USART configurator whenever alternate SIGNAL pins are selected for the USART RXD and TXD. 

I did not select the pins....START picked them for me, so this should have worked out of the box so to speak.  See post #6.  That was done by Start.

 

js wrote:

So my working project didn't work for you?

Did not try it as I got wrapped up in something else.  Will open your project up later.

 

JIm

 

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Last Edited: Thu. Feb 22, 2018 - 10:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

larryvc wrote:

Jim, your Start based project needed this line of code in main.c.  This does the actual remap and is independent of the USART initialization routines.

	PORTC.REMAP |= PORT_USART0_bm;

OK, THAT worked!  I would not be adverse to say that this is a bug in the START utility, but before I jump up and down I am gonna create a new project and make sure I adjust nothing and see what happens first.

 

One thing though.  Here is my main.c file:

#include <atmel_start.h>
#include <util/delay.h>

int main(void)
{
	/* Initializes MCU, drivers and middleware */
	atmel_start_init();
	PORTC.REMAP |= PORT_USART0_bm;
	
	/* Replace with your application code */
	while (1) {
		_delay_ms(500);
		USARTC0_DATA = 0X55;
	}
}

My delay of 500 milliseconds is actually 9 seconds!  Why I do not know.  again, I am going to create a brand new project in START and see if it changes things.

 

Nice work Larry!  Thanks for this.

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

Also need to wait for the transmit buffer to be empty, though with the delay in this test program it probably doesn't matter.

#include <atmel_start.h>
#include <util/delay.h>

int main(void)
{
	/* Initializes MCU, drivers and middleware */
	atmel_start_init();
	PORTC.REMAP |= PORT_USART0_bm;

	/* Replace with your application code */
	while (1) {
		_delay_ms(500);
​                while (!(USARTC0.STATUS & USART_DREIF_bm;))
		USARTC0_DATA = 0X55;
	}
}

About the incorrect delay issue, we need to work on your Start CLK and OSC configurations a bit more, I had the same issue earlier.

 

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Thu. Feb 22, 2018 - 11:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

larryvc wrote:
About the incorrect delay issue, we need to work on your Start CLK and OSC configurations a bit more, I had the same issue earlier.

In Post #6 It shows what the peripherals are using.  The CPU is getting the same clock which should be 32Mhz. 

 

I will create a new START project form scratch later as I have to get some stuff out the door.  The 'clean' project will be just the usart and I will let START default everything first with 2Mhz clock, THEN I will try it at 32Mhz.  If there is a bug then we have proof.

 

Based on what I briefly looked at in Johns projects START may just be making things more complicated than they need be.

 

JIm

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

My delay of 500 milliseconds is actually 9 seconds!

Sounds like you are not running at the clock speed you thought you were.

 

Remember that with the Mega's, if one was running with the Div by 8 Fuse set, the clock was a factor of 8 slower.

 

With the Xmega and its numerous clock options, and the PLL, one can have an incorrect clock that is off by just about any factor you want.

 

There is another Xmega Thread on setting up the clock running at the moment.

It might give you some insight on how to configure the clock if you elect to do it yourself instead of using the Start IDE.

 

You only have to config a couple of register values to set it up.

 

JC 

 

Edit: typo 

Last Edited: Fri. Feb 23, 2018 - 12:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Understood Doc, and as I noted I will create a fresh START project to see if it made the boo boo.  Why am I constantly mentioning START?  Because I want to see if the tool supplied by Atmel is at fault, or is it because a noob missed something, or a combination of both.  As I mentioned in the thread about the XMEGA being unpopular, maybe the reason the XMEGA does not get the press is because the tools that are supposed to make using it easy are broken?  As I noted in the other thread I used START to be able to understand how the part works under the hood so as not to create 50+post threads.  After this experience I have learned a lot of what is there and my next course of action is to look at Johns project and then try writing my own to do the configuration myself.  On the other hand I have a licensed version of Codevision whose wizard got it right the FIRST time I used it

 

I for one think the XMEGA is not getting the credit it deserves.  After reading things over I am really warming up to the part, so now its a matter of getting the toolset proper.

 

JIm

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

larryvc wrote:
About the incorrect delay issue, we need to work on your Start CLK and OSC configurations a bit more, I had the same issue earlier.

 

Ok, I am looking at the configuration I have here in START....It looks like what I want...where did I go wrong Larry?

 

JIm

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

larryvc wrote:
  ​EDIT: Just confirmed that without this line of code, the default USART RXD and TXD pins, PORTC pins 2 and 3 respectively, are still used.

Ok, I just created a brand new START project for the XMEGA32E5 and it runs on the 2Mhz oscillator(default - I did not touch this)  I also added the UART and touched nothing.  Start assigned the RXD pin to PORTC.6, and the TXD pin to PORTC.7.  I did nothing.

 

Imported the configuration into AS&, added my MAIN.c looks like this:

#include <atmel_start.h>
#include <util/delay.h>

int main(void)
{
	/* Initializes MCU, drivers and middleware */
	atmel_start_init();

	/* Replace with your application code */
	while (1) {
		_delay_ms(500);
		USARTC0_DATA = 0x55;
	}
}

 

Build the project - No Errors, and load it into the XMEGA.  NOTHING on PortC Pin 7.  Nothing on PortC pin 3 which was mentioned as the default as well.

 

I add Larrys little line:

PORTC.REMAP |= PORT_USART0_bm;

rebuild and load the XMEGA....SUCCESS!  I have a byte of data every 500 milliseconds, B U T, my baud rate is only 4800, but in START I have it at 9600....WTF?  I touched absolutely nothing

 

Hmmm

 

Jim

 

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

What's the obsession with using the Alt pins on the USART instead of the "normal" pins? wink

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:

What's the obsession with using the Alt pins on the USART instead of the "normal" pins? wink

None, except that START used them by DEFAULT, not me.  AND that they did not bother to set that remap bit to allow for the USART to operate on those pins.  I am compiling a detailed list of bugs/issues in START on this for a support ticket..

 

Had it not been for you and Larry I would still be spinning my wheels wondering what I am doing wrong and wading through all these files.

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

js wrote:

So my working project didn't work for you?

Ok, I looked at your projects and they are indeed much simpler than what START generates.  In fact I see in your code much of what START created in mine, but in your case there is less jumping around between files.  Much more streamlined.

 

Question though is where you configure the clock structure?

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

It works on the default 2 MHz clock, if you add the 32MHz clock code you will need to change the define in Studio to 32MHz (currently 2MHz)

 

I usually specify that in the project_definitions.h file but for some reason (maybe too many crocodiles biting at me at that time) just added it to the project configuration.

 

Also if you want to use pins 6 and 7 add the PORTC.REMAP |= PORT_USART0_bm; line in the USART init C file and of course change

PORTD_DIR |= (1<<PIN3_bp);    // Set TX pin for output

to (1<<PIN7_bp)

 

I must have not done anything with that code for many years! The project was made for the atxmega128a1, glad it still works for the E5.

 

Maybe I will add a bit of code so that the Alt pins and the clock can be defined in the project_definitions.h file...or maybe not. cheeky getting too comfortably lazy, if it wasn't for the invoicing I wouldn't do anything anymore.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Well, ok it appears that there are some confusing bits(pun) involved with the USARTC0, but I have them documented.  So I now decide to add the SPI module as I am gonna need that

 

Went into START and added the module.  Take note of the pin settings:

 

The code:

#include <atmel_start.h>
#include <util/delay.h>

volatile uint16_t count;		//timing 'tick' counter

int main(void)
{
	/* Initializes MCU, drivers and middleware */
	atmel_start_init();
	uint16_t foo = 1;	//simple variable
	
	_delay_ms(1000);
	
	/* Replace with your application code */
	while (1) {
		
		
		
		while(foo < 128)
		{	
			if(count == 10)
			{
				PORTA.OUT = ~(foo);
				//foo++;
				foo = foo * 2;		//multiply variable by 2
				count = 0x00;		//clear tick counter
				USARTC0_DATA = 0x55;		//send a byte out the usart
			}//end of if
		}//end of while
		
		while(foo > 1)
		{
			if(count == 10)
			{
				PORTA.OUT = ~(foo);
				//foo++;
				foo = foo / 2;		//divide variable by 2
				count = 0x00;		//clear tick counter
				USARTC0.DATA = 0x55;		//send a byte out the usart
				
			}//end of if
		}//end of while()
		
		//send some SPI data
		SS_set_level(0);		//ACTIVATE SS PIN
		SPIC.DATA = 0XF0;		//SEND A BYTE OF DATA
		while(!(SPIC.STATUS & 0x80)); // wait for transmit complete
		SS_set_level(1);		//DEACTIVATE SS PIN
		uint8_t jim = SPIC.DATA;		//CLEAR THE FLAG
		
	}//end of while(1)
}//end of main

Build the code, get a warning about the variable 'jim' is unused.  Thats ok as I need to read the DATA register to clear the flag that indicates the data register is empty.

 

I load the XMEGA and now my counter is no longer working as I no longer have an LED zipping across PORTA as observed on my STK600, nor does the USARTC0 transmit.  My logic analyser(saleae Logic8) is telling me that the SPI lines are not correct, even though I see a clock, data, and the SS pin doing what I expect.

 

I elect to look at the SPI first as its 'working'.  After some second look overs I wonder something and reverse the SCK and MOSI connections and run the analyser again...SUCCESS!  the data reads out correctly!  START says the opposite of what the analyser reads.  I am going to believe the analyser as it tells me what color leads test what.  I double checked the connections to make sure I did not err...NOPE  START has it backwards angry

 

What about the part where the Timer does not work anymore? Torby mentions something here:

https://www.avrfreaks.net/forum/x...

 

and here as well:

https://www.avrfreaks.net/forum/t...

 

I am going to need both timers so I am hoping there is a simple solution to this issue.

 

Any suggestions would of course be greatly appreciated.

 

Jim

 

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

@jgmdesign wrote:

Question though is where you configure the clock structure?

 

This works for me.  It sets F_CPU/F_PER = 32MHz, F_PER2 = 64MHz, and F_PER4=128MHz, which you may not require.

	// enable RC32M and wait for ready
	OSC.CTRL |= OSC_RC32MEN_bm;
	while (!(OSC.STATUS & OSC_RC32MRDY_bm));

	// configure/enable PLL and wait for ready
	OSC.PLLCTRL = OSC_PLLSRC_RC32M_gc | 16;	// 8MHz * 16 = 128MHz
	OSC.CTRL |= OSC_PLLEN_bm;
	while (!(OSC.STATUS & OSC_PLLRDY_bm));

	// FIRST, set prescalers
	CLK.PSCTRL = CLK_PSADIV_1_gc | CLK_PSBCDIV_2_2_gc;

	// THEN, switch clock sources
	_PROTECTED_WRITE(CLK.CTRL, CLK_SCLKSEL_PLL_gc);

	// turn off RC2M
	OSC.CTRL &= ~OSC_RC2MEN_bm

NOTE: The RC32M oscillator is divided by 4 before the PLL, so the PLL sees 8MHz.

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

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

Ya but I want to use the 2Mhz oscillator for the SPI and 32Mhz for everything else

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Last Edited: Sat. Feb 24, 2018 - 05:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Go on Jim. Make your mind up.
Write down what you want.
.
You can run MSPI from about 1kHz up to 16MHz.
I have used MSPI up to 31MHz.
.
Of course an SPI Slave is a different matter.
.
The Codewizard is a good way to get started. Or just read the datasheet.
David.

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

Take note of the pin settings:

Which is what I would expect for the SPI but not for the USART.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Since you already have everything running at 32MHz, to run the SPI at 8 MHz set the Prescaler in the Start SPI config block to CLKper/4.  If you want a 2MHz SPI clock select CLKper/16 as the Prescaler setting.

 

​EDIT: To clarify things a bit, changing the SPI Prescaler value only changes the SPI speed (SCK frequency).  Most of the peripherals run off of the peripheral clock CLKper, including the SPI peripheral, and in this case CLKper is 32MHz.  There is no way to specify a different CLKper without affecting the other peripherals too.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Sat. Feb 24, 2018 - 11:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
Go on Jim. Make your mind up. Write down what you want. . You can run MSPI from about 1kHz up to 16MHz. I have used MSPI up to 31MHz. . Of course an SPI Slave is a different matter. . The Codewizard is a good way to get started. Or just read the datasheet. David.

Time for a cup of tea David? wink

I neglected to mention in Post #32 that I wanted the SPI to run at a lower clock frequency and the other peripherals and the CPU to remain at 32Mhz.  I unintentionally left that information out...Please forgive me.

 

You and I did think alike though regarding CodeVision wizard.  I plan on trying that out and see how it handles things tonight.

 

js wrote:

Take note of the pin settings:

Which is what I would expect for the SPI but not for the USART.

I though the same thing.  Add to the list.

 

@larryvc

Yes, I have it set at /128 but I can hot the speeds I want if I run it at 2Mhz or 8Mhz respectively Hence why I would prefer to use the other oscillators.

 

I am still unable to understand why the Timer and USART no longer work.  Very frustrating.  If I pull out the SPI code from MAIN they come back to life, but it takes 5 minutes for this to occur

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

Well I finished teh CV experiment and it does exactly what START does.  If I configure the TCC4C, USARTC0, and SPI and have code for all three in MAIN the timer and USART no longer work.  If I remove the SPI code(leave the init in place) and wait about 5 minutes to ten minutes the timer and USART code come to life.

 

Taking a step back for a little while to ponder this.  There is something that either I am not doing properly, or there is something funny going on in the chip.  I suspect the former over the latter of course.

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

Why do they call it SPI_0 instead of SPIC0? Very confusing.

Last Edited: Mon. Feb 26, 2018 - 08:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mojo-chan wrote:

Why do they call it SPI_0 instead of SPIC0? Very confusing.

It's only SPIC per the ATxmega32E5 datasheet.  That is the instance number of the peripheral module.

 

I am using an ATxmega128A1U, it has four SPI peripherals.  PORTC, PORTD, PORTE, and PORTF each has one SPI.  Notation of these peripherals are SPIC, SPID, SPIE, and SPIF.

 

Note the two SPI instances below, one is using the default name, the other I renamed to SPID, otherwise it would be SPI_1.  Also note that I turned Show hardware on, that displays the actual peripheral in use.

 

 

In my code there are two SPI init functions named per the above.

 

void SPI_0_init()
{

	// SPIC.INTCTRL = SPI_INTLVL_OFF_gc; /* Interrupt Disabled */

	SPIC.CTRL = 0 << SPI_CLK2X_bp         /* Enable Double Speed: disabled */
	            | 1 << SPI_ENABLE_bp      /* Enable Module: enabled */
	            | 0 << SPI_DORD_bp        /* Data Order Setting: disabled */
	            | 1 << SPI_MASTER_bp      /* Enable Master Mode: 1 */
	            | SPI_MODE_0_gc           /* SPI Mode 0 */
	            | SPI_PRESCALER_DIV64_gc; /* System Clock / 64 */

	SPI_0_desc.status = SPI_FREE;
}

void SPID_init()
{

...

}

 

  Not so confusing after all, and quite useful as they can be renamed again anytime and the code generator will update the changes for you.  Renamed SPI_0 to SPIC.

 

void SPIC_init()
{

...

}

 

Start to worry Mojo, you too will be assimilated!

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Tue. Feb 27, 2018 - 10:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well at least you can rename it. I will have to test out START a bit more, but since it doesn't support USB on XMEGA I don't really have any use for it. I've got my own USB stack now anyway...

 

To be fair it does seem better than the ASF. I've used the ASF in several commercial projects.

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

I found that Atmel Start incorrectly calculates the values for the Baud Rate registers because of the complexity of the BSCALE and BSEL values. I was trying to get familiar with the Xmega, so I started out using the default internal 2MHz, requested 9600 baud and couldn't get it to work. Looked at the values in the registers using a debugger - the values calculated by Start had given me 4800 baud. There's a bug in their fractional baud rate calcs.

 

TimboJ

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

Maybe they forgot to handle the CLK_X2 bit properly.

 

The other common failure of XMEGA baud rate calculators is at the extremes, particularly near the maximum baud rate.

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

timj28jl wrote:
I found that Atmel Start incorrectly calculates the values for the Baud Rate registers because of the complexity of the BSCALE and BSEL values.

That's ludicrous!!

 

surprise

 

The whole point of things like Start is precisely to cope with the complexity of the parts - so that the user doesn't have to!

 

If the tool can't cope with basics like this, then it's pointless!!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have had to take a step back from this for a little while sorry.  I have noticed that there have been some anomalies with regards to the X2 bit that I need to review again, so I will check on this.

 

Long story short, LarryVC and I have been going over a bunch of configurations and we are compiling up a list of issues based on our notes.  Once that has been done I am going to start over(Pun intended) from the beginning and test START against what Larry has done manually and see what the results are.   We have certainly identified some 'quirks' that have us both scratching our heads so we'I am calling a do over to confirm things.

 

Thanks for the feedback Tim

 

awneil wrote:

timj28jl wrote:
I found that Atmel Start incorrectly calculates the values for the Baud Rate registers because of the complexity of the BSCALE and BSEL values.

That's ludicrous!!

 

surprise

 

The whole point of things like Start is precisely to cope with the complexity of the parts - so that the user doesn't have to!

 

If the tool can't cope with basics like this, then it's pointless!!

 

START does cope with the complexities, but there are some questions on its methods.

 

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

awneil wrote:

timj28jl wrote:

I found that Atmel Start incorrectly calculates the values for the Baud Rate registers because of the complexity of the BSCALE and BSEL values.

 

That's ludicrous!!

 

surprise

 

The whole point of things like Start is precisely to cope with the complexity of the parts - so that the user doesn't have to!

 

If the tool can't cope with basics like this, then it's pointless!!

Not pointless, bugs happen,  the USART issue is just a very obvious omission of the CLK2X setting in the XMEGA based Start Drivers:USART:Basic driver code generator.  If you select the Drivers:USART:Init driver you will see that it has the CLK2X selector.  So in the meantime if you want to use the USART Basic driver and it's accompanying useful functions then you have to add the code to set the CLK2X bit manually.  It took only a few minutes to discover and fix the problem by reviewing the code that was generated.  If  you don't have time to do that, don't use Start.

 

Issues like this need to be reported, and until they are nothing is going to get fixed.  So I urge all of you to stop whining about Start and initiate a support ticket to address the problems that you find so that they do get fixed.​​

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius