iom324pb.h, not in latest avr8-gnu-toolchain for linux

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

Hi

 

After loooong pause from AVRs I wanted to use atMega324PB in a design but the latest avr8 gnu toolchain does not have the iom file for it. iom324pb.h

I downloaded avr8-gnu-toolchain-3.5.4.1709-linux.any.x86_64 from MicroChip today but it was not included, only the iom324pa/p/a versions.

Is it available somewhere else?

 

I build on Linux only so I do not have (or want) avrstudio so I cant find that file in its subfolders.

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

The note on http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.6.1/ explains how to add devices to avr-gcc

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

Hmm this made me curious Morten..

Who is distribute.atmel.no/tools now that Microchip has acquired Atmel? I see the tools here are newer than the one provided at microchip. 

And Microchip does not referee to this site...

 

And Morten, do you really still work for Atmel as your signature kinda indicates when Atmel has become part of MC ? ;)

 

 

 

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

.no is Norway, that is specifically Trondheim - so you might call it "straight from the horses's mouth". It often gives you an "early look" at what Morten and the lads are going to be delivering later by the "official" (now Microchip) delivery route.

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

I kinda know its norway, I live in Norway myself so...  I was just curious since I thought there where no Atmel left after MC bought them.

But its nice to know that the team is still alive and kicking in Trondheim as good old horses should do.

 

However, regarding the -B option, what more information is provided in the DFP device folder for a given device, i.e. atmega324pb, which is not found in the iom324pb.h file?
Would a build without this information, where one only link to the iom header file,  fail? Is it startup file information etc. that is found here? I tried to read the ar archive but the file-format was not recognized.

 

 

 

 

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

It's a zip-file, just use unzip.

$ file Atmel.ATtiny_DFP.1.3.169.atpack    
Atmel.ATtiny_DFP.1.3.169.atpack: Zip archive data, at least v1.0 to extract
$ 
$ unzip -l Atmel.ATtiny_DFP.1.3.169.atpack | head
Archive:  Atmel.ATtiny_DFP.1.3.169.atpack
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2017-12-18 10:44   atdf/
        0  2017-12-18 10:43   avrasm/
        0  2017-12-18 10:44   avrasm/inc/
        0  2017-12-18 10:43   avrasm/templates/
        0  2017-12-18 10:44   edc/
        0  2017-12-18 10:43   gcc/
        0  2017-12-18 10:44   gcc/dev/

 

 

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

eeehm, yes, sorry for beeing unclear.

 

atpack is ofcourse a zip file but the avr5 folder found in gcc/dev/atmega324pb/ contains a file with an .a extension which is an arch file . Using AR wont open it though so I wonder what filetype this really is???

 

Heres a snippet of the file libatmega324pb.a

As you may see there is many files in this archive and I just wanted to see its content

!<arch>
/               1513587781  0     0     0       408       `
         €      €  Ä  $  $  ”  #Ø  +  +  2`  2`  9`  ?Ì  F„  F„  M|  M|  T(eeprom_read_block eeprom_read_blraw eeprom_read_byte eeprom_read_dword eeprom_read_float eeprom_read_word eeprom_update_block eeprom_update_byte eeprom_update_r18 eeprom_update_dword eeprom_update_float eeprom_update_word eeprom_write_block eeprom_write_byte eeprom_write_r18 eeprom_write_dword eeprom_write_float eeprom_write_word //                                              20        `
eewr_block_xmega.o/
/0              1513587683  1002  1002  100664  1816      `
ELF          S      

 

*************** And so on

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

Last Edited: Mon. Apr 9, 2018 - 09:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And by "see it's content" you mean?

$ ar t libatmega324pb.a
eewr_block_xmega.o
eerd_block.o
eerd_byte.o
eerd_dword.o
eerd_word.o
eeupd_block.o
eeupd_byte.o
eeupd_dword.o
eeupd_word.o
eewr_block.o
eewr_byte.o
eewr_dword.o
eewr_word.o
ccp_write.o
$ 
$ 
$ avr-objdump -d libatmega324pb.a | head -20 ; echo ...
In archive libatmega324pb.a:

eewr_block_xmega.o:     file format elf32-avr


eerd_block.o:     file format elf32-avr


Disassembly of section .text.avr-libc:

00000000 <eeprom_read_block>:
   0:	dc 01       	movw	r26, r24
   2:	cb 01       	movw	r24, r22

00000004 <eeprom_read_blraw>:
   4:	fc 01       	movw	r30, r24
   6:	f9 99       	sbic	0x1f, 1	; 31
   8:	00 c0       	rjmp	.+0      	; 0xa <eeprom_read_blraw+0x6>
   a:	00 c0       	rjmp	.+0      	; 0xc <eeprom_read_blraw+0x8>
   c:	f2 bd       	out	0x22, r31	; 34
...

 

 

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

quote "And by "see it's content" you mean?"

Yes, I do.

 

I do not know why the archive did not extract when I issued "ar x <archive>" earlier, but now it does. Murphy's law I guess.
 

Thanks. Just wanted to know its content to better understand the avr build system, See that except for ccp_write (empty) the archive contains eeprom subroutines.

But what is the purpose of crt<device>.o file? Contains a lot of .debug functionalities i see but have no clue for the usage of it.

 

In my build i used the -B option to add the device specific info as mentioned at distribute.atmel and i set mmcu to atmega324pb and the build whent trrue perfectlyu, but avr-gcc still reported unknown device.
Is this as expected? Not that I care to much, the build went true but still like to ask.

 

Creating Extended Listing: Z044.lss
avr-objdump -h -S -z Z044.elf > Z044.lss
Creating Symbol Table: Z044.sym
avr-nm -n Z044.elf > Z044.sym
Size after:
AVR Memory Usage
----------------
Device: Unknown
Program:    1246 bytes
(.text + .data + .bootloader)
Data:         48 bytes
(.data + .bss + .noinit)
-------- end --------
Process terminated with status 0 (0 minute(s), 3 second(s))

 

 

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

Last Edited: Wed. Apr 11, 2018 - 05:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

That's avr-size (not avr-gcc) that doesn't know the device, but it doesn't really matter (IMO).

 

The crt... is "C Runtime" something. It's the interrupt vector and some code to be run before main is entered.

 

You can use "avr-objdump -d" on it to get a disassembly  of it's content.

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

I'd the same problem using an ATmega328PB last weekend (first time working with microcontrollers after a while). This project log showed me the way https://hackaday.io/project/9313-uino-mini-super-atmega328pb/log/31003-easy-way-to-a-toolchain-for-the-atmega328pb (I've ignored the Arduino stuff).

In my opinion your build looks good. Why don't you test it with a microcontroller?

Regards Max

Last Edited: Wed. Apr 11, 2018 - 05:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

... Because I have no microcontroller yet in my pocket ;)  Have started the sw project though and are assembling the HW these days, so some time in a future not to distant

Thanks for the link.

 

 

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

Oh, sorry! I didn't think of that... I could flash a test program to a ATmega328PB next week if that would be of any help to you.

And please tell us after you've tried.

Regards Max

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

Hi, you wanted an update, took a while but you know, summertime is time for sailing, even though thats where my project will end up as an translator of NMEA data
But I am now debugging using Code::Blocks.  Two problems still, one beeing that CB does not support viewing peripheral registers, but thats a minor problem for the moment.

The only real problem is that the device does not switch to external xtal when debugging, thus running on incorrect clk. This is my next job to find out why.

Some times it seems that external clock does not start correctly if reprogrammed but not repowered, this happens both when debugging and when reprogramming
It  does instead start on default internal RC clock. Tried using longer startuptime for example 16kCK+4.1ms (lfuse=0xEF) or 0xFF for maximum startuptime +65ms. Or lower using 0xDE.

Using 22p capacitors. This may be on the limit to what it will accept. Still investigating...

 

Heres is how i use avrdude for the moment (note: Z044 is just my projects build output name)

PROGRAMMING
avrdude -P usb -c jtag2 -patmega324pb -e -Uflash:w:Z044.elf
(-P usb might be omitted)

 

PROGRAMMING FUSES
http://eleccelerator.com/fusecal...

lfuse  : 0xFE --> Ext.Xtal 1kCK +4.1ms, >8MHz
hfuse : 0x1B --> OCDEN, JTAGEN, SPIEN, BOOTSZ1  (use 0x3B to turn off SPIEN)
efuse : 0xFC --> BOD level 4V3
lock   : 0xFF --> No lock

 

avrdude -c jtag2 -P usb -B 100kHz -p atmega324pb     -U lfuse:w:0xFE:m     -U hfuse:w:0x1B:m     -U efuse:w:0xFC:m     -U lock:w:0xFF:m

 

Heres is the settings I use within CB (note: Z044 is just my projects build output name)

CB and the project must be set up to use the correct debugger, avr-gdb.
AVR debugger setting is created in menu Settings and Debugger, and then activated in menu Debug and Active Debuggers

 

Then the project settings must be changed

 

Project settings for debug

Target (Project)
Remote Connection:
Connection type: TCP
IP Address: localhost
Port: 4242

 

Aditional GDB commands:
Before Connection:
shell avrdude -P usb -B 500kHz -c jtag2 -patmega324pb -e -Uflash:w:Z044.hex
shell sleep 2
shell /opt/avarice/bin/kill-avarice
shell /opt/avarice/bin/avarice --part atmega16 --mkII --jtag-bitrate 500kHz --jtag usb :4242 &

 

After Connection:
file Z044.elf
b main

Aditional SHELL commands:
none

 

NOTE: avarice do not recognize atmega324pb, using atmega16 instead
Which problems this may cause I do not know, but for now, connection has been very stable.

Has nothing to do with clock startup i believe

 

You may also be interested in this thread

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

 

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

Last Edited: Tue. Jun 5, 2018 - 08:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

zainka wrote:
Using 22p capacitors. This may be on the limit to what it will accept. Still investigating...
Might consider a resonator instead of a crystal as resonators are on several mega328PB boards.

https://github.com/pololu/a-star/blob/master/boards.txt

via https://www.pololu.com/product/3161/resources

 

mega324PB Xplained Pro has a 16MHz crystal; am currently unable to locate its hardware file with a schematic.

 

22pF - might need to reduce that.

Abracon

Abracon Application Note 1025: 18pF Crystals May Not Oscillate with Energy Saving MCUs

https://abracon.com/news/abracon-release-app-note-1025

 


https://www.microchip.com/wwwproducts/en/ATmega324PB

 

Edit: Abracon

 

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

Last Edited: Tue. Jun 5, 2018 - 09:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Right.. suspected that this might be the case. However the datasheet gives capacitor range to be 12-22pF, but this is TOTAL capacitance. So therefor i wondered if i might had to reduce my value.

Then again, a capacitors printed value is the value measured under controlled environments and two 22pF might behave different to some extent. and the technology used like COG, X7R and so on gives quite some room for individual differences between different manufacturers.

 

Will reduce capacitance as next test.

 

Thanks for your input!

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

...; am currently unable to locate its hardware file with a schematic.

16MHz Crystal

Crystal datasheet (16MHz):

Load capacitance CL = 9pF

ESR 60 Ohm Max.

Frequency tolerance +/- 10 ppm

 

Ce = 2(CL - Ci - Cs) = 2 (9pF - 8.1pF) = 1.8pF

where:

Ce - is the external capacitance needed

CL - is the load capacitance specified by the crystal vendor

Ci - is the pin capacitance

Cs - is the total stray capacitance, assumed to be <1pF and can be ignored

 

Ce of 1.8pF was selected after measururing frequency, this gives an approximate combination of pin capacitance and stray capacitance of 8.1pF

refdes is XC200, C205 and C206

Epson TSX-3225 16.0000MF09Z-AC3

16MHz uXtal, 3.2 x 2.5 mm SMD, CL=9pF, 15PPM, ESR=80ohm(Max.

 

1.8pF

Ceramic capacitor, SMD 0402, NP0, 50V, +/-0.25pF

via https://www.microchip.com/DevelopmentTools/ProductDetails/ATMEGA324PB-XPRO

 


https://www.mouser.com/ProductDetail/Epson-Timing/TSX-3225-160000MF09Z-AC3?qs=sGAEpiMZZMsBj6bBr9Q9acukpafrIaZ1%2fpqCtYImzz0%3d

https://www.mouser.com/Epson/Crystals/TSX-3225-Series/_/N-1yzu7kvZ6zu9fZ1yzu64o

 

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

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

A small update, the change in capacitance does not change behaviour. The external clock starts everytime at 12MHz when running without debugger. However, when connecting to target with mkII and avarice (now using part atmega324p since pb variant not existing in avarice) the external clock does NOT start. Very strange.

 

Which commands could lead to this behaviour when attaching to target ?

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

am assuming it's 12MHz CLKO signal on PB1 (pin 41)

zainka wrote:
Which commands could lead to this behaviour when attaching to target ?
Don't know unless I connect a logic analyzer onto its JTAG.

OCD JTAG is proprietary (data sheet section 29.7); programming JTAG (Table 31-19. JTAG Programming Instruction Set) is documented.

 

 

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