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.
meolsen 
The note on http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.6.1/ explains how to add devices to avr-gcc
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 ? ;)
clawson 
.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.
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.
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/
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
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 ...
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))
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.
TheEYE13 
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?
... 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.
TheEYE13 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.
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 mainAditional 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/...
gchapman Using 22p capacitors. This may be on the limit to what it will accept. Still investigating...
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 Application Note 1025: 18pF Crystals May Not Oscillate with Energy Saving MCUs
https://www.microchip.com/wwwproducts/en/ATmega324PB
Edit: Abracon
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!
gchapman ...; 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/Epson/Crystals/TSX-3225-Series/_/N-1yzu7kvZ6zu9fZ1yzu64o
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 ?
gchapman am assuming it's 12MHz CLKO signal on PB1 (pin 41)
Which commands could lead to this behaviour when attaching to target ?
OCD JTAG is proprietary (data sheet section 29.7); programming JTAG (Table 31-19. JTAG Programming Instruction Set) is documented.
Summer vacation is over, time to debug, and the hours spent on sailing really helped.
I started off by monitoring the RESET signal, and voila, theres where the problem lays... well so I believe... When the debugger (jtagice mk2) attaches to target it should reset the target, it tries but reset level is never pulled low enough. Running at 5V the reset pin goes no lower than 3.5V, Thus somehow the target got confused and the ext.clk did not start properly leading to the CFD system to detecting a clock failure, I guess, reverting to internal RC. I have nothing else connected to the RESET pin other than the debugger, thus relying on the internal RESET PU to keep the reset pin high.
Now, how to solve this? Wondering if the jtagicemk2 is not working but also have to consider the RSTDISBL fuse. Section 13.4 in datasheet says that "The External Reset can be disabled by the RSTDISBL fuse.", but there is no RSTDISBL mentioned in the fuse section!!! Searching for RSTDISBL in the datasheet gives only one hit and this is in section 13.4. So, either section 13.4 is wrong, or the fuse section is wrong., (or I am wrong)
Second, not to be forgotten, I am having nSRST connected to the RESET pin. I thought this was the correct thing to do, but please correct me if wrong, I do not believe this to be the cause since, After all, I am able to connect to target and run the code, but with the wrong clock source.
jgmdesign 
Sounds right. How do you have Reset connected on your target board? I usually have a 10kmresistor connected to Reset and Vcc. This way the programmer/debugger can control the pin when connected, but the pin is pulled high when there is no connection. If you have the line tied direct to Vcc then you will not be able to pull the line low....and you are shorting out the power supply too.
And do NOT program RSTDSBL!
Jim
Hi
I could not program the RSTDSBL deliberately even if I wanted to, this because the datasheet does not show this fuse in the fuse setting. My consern was that what if this was programmed by an accident, since it is not mentioned in fuse section, Then the pin now was a IO pin and what if it was set as output, then problems arise. But it is just a concern. not something i know for sure has happend.
Second, I only rely on the internal pull up (PU) of the reset pin as shown in diagrams in the datasheet, I do not have any external pullups or anything else connected to the reset pin except for the jtagicemk2/debugger. However, the value is not given directly by the datasheet but should usually be very weak, like several decades of kilo-ohms. Section 33.5 fig 33-21 shows the PU current vs voltage applied to reset pin. when pulled low (0V) the reset PU resistor current will be app 138uA at VCC=5V, giving internal PU to be something like 36k. This should not be to hard to pull down by the debugger.
Since it is not doing so, my hottest guess is that the busdriver inside the debugger is not doing its job (MAX4712CUE actually SPST circuits!), or the reset pin itself might have issues.
Other options??
EDIT:
Have been measuring the reset line on the board to verify no shortcuts or bridges etc. Then I, without debugger connected, monitored the xtal freq while toggling the reset line between ground and open (i.e. the internal PU pulls the reset line high, which it does). The external clock did not stop when device was in reset. Is this normal operation? Have never looked at that before and just wondered...
xtal freq amplitude is about 300mVpp.
Also added an external PU to opt out things. No changes in behavior. Will get my hands on an atatmel ice tomorrow. See if thats helps.
