.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.

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

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.

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)

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.

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 ?

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.

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

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

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.