RTC bug on ATXMEGA16E5!!!

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

Hi,

 

I am using ATXMEGA16E5 in a application. And i use the RTC clock ( period 1 sec , external 32.768 clock) to wakeup from power save mode.

After wake up i measure some ADC channels and after goes to power save mode.

The program works well when no debugging.

When i use the AtmelICE and i push HALT it does not stops, and IAR gives a error "Fatal error : Failed to attach to target with PDI interface" and the debug stops!!!!!!  So i can not make debug!!!!

 

The same happens at the example of IAR "rtc_example" of ATxmega32E5!! Even when i used the aplication Note AVR1314 the same problem!!!

 

if I use the mcu ATxmega64B3 it works well!!.

This is crasy. Does anyone face the same problem? or have a solution?

 

I tried to use a new mcu insteed of atmega88 but i am faceing "newborn" problems. Also ASF is not a proffesional framework it is just a collection of function.

I am using atmel more 15 years and i did not had a any serious problem with atmega. Maybe Atxmega was release too early.

 

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

All the AVR experts must took a walk! ASF is NOT a framework, that's 100% true! It is a collection of routines, escorted by very poor documentation. You should stick to good old fashioned ATmega168. The "experts" who wrote this so called "framework" shouldn't be above 20 years old, because this "framework" is an example to avoid even for students! Library files mixed with application files? I bet this is a world patent!!! The teachers in the elementary school say "DO NOT MIX LOW LEVEL FUNCTIONS WITH APPLICATION FUNCTIONS, instead use callback functions". But in ASF they hide MCU driver files inside evaluation board files. It is just a comic tragedy.

 

PS: A new generation (?) MCU, without live watch!!! Ha! I expected more from Atmel.

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

Ah! Welcome to the club. I was facing a few similar problems with ASF and I had to edit the original ASF files in order to work with IAR. My opinion for the ASF is that someone should be fired.

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

I wonder if the PDI debugger has trouble when the processor is asleep. Try setting a breakpoint in some code it will hit when awake.

 

I agree, I don't find ASF to be very useful.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

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

Hi Torby,

 

If i put a breakpoint is working. it stop. But when it in run it does not stops/halt. I do not understand.

 

Yes ADF is confusing....

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

The debugger does seem to have issues when the chip is asleep. If you use a breakpoint and wait for it to wake up everything is fine, but if you try to pause it while asleep...

 

A quick hacky work-around is to set up a button and some code that triggers when it is pressed, and put a breakpoint on that.

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

Hi mojo-chan,

This probably is a work-around solution. But i need to change the PCB to use this and it not easy to debug.

 

The debugger or the mcu have bug, and atmel must give a solution. 

 

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

if you want action from Atmel, then contact them. We are not Atmel. Besides, what gave you the impression Atmel have to do anything to solve your problem? Many devices have defects that aren't fixed - so read the terms and conditions of the contract you entered into when you purchased Atmel parts.

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

Kartman wrote:

if you want action from Atmel, then contact them. We are not Atmel. Besides, what gave you the impression Atmel have to do anything to solve your problem? Many devices have defects that aren't fixed - so read the terms and conditions of the contract you entered into when you purchased Atmel parts.

 

O load of crap! Atmel should do NOTHING to improve their product, interesting theory!!!! BTW do you have any idea of the terms "market", "competition" or "quality product"? Are you a pro or a hobbyist? Send a CV to ATMEL to hide you as their lawyer...

 

PS: If you have nothing to answer, then just stay quiet. I hope the other 12K posts of yours to be meaningful and helpful and not nonsense like this one!

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

Torby wrote:
I wonder if the PDI debugger has trouble when the processor is asleep. Try setting a breakpoint in some code it will hit when awake.

 

mojo-chan wrote:
The debugger does seem to have issues when the chip is asleep.

 

Same with the SAM D20/D21/R21.

 

With low power being such an important thing these days - and Atmel trying to play to that - Atmel really need to get their act together on debugging with sleep modes.

 

Other manufacturers - eg, TI, Energy Micro (now SiLabs) - not only "cope" with it, but have specific features to analyse it!

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: 1

awneil wrote:

With low power being such an important thing these days - and Atmel trying to play to that - Atmel really need to get their act together on debugging with sleep modes.

 

I agree with awneil. Atmel advertise picopower. But the debug have a lot of probelm when the mcu is in sleep mode.

Also the problem is that ASF is not proffesional and have a lot of bugs and no documentations.

 

 

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

xxxtigerxxx wrote:
ASF is not proffesional (sic)

How so?

 

Quote:
and have a lot of bugs

I can't say that it has any more bugs that the equivalents from the other manufacturers...

 

Quote:
and no documentations.

That's just not true!

 

You may find it unhelpful, and/or consider it incomplete - but you can't say that it does not exist!

 

http://asf.atmel.com/docs/latest/

 

 

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: 1

Hi awneil. Below are my answers 

 

1 ) ASF is not proffesional (sic)

 

Because all *.c and *.h files has almost no or minimum comments.

At the beginning of the file there is not history, revision and description fo the file. Just some copyright s@t.

No even that this file belong to ASF 3.2.1 and the version of the file is x.xx.xx.

They a lot of defines without any comments, and the defines for a module is not all together ( for example GPIO ).

Functions call in most case there is no help for the arguments.

And the most important there is not template project that has all module inside like ST framework.

So you must gather files from GPIO examples , from UART example. But the GPIO example has other uart file that UART example.

It is a mess.

 

 

2) I can't say that it has any more bugs that the equivalents from the other manufacturers...

 

I be working with ASF last month and i found like 4-5 bugs. (On rtc, on sleepmng, on compiler there are all of warnings without a reason etc).

With CMIS, and ST framework i did not find so more tha 1 bug the last 2 years.

 

3) and no documentations.

 OK there is some documentation. 

But for example i read are incomplete and have mistakes. For example , the rtc ( aplication note AVR1314 ) has steps that can not be fulled!!

 

 

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

I'm sorry my comments raised such ire! If you had early xmega silicon with lots of defects, did Atmel replace the silicon? Point being Atmel don't have to do anything - but it would be nice if they did. Same with other suppliers. So rather than waging a personal attack on myself, why don't you follow up the issue with Atmel then report the outcome?

Nevertheless, if a potential defect is found , contact Atmel. At least then it gets into their system and hopefully followed up.

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

Part of the problem is that the ASF is so heavily abstracted in order to allow the use of the same API on multiple hardware platforms. I preferred the old app note code which was XMEGA specific, as it was much easier to use as a reference for how things are supposed to work than the ASF is.

 

Having said that, despite a few bugs the ASF USB stack is pretty good. Some stuff is pointless, like USART and SPI drivers, but the USB stack has proven to be fairly robust and reliable (apart from the USB 3.0 serial number bug).

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

Hi Kartman,

 

My agreement is nto with you but is ATMEL support. I have send to atmel oficial site and i am still waiting.

 

With ATmega series I did not had any serious problem. Some college told me that ATxmega are good. So i put in a project ATXmega for reducing the cost and upgrading the perfomance.

 

But i found out ATXMega+ASF makes your life difficult.

 

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

mojo-chan wrote:
Part of the problem is that the ASF is so heavily abstracted...

I agree.

 

Sadly, it seems that ST are going the same way with their "STM32Cube"...

 

https://www.avrfreaks.net/comment...

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...
Last Edited: Wed. Dec 24, 2014 - 11:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is their any manufacturer that has 'good' libraries? At best they are a compromise - on one hand they need to be generic and on the other we want them efficient. I just use them as a starting point. What is a worrying trend is that there are workarounds in the code that aren't in the documentation or simply aren't documented. The old AVR is a wonderfully simple chip - newer stuff is a lot more involved.

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

Kartman wrote:
What is a worrying trend is that there are workarounds in the code that aren't in the documentation or simply aren't documented.

Yes, I saw that with the SAM D20/D21/R21 - there were comments in the code referencing Errata numbers, but those Errata were not mentioned anywhere in any published documentation.

 

angry

 

What was that about free lunches...?

 

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: 2

Kartman wrote:

The old AVR is a wonderfully simple chip - newer stuff is a lot more involved.

 

I agree with you, but instead of look back to the old days lets try to solve the issue that xxxtigerxxx has. Is there any workaround?

 

Why ATMEL tried to make one generic software framework that "works" with all of their products, instead of providing different framework solutions for Xmega and SAM?angrynono

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

th_shak wrote:
Why ATMEL tried to make one generic software framework that "works" with all of their products, instead of providing different framework solutions for Xmega and SAM?

Note that it's not just XMega & SAM; there's also AVR32. And "SAM" covers some quite different product lines...

 

So answer to that should be obvious - it is clearly in Atmel's interest to just have a single framework rather than have to duplicate (triplicate?) effort on multiple product line!

 

To some extent, that's also in the customer's interest - making it easier to choose among the different ranges according to specific project requirements without having to duplicate (triplicate?) effort on (re-)learning multiple frameworks!

 

But, as always, there is no such thing as a free lunch - the price of generality is efficiency.

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...
Last Edited: Wed. Dec 24, 2014 - 01:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

th_shak wrote:
try to solve the issue that xxxtigerxxx has. Is there any workaround?

As already noted, the problem has nothing to do with ASF - it's an issue with the debugger not coping with Sleep modes.

 

You would get exactly the same if you wrote the code "from scratch" without ASF. Even in assembler.

 

And a workaround has already been suggested: use a breakpoint where it is not asleep!

 

 

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

Hi awneil,

 

The workaround to use a breakpoint in not good for my aplication.

 

Because i would like to start and stop the debug to see the variables and the state of the aplication.

 

Also i would like to stoip debug when the product is not responce well to see the potenial BUG.

 

If the Atxmega had real time view or variables it will be very helpfull.

 

P.S. the atmel answer me that they also reproduce the issue with the project settings in the example project. But i do not have a solution up to now.