Atmega8535 OK / Atmega328p FAIL

[rodmolina]

i have been testing my chances.. neither the atmega8535 and atmega328p works at 12,8Mhz code.
atmega8535 works at 12 and 16Mhz
atmega328p no successfull results even with same crystals

here is what i did:
always running at 3,3v
i simply took the mouse-hid project and just like it was, i compiled it and only changed the F_CPU and DEVICE on the MAKEFILE acording to the test being made.

fuses for atmega8535 CKSEL3/0
internal RC 0 1 0 0
external Xtal 1 1 1 1

fuses for atmega328p
internal RC 0 0 1 0
external Xtal 1 1 1 1

any comments would be great

[christian]

Just posted the reply in the other thread, hope that does not cause too much confusion... Here's a copy:

I have never tried one of the AVRs with P suffix. Maybe they need additional initialization? Or have other fuse values?

If you take the HID Mouse project and change F_CPU to 12.8 MHz, it won't work. You must also add some kind of oscillator calibration and change the fuse values so that the internal RC oscillator is used without 1/8 divider. If you have a crystal, start with that and add the other features one after the other.

[rodmolina]

i thought thats the way it works.. i assumed the osc calibrations were made automatically as the module for 12,8mhz was loaded, if i port D+ to INT0 the osc tune was made at every usb bus reset and if i port D- to INT0 then the osc tune was made at every packet..

so how should i do to have an 12,8mhz tunned avr with v-usb working?

[christian]

have a look at the libs-device directory. It contains example code for calibration at connect time and for continuous tuning.

[rodmolina]

i made it work.. with a 12mhz crystal, both atmega8535 and atmega168V (yes, i know its only 10mhz but it worked fine) but i still cant make it work on atmega328p. i think there is a compatibility issue, because mega168 and mega328 are from the same family..
i know the mega328 is running because i run another project on it.. i have tried both hidmouse and bootloaderhid

i started looking at usbdrv.c but cant find anything wrong about configuration.. any ideas? or anyone who has tried out and made it work? so i can know if im looking for the problem in the wrong place

[christian]

The AVR code needs nothing else than an edge triggered interrupt. This is configured in usbInit() in usbdrv.c.

The "P" stands for pico-power. Maybe you must enable something in an I/O register to turn on edge triggered interrupts. Just an idea...

[rodmolina]

hi there! i made it work, but in order to make it work on a 328p i made some changes on the iom328p.h library file..i dont know why, i didnt checked the hole file but i seemed to be identically to iomx8.h general library file used by atmega48/88/168 (not pico) but, the PRR register is included anyway, thats weird..

so i simply force the iom328p.h to include the general i/o library iomx8.h and then i just configure specific stuff about the 328.. this is how any avr atmegaxxx8 works with winavr.. and it worked perfectly by now!

my original iom328p.h file version is:

Code: Select all

/* $Id: iom328p.h,v 1.3.2.14 2009/02/11 18:05:28 arcanum Exp $ */

here i post the iom328p.h.. if anyone finds the wrong thing on the original iom328p.h file, please post it:

Code: Select all

/* avr/iom328p.h - definitions for ATmega328P. */

/* This file should only be included from <avr/io.h>, never directly. */

#ifndef _AVR_IOM328P_H_
#define _AVR_IOM328P_H_ 1

#include <avr/iomx8.h>

#  define _VECTORS_SIZE 104

/* Constants */
#define SPM_PAGESIZE 128
#define RAMEND       0x8FF     /* Last On-Chip SRAM Location */
#define XRAMSIZE     0
#define XRAMEND      RAMEND
#define E2END        0x3FF
#define E2PAGESIZE   4
#define FLASHEND     0x7FFF



/* Fuses */
#define FUSE_MEMORY_SIZE 3

/* Low Fuse Byte */
#define FUSE_CKSEL0 (unsigned char)~_BV(0)  /* Select Clock Source */
#define FUSE_CKSEL1 (unsigned char)~_BV(1)  /* Select Clock Source */
#define FUSE_CKSEL2 (unsigned char)~_BV(2)  /* Select Clock Source */
#define FUSE_CKSEL3 (unsigned char)~_BV(3)  /* Select Clock Source */
#define FUSE_SUT0   (unsigned char)~_BV(4)  /* Select start-up time */
#define FUSE_SUT1   (unsigned char)~_BV(5)  /* Select start-up time */
#define FUSE_CKOUT  (unsigned char)~_BV(6)  /* Clock output */
#define FUSE_CKDIV8 (unsigned char)~_BV(7) /* Divide clock by 8 */
#define LFUSE_DEFAULT (FUSE_CKSEL0 & FUSE_CKSEL2 & FUSE_CKSEL3 & FUSE_SUT0 & FUSE_CKDIV8)

/* High Fuse Byte */
#define FUSE_BODLEVEL0 (unsigned char)~_BV(0)  /* Brown-out Detector trigger level */
#define FUSE_BODLEVEL1 (unsigned char)~_BV(1)  /* Brown-out Detector trigger level */
#define FUSE_BODLEVEL2 (unsigned char)~_BV(2)  /* Brown-out Detector trigger level */
#define FUSE_EESAVE    (unsigned char)~_BV(3)  /* EEPROM memory is preserved through chip erase */
#define FUSE_WDTON     (unsigned char)~_BV(4)  /* Watchdog Timer Always On */
#define FUSE_SPIEN     (unsigned char)~_BV(5)  /* Enable Serial programming and Data Downloading */
#define FUSE_DWEN      (unsigned char)~_BV(6)  /* debugWIRE Enable */
#define FUSE_RSTDISBL  (unsigned char)~_BV(7)  /* External reset disable */
#define HFUSE_DEFAULT (FUSE_SPIEN)

/* Extended Fuse Byte */
#define FUSE_BOOTRST (unsigned char)~_BV(0)
#define FUSE_BOOTSZ0 (unsigned char)~_BV(1)
#define FUSE_BOOTSZ1 (unsigned char)~_BV(2)
#define EFUSE_DEFAULT (FUSE_BOOTSZ0 & FUSE_BOOTSZ1)



/* Lock Bits */
#define __LOCK_BITS_EXIST
#define __BOOT_LOCK_BITS_0_EXIST
#define __BOOT_LOCK_BITS_1_EXIST 


/* Signature */
#define SIGNATURE_0 0x1E
#define SIGNATURE_1 0x95
#define SIGNATURE_2 0x0F


#endif  /* _AVR_IOM328P_H_ */

[christian]

If you can find the difference in the headers and why this causes a problem, please file a bug report for avr-libc!

But before you file a bug report, please make sure it's really a bug in the header, not a missing configuration on your side or something similar.

[gabebear]

It's really weird... I would expect to use iom328.h, but it doesn't exist and you can't just create it... anyone know why?

[rodmolina]

SOLVED POST: wrong fuses

the problem was i was using codevisionAVR to program the fuses but aparently it has wrong info about mega328P so the code was not starting at boot address..

i can use it now at 12MHz or 16MHz perfectly

Thank you all!

[objective]

What are the proper fuse bits to get the 328p working? I was able to get the HID-mouse example to work on the atmega168 @ 16MHz but when I make the code for the atmega328p @ 16MHz, I get this error code in my system.log file:

[0x7feef00] The IOUSBFamily was not able to enumerate a device.
[0x7feef00] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of hub @ location: 0xfd300000)

Is there anything else I need to change to adapt the code for the 328p? All I did was replace atmega168 with atmega328p in the Makefile.

Thank you in advance!

[objective]

I figured out how to get the code to run on the 328 and wanted to update this thread, in case anyone else was wondering.

I just compiled the code as if I were compiling for the 168. Then I just burned the .hex file normally as for the 328p... and it worked!

[julian.dasilva]

I found very problematic to compile for the "p" series. The problem seems not to be the 328, but the "p", because I have code with VUSB running compiled for a 168, and when try to compile for the 168p it does not work. And, because the only version of the 328 is the 328p, we cannot compile for the 328 and just use the 328p, so we have to compile for the 168 instead, and then force it into the 328p.

[DetlevT]

I also had some trouble to get the USBAsploader working on a ATMEGA328p although the code was working on an ATMEGA88 before.

I discovered that the cause is a change in the identifier of the INT0 vector. V-USB is using the outdated "SIG_INTERRUPT0" as default in usbdrvasm.S (Line 60) which is only supported by "old" headerfiles for "old" controllers. The headerfiles for the controller with a "p" only support the new identifier "INT0_vect". So the vector to the interrupt routine is not written into the vector table and unfortunately in this case you will not get any warning or error message.

Since I replaced the identifier in usbdrvasm.S the bootloader works.

[christian]

Thanks for this valuable info! I'll fix this for the next release.