M4809 RealTime Clock puzzles [solved]

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

Greetings Freaks!

 

I am trying to  understand how the RTC works in the Mega4809. I am using the really nice ATmega4809 Xplained Pro (which has no 32KHz crystal). And, yes, I have read (open in front of me at this moment) both "megaAVR-0 Series Family Data Sheet" and "TB3213-Getting-Started-with-RTC-DS90003213B".

 

Started with a standard "blinky", to verify that the MCU clock frequency is what I expect at 16MHz. No problems, there.

 

Next, I want to investigate the RTC prescaler, along with the period (RTC.PER) and compare (RTC.CMP) to understand how they interact.

 

My Step 2 of this exploration is to pipe in the OSCULP32K instead of using an external crystal, and trap it a few RTC clocks after it starts (eliminating any involvement of interrupts or events). I set RTC.PER = 0xffff; so that it won't overflow before other things happen and RTC.CMP = 0x0008; in the following code:

 

	//STEP 2 - set up RTC.COUNT with prescale DIV1
	while (RTC.STATUS & RTC_PERBUSY_bm) {}			//wait for PER NOT busy
	RTC.PER = 0x000f;					//so no rollover in test time
	while (RTC.STATUS * RTC_CMPBUSY_bm) {}                  //wait for CMP NOT busy
	RTC.CMP = 0x0008;                                       //CMP true after 8 cycles of internal 32.768KHz oscillator
	while (RTC.STATUS & RTC_CTRLABUSY_bm)	{}		//wait for CTRLA NOT busy
	RTC.CTRLA = RTC_PRESCALER_DIV1_gc + RTC_RTCEN_bm;	//count at 32KHz and turn on
	RTC.CLKSEL = RTC_CLKSEL_INT32K_gc;			//internal 32KHz osc is clock source
	//STEP 2	

	while (1)
	{
	        while ( (RTC.INTFLAGS & RTC_CMP_bm) == 0 ) {}  //wait for compare
		PORTB.OUT = 0x00;

	}

 Then, in AS7 debugger, I put a breakpoint on the PORTB.OUT statement.

 

My expectation is that RTC.CNT will show SOMETHING in the IO Window once the break hits. It always reaches the PORTB.OUT line, meaning that (RTC.INTFLAGS & RTC_CMP_bm) has become non-zero. Which should indicate that a comparison event has occurred. But RTC.CNT shows Nothing. Always reads 0x0000 in the IO register display.

 

So....

 

I add a variable at the head of main:  volatile int16_t RTC_var;

And, I add the following code just before the PORTB.OUT statement:

 

while (RTC.STATUS & RTC_CNTBUSY_bm) {}	    //wait for CNT NOT busy
RTC_var = RTC.CNT;                          //read the RTC count register

When I add a watch on RTC_var, it always reads 0x7100 once the break at PORTB.OUT is hit !

 

Hope someone with RTC experience on this beastie can help unravel this strange behavior. It seems to be doing SOMETHING but the "signals" leave me really confused. Hope I am just not  doing something correctly.

 

BTW, the spec sheet seems really unclear,  to me, whether or not  the interrupt has to be enabled for the event to become true. In the "old" AVR world, the flag would be set, but no ISR would be executed when the interrupt enable bit is clear. Have not been able to find an explicit statement here. Its probably in the document, just remaining unfound.

 

Many thanks

Jim

This topic has a solution.

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Mon. Jul 20, 2020 - 06:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:


	RTC.CTRLA = RTC_PRESCALER_DIV1_gc + RTC_RTCEN_bm;

 

Is it a valid expression?
 

The truth is more important than the facts.

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

Well, whether or not it is structurally correct, RTC_PRESCALER_DIV1_gc is zero and it results in the correct value for RTC.CTRLA. I admit  that I am still a bit befuddled by the _gc, _bm, etc syntax.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Mon. Jul 20, 2020 - 05:33 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I implement it as an interrupt rather than polled, it seems to work properly. Its not clear why polling does not work; it might be an issue with the asynchronous nature of that counter. 

 

So, while not really "solved", it is, sort-of. 

 

Its also clear that I need to understand some of the  new syntax better. _bm, I understand. Some of the others still seem a bit strange.

 

Thanks

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Have you seen this board?  Includes a programmer/debugger, serial port, and 32 KHz xtal

And it is lower cost than the  ATmega4809 Xplained Pro

https://www.digikey.com/product-detail/en/microchip-technology/DM320115/DM320115-ND/9657705

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

This has a good description of the _bm _bp _gm _gc naming convention

Title:

AVR1000: Getting Started Writing C-code for XMEGA

Name:

AN_8075

https://www.microchip.com/wwwApp...

 

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

To summarise:

 

_bm = bit mask - see 3.4.1

 

_bp = bit position - see 4.2

 

_gm = group mask - see 3.4.2

 

_gc  =  group configuration mask - see 3.5

 

As  MrKendo  says, it's just a naming convention - there is no special syntax here.

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

Agree that I improperly used term "syntax". Naming convention is more accurate. 

 

I have seen that document and need to re-read it.

 

Thanks

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Of course, there is nothing to stop you ditching all the structure stuff and writing you own 'old-skool' header file.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

ka7ehk wrote:
 Well, whether or not it is structurally correct, RTC_PRESCALER_DIV1_gc is zero and it results in the correct value for RTC.CTRLA

 

Ok, but generally speaking Bitwise OR and Addition are not universally interchangeable.
 

The truth is more important than the facts.

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

Good point in the general case. I've gotten a bit sloppy with named register bits; that is probably something I should quit doing.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!