ATMega324PB and external AREF

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

Just got a few samples of ATMega324PB. I would like to use it instead of ATMega324P(A) in our current project. ATMega324PB should be backwards compatible with older flavors of ATMega324 but I got stucked with external AREF for ADC. To cut the long story short - I can't get it to work as supposed. When I select external AREF, ADC always reads 0x3FF on any channel I select - like AREF is not routed to the pin. On ATMega324PB it is shared with (new) PortE, but according to Microchip, if ADC is enabled and AREF set to external, pin should be automatically re-routed as an AREF input. On the other hand, if any other reference source is selected, it works as expected....

 

To make things clearer - hardware is OK, if ATMega324PA is soldered and programmed with the same HEX file, it works as supposed, with ATmega324PB I see this issue. By the way, other things work correctly (timers, PWM, GPIO...).

Can anybody try it out and verify my findings, or point me in the right direction if I'm missing something ?

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

ddurdeni wrote:
ATMega324PB should be backwards compatible with older flavors of ATMega324 but I got stucked with external AREF for ADC. 

http://ww1.microchip.com/downloads/en/AppNotes/Atmel-42769-Differences-between-ATmega324-and-ATmega324PB_ApplicationNote_AVR42769.pdf

(page 1)

...

ATmega324PB is not a drop-in replacement for ATmega324 variants, but a new device. ...

...

could be due to datasheet's

Table 16-16. Overriding Signals for Alternate Functions in PE6...PE3


http://www.microchip.com/wwwproducts/en/atmega324pb

 

Edit: 2nd URL

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Jan 10, 2018 - 01:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The next line of that PDF document says: "However, the functions are backward compatible with the existing ATmega324 functions." Believe me, I've browsed datasheets up and down and could not find a single word

regarding this issue. Working with MCU's for 35+ years I always assume I am doing something wrong before blaming the hardware, but in this case it's not the issue of compatibility. I can't get external AREF working.

Internal references (1.1V and 2.56V and AVCC) work as supposed, but, again, when I select external reference input, it does not work. To me it looks like the pin is not routed to REF input of ADC.

 

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

What are you using for your external reference voltage?  Schematic please.

 

Jim

 

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

What device/voltage are you using for the external AREF?

 

Edit: and Midwest Jim beats me to it...

David (aka frog_jr)

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

Schematic is here, but it won't help you. The same board works fine with ATmega324P. With ATMega324PB - all I can read back is 0x3FF.

It would really help if somebody uses the same device and can verify/deny this issue.

Attachment(s): 

Last Edited: Wed. Jan 10, 2018 - 02:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just as a sanity check, what V do yu read right on the AREF pin during these tests?

 

I don't see any errata that directly addresses your symptoms.  Still, it might be good to see a code snippet (or full test program) that exercises the symptoms. [I'm thinking of the differential erratum]

 

If you select e.g. AVcc as reference, do you get reasonable conversion results?  what about with internal reference(s)?

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

No need to tie AVCC to AREF, in fact it can cause internal damage if one of the internal REF's is selected. 

Just connect the 100nf cap to AREF, if you need (want) to use AVCC as ref, it can be selected in ADMUX.

 

Jim

 

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

How exactly will this help in my case? I am familiar with that, but please note that the attached schematic IS NOT actual schematics (can't post it due to project sensitivity).

I have an external reference source (derived from VCCA)  and it's value is equal to VCCA or less. When performing the tests it was 4.95V (VCCA was 5.02V) with 1.2V on CH1

and 0.0V on the remaining 2 channels. When read, all three channels returned 0x3FF

 

Code snippet is here, but it won't help as it's pretty straigforward and ATMega's ADC is not that complicated.

 

Init:

 

ADCSR = 0x00; //disable adc
DIDR0 = 0x07; // disable ADC input pin digital I/O drivers
ADMUX = 0x0; //select adc input 0

ADCSR = 0xCE; // 250kHz ADC clock (~8Khz conversion rate), enable interrupts and start converesion

 

in ADC ISR:

 

switch (channel)
{
case 0:
ADMUX = 0x01;
break;

case 1:
ADMUX = 0x02;
break;

case 2:
ADMUX = 0x00;
break;

}
NewAdcSample = ADC;
ADCSR |= 0x50; // clear interrupt flag and start new conversion

 

 

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

I've mentioned in my previous posts that only external AREF does not work as supposed. Selecting AVCC, 1.1 or 2.56 returns meaningful results.

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

ddurdeni wrote:
but please note that the attached schematic IS NOT actual schematics (can't post it due to project sensitivity).

???  Then how do you expect us to examine your setup, to try to come up with ideas?

 

I understand about perhaps the full schematic.  But surely the snippet showing AREF connection will not give away the farm.

 

ddurdeni wrote:
ADCSR |= 0x50; // clear interrupt flag and start new conversion

If you are in the ISR, why do you think you need to clear the flag?

 

Do you always just use magic numbers and not bit names? 

 

It would help if the snippet was more complete.  E.g. how is "channel" declared?   If a switch is used as shown, I'd like to see a default case. 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

The problem with schematics is that AREF voltage comes from another sheet, from another circuitry. Anyhow, why do you think it is important since:

1 - ATMega324P works on the same board

2 - AVREF = 4.95V AVCC=5.02V (so how it's actually generated does not matter)

 

Regarding ISR - your're right regarding clearing int. flag, although it does not matter anyway. Again it's only a part showing ADC register access - it's not the actual code.

What EXACTLY is wrong with this code that will result in reading 0x3FF if external AVREF is selected and works correctly if AVCC or internal reference is used ? And again,

ATMega324P WORKS CORRECTLY - and if you compare datasheets for ADC, there's no obvious reason why ATMega324PB does not.

 

As I have only one ATMega324PB sample, I was asking if somebody can try it out and verify - as there might be (slight) chance that my sample is broken.

 

 

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

You ask for help, and it is pointed out that tying AREF to AVCC is not recommended as it can damage the MPU if other internal references are selected....

You then state the ADC works with these internal references selected, BS!  Not connected as shown!

Further more, you state what has been shown is not how the actual h/w is connected.....

 

So how is it we can help?

 

I'm out!

 

Jim

 

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

When I tested internal reference sources, I have disconnected external source, leaving only bypass cap.

Nitpicking about (at least in this case) irrelevant details is not very productive. I CAN'T post actual schematics on a public forum.  If you REALLY want to help, please try it out on an actual ATMega324PB

for yourself - it's just a few lines of code. Once again - I might have got a faulty sample, but can't verify it as I have only one. Others are on the way, but I thought that somebody here can confirm/deny

my findings on his/her hardware as it would take a few days until I get new samples.

Last Edited: Wed. Jan 10, 2018 - 04:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You probably have already noticed that the ADC Control and Status Register B is slightly different between the two devices and is configured differently on reset.

 

ATmega324PA:

 

ATmega324PB:

 

Edit: Hmmm, I now see that ADCSRB bit 6 was changed to ACME in the migration to the Microchip version of the PB datasheet...

Edit2: clarification

Edit3: Very curious, iom324pb.h shows:

#define ADCSRB  _SFR_MEM8(0x7B)
#define ADTS0   0
#define ADTS1   1
#define ADTS2   2
#define ACME    6
#define GPIOEN  7

So, ... ???

David (aka frog_jr)

Last Edited: Wed. Jan 10, 2018 - 10:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now that's VERY interesting! Where did you download that datasheet from? The one I am using (DS40001908A from Jan/2017 - the latest on Microchip's site) does not show this?

Anyway, I will try it out, just to be sure. Thanks!

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

OK - you were on a right track! It's an undocumented bit in ADCSRB -> GPIOEN is bit 7 in ADSCRB and it's set to 1 after reset. When I manually reset it to zero, everything works as supposed.

So, to summarize - ATMega324PB has a new control bit in ADCSRB.7 which is set by default and must be cleared in order to use PE4 as an AREF pin.

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

And that is the normal way (yes here they should write about it), at reset port pins will be enabled and set as input.

And then you steal them when you enable the HW that use them.

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

Just make sure that you know that the 324pb don't have high power crystal mode, and can't run it faster than 16MHz!

 

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

I got interesting response from Microchip - they said that AREF pin is automatically re-routed as an ADC reference as soon as ADC is enabled. Obviously, it is not - GPIO function must be EXPLICITLY disabled in ADCSRB !

 

 

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

And that would be stupid, because then the port pin could not be used if the adc ref was internal.

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

ddurdeni wrote:
Where did you download that datasheet from?
When I first ordered a 324PB Xplained board, I downloaded a datasheet dated 11/2015 (42546A). There are two Atmel data sheet revisions after that one (42546B & 42546C), and then the Microchip version of 01/2017 (DS40001908A).

 

Edit: I just found this data sheet from 03/2017 (DS40001892A) for the automotive device:

 

David (aka frog_jr)

Last Edited: Thu. Jan 11, 2018 - 02:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good digging, kids.  frog had to find the incidental reference.  Then

ddurdeni wrote:
GPIOEN is bit 7 in ADSCRB
...and I wondered where ACME went.

 

Setting that target in Studio7, the standard include has

#define ADCSRB  _SFR_MEM8(0x7B)
#define ADTS0   0
#define ADTS1   1
#define ADTS2   2
#define ACME    6
#define GPIOEN  7

It gets even more interesting... ddurdeni, have you told which chip revision you are using?

 

-- Note the revision history for the Microchip datasheet says that the ADCSRB description is changed:

-- ... so perhaps later chip revisions do not have the feature, and the datashet was updated to reflect operation of the current chip revision?

-- Note that the listed errata from early chip versions has disappeared.  "Nothing to see here; move along..."

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I see that the microchip version have removed fig 8.2 that show that registers are placed in addr 0x00-0x1F

 

I don't know if it's an error, or they want to streamline with the newer chips that don't have this feature.

 

 

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

I'm not at the compiler, but what does the simulator do? (it should be based on the chip, and if there are are two different pb chips there should also be two different simulator settings.  )

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

sparrow2 wrote:
if there are are two different pb chips there should also be two different simulator settings.

???  In all the years of AVR/Atmel Studio, have you ever seen a simulator target selection based on chip revision?  I cannot recall any.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I wondered where ACME went.

Ask Wylie Coyote, he shops there all the time.

 

Image result for wylie coyote acme

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Chip markings say ATmega324PB-20AU and datecode is 1742S - not sure if that clears anything. It looks as a simple datasheet error to me...

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

No but I don't recall a chip with the same name not be a replacement of the old one ! (it should really have had an other number)