Can't find DIDR1 register in AT90USB162

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

I'm using an AT90USB162 and want to use the built-in comparator. The datasheet says that there is a
register "Digital Input Disable Registers (DIDR1)" to disable the digital input circuit for the two analog
input pins.

But DIDR1 isn't listed in the Register Summary in the datasheet and it is not defined in the
iousbxx2.h file in Studio5.

Does this register actually exist?
If so, how is it accessed?

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

It exists in the assembler include file

.equ	DIDR1	= 0x7f	; MEMORY MAPPED

edit ...but it doesn't in the datasheet as you already know. :roll:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Thanks JS.
That gives me an address to try.

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

Quote:

Studio5.

Studio 5 is full of holes and bugs. Upgrade to AS6 where Atmel finally appear to have got the plot.

EDIT: nope AS6 is no better:

C:\Program Files\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.0.65\AVRToolchain\avr\include\avr>grep DIDR1 *.h |
rep u
iom128rfa1.h:struct __reg_DIDR1 {
iom128rfa1.h:#define DIDR1_struct _SFR_MEM8_STRUCT(0x7f, struct __reg_DIDR1)
iom169.h:/* NOTE: DIDR0 and DIDR1 are swapped in the register summary of the data sheet
iom16u2.h:#define DIDR1 _SFR_MEM8(0x7F)
iom16u4.h:#define DIDR1 _SFR_MEM8(0x7F)
iom32u2.h:#define DIDR1 _SFR_MEM8(0x7F)
iom32u4.h:#define DIDR1 _SFR_MEM8(0x7F)
iom32u6.h:#define DIDR1 _SFR_MEM8(0x7F)
iom8u2.h:#define DIDR1 _SFR_MEM8(0x7F)
iousbxx6_7.h:#define DIDR1   _SFR_MEM8(0x7F)

However:

C:\Program Files\Atmel\Atmel Studio 6.0\devices>grep DIDR1 *.xml | grep USB
AT90USB1286.xml:        
AT90USB1287.xml:        
AT90USB162.xml:        
AT90USB646.xml:        
AT90USB647.xml:        
AT90USB82.xml:        

So this looks like a bug in Atmel's AVR-LibC for AS6. But also missing in the open copy of AVR-LibC too:

http://svn.savannah.nongnu.org/v...

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

I think the at90can32 datasheet has it, if that helps.

Imagecraft compiler user

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

Quote:
Studio 5 is full of holes and bugs
So seems to be the datasheet (7707C–AVR–12/07) as addresses 0x70-0x7F (supposedly DIDR1) are reserved addresses. :roll:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Yes, something's inconsistent; the datasheet mentions it in text, but not in the register summary. The XML files are supposed to be the "canonical" source of device registers -- which is why I'm confused; they are used by Studio for the register I/O view and by avrlibc for automated device header file generation. Since the register is listed in the XML file according to Cliff, the definition should be in the device headers -- unless the device is too old to be of the auto-generated vintage.

Chuck - can you file a bug with the avr-libc project to get the device header files updated please?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Yikes. A mistake in avrgcc breaks atmelstudio program development for certain avr processors? Get that Stallman guy on the phone and give him an earfull.

Imagecraft compiler user

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

Quote:

A mistake in avrgcc breaks atmelstudio program development for certain avr processors?

Actually it's an avr-libc problem not an avr-gcc problem. You can fix it by manually defining the register in your code until the library is patched upstream.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Quote:

Get that Stallman guy on the phone and give him an earfull.

That is just plain ignorant, Bob. An error specific to avr-gcc has nothing to do with what is at the remote "top" of the GCC hierarchy.

You may fight avr-gcc, but you will have to use reasonable arguments. Your comment above will be revealed by most people knowing just a wee bit about GCC and other GNU stuff as not standing on a solid foundation, it reveals you are commenting upon soething where you are ignorant and just makes you look like a bad looser.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

That would be a "bad loser". -1 point for spelling.

Imagecraft compiler user

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

abcminiuser wrote:
Chuck - can you file a bug with the avr-libc project to get the device header files updated please?

- Dean :twisted:


How do I do that?
I found the bug list:
http://www.nongnu.org/avr-libc/b...
but I don't see any way of posting a new bug.

Also, what version of avr-libc is used in Studio5?

Dean, if you'd like to just go ahead and post the bug, that would be fine with me.

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

Quote:

but I don't see any way of posting a new bug.


You need to be "authentificated". ;) https://www.avrfreaks.net/index.p...

Note that when I said I didn't know how to do that,

Quote:
Lame excuse for your laziness.

But I'm not a user of the toolchain. If I were I'd indeed probably dig through the registration process.

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

Quote:

Also, what version of avr-libc is used in Studio5?

I don't know about Studio5 but:

C:\Program Files\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.0.65\AVRToolchain\avr\include\avr>grep AVR_LIBC  ver
sion.h
#define __AVR_LIBC_VERSION_STRING__ "1.8.0"
#define __AVR_LIBC_VERSION__        10800UL
#define __AVR_LIBC_DATE_STRING__    "20111228"
#define __AVR_LIBC_DATE_            20111228UL
#define __AVR_LIBC_MAJOR__          1
#define __AVR_LIBC_MINOR__          8
#define __AVR_LIBC_REVISION__       0

As I say the fault (no DIDR1 usb162) is still existent at HEAD of AVR-LibC SVN so this would appear to be a fault throught all issues of AVR-LibC whether the privately engineered Atmel version or the open copy.

(unless the AVR-LibC engineers had "inside knowledge" and know some reason why the register should not be publicly revealed perhaps?)

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

Quote:

That would be a "bad loser". -1 point for spelling.

Yup, a recurring problem for me (and many others, both with and without having English as their first language). Lose and loose..

So, could you now clarify in what way Mr Stallman could be held responsible for a bug in avrlibc?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

I think atmel needs the whole avrgcc source on their own company computers so when they release atmel studio 6.1, everything has this week's date on it. The makefile for avr lib depends on the atmel xml files. When the team librarians do a build on atmel studio, the compiler and the lib get rebuilt with today's xml files. Aint that how its supposed to work?

Imagecraft compiler user

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

Yes, probably something like that.

And in that build of avrlibc (not "avr lib", -1 point for not getting the names of things which you speak about right). There obviously is a bug, and judging from what Dean writes above it is associated with the avrlibc build (rather than being a bug in Atmels XML part description files).

Still wondering where you fit Mr Stallman into this.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

I'm still wondering if DIDR1 actually exists on the chip??? Does the datasheet need to be fixed and not just something in the compiler?

edit according to my demo versions of CV and ICC7 it exists.

CV (2 files)

#define DIDR1 (*(unsigned char *) 0x7f)
.
.
.
/* DIDR1 -  */
#define    AIN0D           0       // AIN0 Digital Input Disable
#define    AIN1D           1       // AIN1 Digital Input Disable

ICC7.2

#define DIDR1	(*(volatile unsigned char *)0x7F)
#define  AIN1D    1
#define  AIN0D    0

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:

I'm still wondering if DIDR1 actually exists on the chip?

I guess all one could do is write a program that toggles the bits in DIDR1 every second (say) then monitor the supply current and see if there's any discernible difference when location 0x7F is being changed?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#define DIDR1 _SFR_MEM8(0x7F)

int main(void)
{
    while(1) {
        DIDR1 = 3;
        _delay_ms(2000);
        DIDR1 = 0;
        _delay_ms(2000);
    }
}

The supply current alternates between about 12.0 mA and 12.4 mA on a at90usb162@1MHz and 5V. It includes a constantly lit LED (power indicator).