Support of ATmega324PB in avr-gcc

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

 

 Any news or ideas on the topic? Just bought 324PB Xplained Pro and all of a sudden found out that I can't even compile for it.

 Toolchain I have is 3.5.3, no mention of 324PB in headers and device specs. Release notes for the latest gcc toolchain (3.5.4) at

 

http://ww1.microchip.com/downloa...

 

 list only 324A, P and PA

 Is it the same with the Studio? I can't use it, just curious.

 

 Thanks

 

 PS

 Not sure if this belongs here or in Compilers. Please, feel free to move.

 

 

This topic has a solution.
Last Edited: Thu. Dec 28, 2017 - 06:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yabusame wrote:
all of a sudden found out that I can't even compile for it

Please explain that.

 

You mean you have previously been able to "compile for it", but now can't?

 

What, exactly, are you doing?

What, exactly, is happening?

Any error messages?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

 Sorry for not being perfectly clear. This is my first 324PB so I haven't been able to compile for it before.

 

 Here is what happened:

 

avr-gcc -Wall -pedantic -O3 -pipe -mmcu=atmega324pb -DBLI_APP_VERSION=\"0.2\" -I. bli.c -c -o bli.o
avr-gcc: error: cannot access device-specs for 'atmega324pb'

 

 

 

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

Well,  AS7 knows all about the ATmega324PB.

 

However there are a few changes in the header files compared to the ATmega324PA.

e.g. bit names in multiple peripherals like USART0, USART1 are now called RXC instead of RXC0, RXC1

and single peripheral SFR names like TWCR are now called TWCR0, TWCR1 because there are two TWI channels in the 324PB.

 

You will need to do a certain amount of conditional editing.   e.g. #if ..324PB.. #define TWCR TWCR0

 

There have been similar name conflicts in the past.  e.g. with RXC RXC0

The new system is more logical.  i.e. single bit name because RXC0, RXC1 are both in the same position in UCSR0A and UCSR1A

 

David.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yabusame wrote:
avr-gcc: error: cannot access device-specs for 'atmega324pb'
http://packs.download.atmel.com/#collapse-Atmel-ATmega-DFP-pdsc

via

http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.6.1/avr8-gnu-toolchain-readme.pdf

(page 8)

4. Supported Devices

 

P.S.

0-series megaAVR?

Some new megaAVR in the works.

 

 

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

Last Edited: Wed. Dec 27, 2017 - 03:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

 gchapman,

 

 Thanks, atpack worked. Do you know if avrdude part definition of 324pb can be derived from 324p by simply changing signature to 0x1e 0x95 0x17?

 

 

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

You're welcome.

Yabusame wrote:
Do you know if avrdude part definition of 324pb can be ...
Don't know (won't have mega324PB until Jan '18)

 

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

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

Yabusame wrote:
... 324pb can be derived from 324p by simply changing signature to 0x1e 0x95 0x17?
An assumption is like the change for mega328PB.

http://svn.savannah.gnu.org/viewvc/avrdude/trunk/avrdude/avrdude.conf.in?r1=1391&r2=1397

 

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

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

gchapman wrote:

Yabusame wrote:
... 324pb can be derived from 324p by simply changing signature to 0x1e 0x95 0x17?
An assumption is like the change for mega328PB.

http://svn.savannah.gnu.org/viewvc/avrdude/trunk/avrdude/avrdude.conf.in?r1=1391&r2=1397

 

 

 That's what I did. I can flash the chip and change fuses.

 However, Atmel's migration guide 324->324PB says `ATmega324PB is not a drop-in replacement for ATmega324 variants, but a new device.' So 324PB may require more profound changes. We'll see.

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

 It works.

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

Someone can give me some instructions to do this on debian? I downloaded the patch and included it on avr-gcc command but did not work. I did the process below and didnt have results.

 

Yabusame wrote:

gchapman wrote:

Yabusame wrote:
... 324pb can be derived from 324p by simply changing signature to 0x1e 0x95 0x17?
An assumption is like the change for mega328PB.

http://svn.savannah.gnu.org/viewvc/avrdude/trunk/avrdude/avrdude.conf.in?r1=1391&r2=1397

 

 

 That's what I did. I can flash the chip and change fuses.

 However, Atmel's migration guide 324->324PB says `ATmega324PB is not a drop-in replacement for ATmega324 variants, but a new device.' So 324PB may require more profound changes. We'll see.

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

Google "Atmel toolchain linux". Download the .tar.gz, unpack it. Job done.

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

3.6.1 has made the home page (was 3.5.4) for macOS and Linux; Windows is still at 3.5.4 there :

Microchip Technology Inc

Microchip Technology

'SAM(ARM) and AVR Toolchains (C Compiler)

http://www.microchip.com/avr-support/avr-and-arm-toolchains-(c-compilers)

source code and macOS build :

Atmel - Tools Distribution

http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.6.1/

 

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

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

rcmurakami wrote:
Someone can give me some instructions to do this on debian?
Microchip AVR GCC 3.6.0 (current is 3.6.1) is a part of recent Debian gcc-avr packages.

mega324PB is not in the forthcoming AVRDUDE 6.4 avrdude .conf so patch it.

https://packages.debian.org/search?keywords=gcc-avr&searchon=names&suite=all&section=all

http://svn.savannah.gnu.org/viewvc/avrdude/trunk/avrdude/avrdude.conf.in?revision=1422&view=markup

 

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

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

To patch it, I need to download and add the directory in the avr-gcc call? Just it? Because still not working for me...

Last Edited: Mon. May 7, 2018 - 08:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried on Ubuntu and works fine, but on Debian still not working, any advice to solve this?

 

I did the patch download and modify avrdude.conf. Its work on Ubuntu but not in my Debian. It still dont recognize the atmega324pb. Looks like the avr-gcc is ignoring the path where is the patch...

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

rcmurakami wrote:
... any advice to solve this?
None from me (I'm at a loss for ideas on this)

 

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

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

This is a thread where someone had the same problem with a different uC. And I've posted additional information regarding the ATmega328PB (had the same problem a few weeks ago). I'm using Ubuntu by the way.

Max

Edit: Forgot the link: https://www.avrfreaks.net/forum/iom324pbh-not-latest-avr8-gnu-toolchain-linux?skey=theeye13

Regards Max

Last Edited: Tue. May 8, 2018 - 12:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I admit I feel a bit lost.

I am using the ATmega324PB xplained pro board and I am constantly running into issues.

My experience with development environments is a bit rusty, to say the least. 

 

The code example attached I have seen run on MPLAB X IDE in a youtube video yet I am having difficulty with following.

 

The compiler does not seem to like 

 

void USART_Flush( void )
{
    unsigned char dummy;
    while ( UCSR0A & (1<<RXC) ) dummy = UDR0;
}

 

If I removed it and run without it compiles but when I open "Simple Serial Port Terminal" and try to send a text nothing returns.

Attachment(s): 

DViking

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

it's a warning

 

You don't use dummy for anything. Either make it volatile or actually use it :)

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

Soren1974 wrote:
when I open "Simple Serial Port Terminal" and try to send a text nothing returns.

The "terminal" in AS7 was an interns project that should have never been included with the suite, suggest you use a real terminal program!

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

Lets go Brandon!

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

So, two thing :)

I am not a super experienced....yet. I do see what you are saying about dummy. It was a copied example to clear the buffer. Apparently I did pay attention to the fact that it is going nowhere. ;)

 

In regards to the Terminal program. I tried YAT which I have used for quite a while but it does not return anything either. 

It connects okay thought.

DViking

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

Is there another suggestion for clearing the rx buffer?

DViking

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

Soren1974 wrote:
Is there another suggestion for clearing the rx buffer?

does it need clearing?

 

I usually have two functions for serial input:

//------RS232-------------------
unsigned char kbhit(void){
//return nonzero if char waiting  polled version
unsigned char b;

  b=0;
  if(UCSRA & (1<<RXC)) b=1;
  return b;
}

//-----------------------
int getchar(void){
//polled version... 
unsigned char c;

  while(!kbhit()){}; //wait for char
  c=UDR;             //get char from usart
  return c;  
}

to clear the buffer, test for data using kbhit() and if true, then call getchar() and ignore the result, rinse and repeat if longer then one char buffer.

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

Lets go Brandon!

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

Just disable, and then re-enable the receiver...

 

Quote:

23.3.2.4.2 Disabling the Receiver
When disabling the receiver, the operation is immediate. The receiver buffer will be flushed, and data from ongoing
receptions will be lost.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

My program still is not working with a terminal??

I am not getting any compiler errors. 

I am obviously communicating with the board as it programs okay.

 

It would be great with some help on that. Ideas, thoughts.

 

DViking

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

Soren1974 wrote:

My program still is not working with a terminal??

 

How are you connecting the terminal program to the output of your AVR?

 

Are you sure you are connecting to the right COM port?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Common problems with serial comms:

1) cpu is not running at the clock speed you think it is, so the baud rate is also not what you think it is. (CLK/8 fuse is default so clock is 1/8 what you think it is)!

2) TX on AVR connects to RX on USB-ttl serial adapter, and RX on AVR connects to TX on USB-ttl serial adapter.

3) Using a USB to RS232 adapter, rather then a USB to ttl serial adapter.

4) Not having a common GND connection between AVR and USB-ttl adapter.

5) Using the internal RC osc (@ 1MHz) and trying to use 9600 baud! (error rate is TOO large, use 4800 baud), but best to use xtal with much better accuracy than the internal RC osc.

 

I'm sure there are more but see if that list will solve your issue.

 

Jim

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

Lets go Brandon!

Last Edited: Fri. May 8, 2020 - 06:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
does it need clearing?

Sometimes, with double-buffered (or deeper), it is nice to [say] clear the internal circular buffer and UART buffer(s).

 

Soren1974 wrote:
Is there another suggestion for clearing the rx buffer?

If you want to clear the warning with a replacement line for dummy=UDR0; you can just use UDR0;

 

 

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

Thank you Jim

DViking

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

theusch wrote:
Sometimes, with double-buffered (or deeper), it is nice to [say] clear the internal circular buffer and UART buffer(s).

Hmm, I would just read what is in the buffer and let the input parser state machine discard if not needed.

 

Brian Fairchild wrote:
Just disable, and then re-enable the receiver...

That could lose an incoming character, I would rather process what is in the buffer and discard if not needed.

 

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

Lets go Brandon!

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

If only I had an Oscilloscope.

You were right about the 1 M clk. I modified it but I am still not getting any USART action. 

When I run in debug mode I can see all the registers being configured as i would expect but the RXC never go high nor do I see and action on UDR0.

 

DViking

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

You still haven't answered my questions back in #27.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

The answer to your question is 

 

The board I am using is a ATmega324PB Xplained Pro with a built-in EDBG Debugger which connects on COM8 virtual through USB.

My Terminal program YAT detects and connects via COM8.

 

Running in debugging mode I execute the code and watch the register values. They all change according to the program until it gets to the Receive while loop that is looking for a logic high on RXC to continue. 

Here is gets stuck.

I looked at the Set Configuration Bit's

SUT_CKSEL = INTRCOSC_8MHZ_6CK_14CK_65MS

Int. RC Osc. 8 MHz; Start-up time PWRDWN/RESET: 6 CK/14 CK +64ms

CKDIV8 = SET

Divide clock by 8 internally

 

Also, when I run the code I get the following message.

"Configuration memory will not be programmed because no configuration bits settings have been defined in your code. 
To program configuration memory, either define the settings in your code or use the Program Configuration Bits button on the configuration memory window."

 

 

DViking

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

I try changing the Configuration Bit's to 16 M or what I believe is 16 M.

 

Attachment(s): 

DViking

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

Is there an LED on the board? Can you write a small program to turn the led on, delay 500ms, turn it off, delay another 500ms, and then loop continuously.

So the led will blink at 1Hz. And then we really know what speed you are running at.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Soren1974 wrote:

If only I had an Oscilloscope.

You were right about the 1 M clk. I modified it but I am still not getting any USART action. 

When I run in debug mode I can see all the registers being configured as i would expect but the RXC never go high nor do I see and action on UDR0.

You don't need any sophisticated equipment.

Blink an LED at 1Hz to verify the F_CPU is what you thought it was.

You can even measure the accuracy of a nominal RC clock.   e.g. count 100 blinks against your wristwatch.   gives 1% accuracy.   200 gives 0.5% accuracy.

 

You already have an onboard debugger on your XPRO board.

Buy a $8 Logic Analyser  from China.   (or $12 locally).   This will give accurate timing and decode USART, SPI, I2C, ...

 

David.

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

I verified the clock and it is blinking at 1Hz.

 

I know I have mentioned this before but this is where it gets stuck.

 

unsigned char USART_Receive(void)
{
   
while ( !(UCSR0A & (1<<RXC)) );
    return UDR0;    

}

DViking

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


Soren1974 wrote:

unsigned char USART_Receive(void)

{

   
while ( !(UCSR0A & (1<<RXC)) );
    return UDR0;    

}

 

The virtual COM port connect to USART1 not USART0...

 

 

...and you should also be aware of this...

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Ah,

I will make adjustments.

 

DViking

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

Thank you for alerting me to this error. I think I got blindsided.

My Serial loopback is working perfectly now.

 

Thank you all for helping. 

 

Soren

DViking