ATMEGA328P on V-USB

[ulao]

Is this forum still being used?

Yes

Has this problem been solved?

Second to last post is quite clear.

Anyone know whats going on?

As to the problem, years its pretty clear to most of us now. Though its not just one issue.

These Confirmation codes will drive everybody away they are a pain in the arse . I can't read the rotten things!!!!
Taken me 5 minutes to try and read this rubbish

Why are you beating yourself up reading this old thread. Make a new thread ans ask your question. There are a lot of changes you need to make going from a atmeg8 project to a mega88/168. The 328 has a few more small bits of understanding that could be found in this thread. Just tells us what project you are working on and where you are having issues.

[Nitz76]

Hey guys!

I'm having a hard time with BOOTLOADHID on my atmega328p.

I've been able to build my main application using V-USB Release 2007-09-19 with slight modification (INT0_vect). My compiler is avrgcc 20100110.
I've downloaded the latest BOOTLOADHID from the site and modified it for atmega328p in the Makefile.

Makefile:

Code: Select all

DEVICE = atmega328p
BOOTLOADER_ADDRESS = 0x3800
F_CPU = 12000000

# FUSES: EXT: 0xFF  HIGH: 0xD8  LOW: 0xFF

bootloaderconfig.h:

Code: Select all

static inline void  bootLoaderInit(void)
{
    PORTB = 1 << 4; /* activate pull-up for key */
    _delay_us(10);  /* wait for levels to stabilize */
}

#define bootLoaderCondition()   ((PINB & (1 << 4)) == 0)   /* True if jumper is set */

#endif

Modified for my application.

When I trig the bootloader (PB4 to gnd), the USB is not responsive, as if nothing was connected. When I release it, it detects as an unknown device.

Everything was working fine with my atmega8 with same code.

Any idea?

Thanks!
Nitz

[Nitz76]

Update:

When I turn on TEST_MODE, put the bootloader origin to 0x0 and turn off the BOOTRST option in the fuse, it works...

Hummm... someting wrong with the bootflash mode and vectors...

Any suggestion?

Nitz

[vouvoume]

Hi.
If it might help you (or you just want to use tinyUSBboard in future): http://matrixstorm.com/avr/tinyusbboard/

I got it working with BootloadHID - no problems at all. ( http://matrixstorm.com/avr/tinyusbboard ... bootloader )
Althought the default bootloader is USBaspLoader, one of the boards features is to be able to exchange the bootloader. So you can exchnage USBaspLoader by BootloadHID.

All firmware are precompiled and xchangeable by each other.

BR vouvoume

[ulao]

Hi Nitz, I though you were not a fan of low speed devices? Either way welcome to the v-usb project ( one year late ).

I had this same issue I see you set the make/environment settings for 0x3c00 did you also match the fuses( not at a system that I can check that on right now ) and burn at the top of the memory? Are you on windows or inux?

fuses for my project are
with reset enabled FD:ex DA:hi DF:lo
with reset disabled FD:ex 5A:hi DF:lo

[Nitz76]

Hi Nitz, I though you were not a fan of low speed devices? Either way welcome to the v-usb project ( one year late ).

I had this same issue I see you set the make/environment settings for 0x3c00 did you also match the fuses( not at a system that I can check that on right now ) and burn at the top of the memory? Are you on windows or inux?

fuses for my project are
with reset enabled FD:ex DA:hi DF:lo
with reset disabled FD:ex 5A:hi DF:lo

Hey Ulao!
Actually, I'm a fan of V-USB.

My fuses are set to $3800. My bootloader address is 0x3800. As I said, it starts the bootloader because it detects my button. It's just hanging without dooing anything. When I release the button, my code is starting. It doesn't look like a vector issue... I'm confused.

[ulao]

For a 1024 word bootloader section on the 328p, the bootloader needs to be compiled such that it starts at $3C00, give it a try Also I was pretty certain BOOTSZ0 had to be unchecked. Are you migrating from a 168? I think it was $3800 for a 168 chip ( easy mistake ), also the 328 swapped BOOTSZ & BODLEVEL.

[Nitz76]

For a 1024 word bootloader section on the 328p, the bootloader needs to be compiled such that it starts at $3C00, give it a try Also I was pretty certain BOOTSZ0 had to be unchecked. Are you migrating from a 168? I think it was $3800 for a 168 chip ( easy mistake ), also the 328 swapped BOOTSZ & BODLEVEL.

Actually, I'm migrating from atmega8 to atmega328p. I'll try $3C00. I'm using AVR STUDIO with STK500 to program.

I just looked at the lss and it seems fine for the vectors:

Code: Select all

main.bin:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         0000000a  00800100  00003efc  00000790  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  1 .text         000006fc  00003800  00003800  00000094  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .bss          00000031  0080010a  0080010a  0000079a  2**0
                  ALLOC

Disassembly of section .text:

00003800 <__vectors>:
    3800:   71 c0          rjmp   .+226       ; 0x38e4 <__ctors_end>
    3802:   00 00          nop
    3804:   a4 c0          rjmp   .+328       ; 0x394e <__vector_1>
    3806:   00 00          nop
    3808:   88 c0          rjmp   .+272       ; 0x391a <__bad_interrupt>
    380a:   00 00          nop

Code: Select all

000038e4 <__ctors_end>:
    38e4:   11 24          eor   r1, r1
    38e6:   1f be          out   0x3f, r1   ; 63
    38e8:   cf ef          ldi   r28, 0xFF   ; 255
    38ea:   d8 e0          ldi   r29, 0x08   ; 8
    38ec:   de bf          out   0x3e, r29   ; 62

Code: Select all

0000394e <__vector_1>:
    394e:   cf 93          push   r28
    3950:   cf b7          in   r28, 0x3f   ; 63
    3952:   cf 93          push   r28

[ulao]

8 and 168 are very similar, its the 328 that make a few fuse swaps. Also the timers changed from 8 but I'm sure you discovered that if you use them during compile. Another unknown byte in the butt is the z-diode. They must be 1/2 watt but you passed enumeration so that not your troubles.

[Nitz76]

Table 28-6. Extended Fuse Byte for ATmega328/328P
Extended Fuse Byte Bit No Description Default Value
– 7 – 1
– 6 – 1
– 5 – 1
– 4 – 1
– 3 – 1
BODLEVEL2(1) 2 Brown-out Detector trigger level 1 (unprogrammed)
BODLEVEL1(1) 1 Brown-out Detector trigger level 1 (unprogrammed)
BODLEVEL0(1) 0 Brown-out Detector trigger level 1 (unprogrammed)

In my case 0xFF (no BOD).

Table 28-8. Fuse High Byte for ATmega328/328P
High Fuse Byte Bit No Description Default Value
RSTDISBL(1) 7 External Reset Disable 1 (unprogrammed)
DWEN 6 debugWIRE Enable 1 (unprogrammed)
SPIEN(2) 5
Enable Serial Program and
Data Downloading
0 (programmed, SPI
programming enabled)
WDTON(3) 4 Watchdog Timer Always On 1 (unprogrammed)
EESAVE 3
EEPROM memory is
preserved through the Chip
Erase
1 (unprogrammed), EEPROM
not reserved
BOOTSZ1 2
Select Boot Size
(see
Table 27-7 on page 292,
Table 27-10 on page 293 and
Table 27-13 on page 294
for details)
0 (programmed)(4)
BOOTSZ0 1
Select Boot Size
(see
Table 27-7 on page 292,
Table 27-10 on page 293 and
Table 27-13 on page 294
for details)
0 (programmed)(4)
BOOTRST 0 Select Reset Vector 1 (unprogrammed)

Table 27-13. Boot Size Configuration, ATmega328/328P
BOOTSZ1 BOOTSZ0 Boot Size Pages Application Flash Section Boot Loader Flash Section End Application Section
Boot Reset Address (Start Boot Loader Section)
1 1 256 words 4 0x0000 - 0x3EFF 0x3F00 - 0x3FFF 0x3EFF 0x3F00
1 0 512 words 8 0x0000 - 0x3DFF 0x3E00 - 0x3FFF 0x3DFF 0x3E00
0 1 1024 words 16 0x0000 - 0x3BFF 0x3C00 - 0x3FFF 0x3BFF 0x3C00
0 0 2048 words 32 0x0000 - 0x37FF 0x3800 - 0x3FFF 0x37FF 0x3800

In my case, 0xDA for boot at 0x3C00

Table 28-9. Fuse Low Byte
Low Fuse Byte Bit No Description Default Value
CKDIV8(4) 7 Divide clock by 8 0 (programmed)
CKOUT(3) 6 Clock output 1 (unprogrammed)
SUT1 5 Select start-up time 1 (unprogrammed)(1)
SUT0 4 Select start-up time 0 (programmed)(1)
CKSEL3 3 Select Clock source 0 (programmed)(2)
CKSEL2 2 Select Clock source 0 (programmed)(2)
CKSEL1 1 Select Clock source 1 (unprogrammed)(2)
CKSEL0 0 Select Clock source 0 (programmed)(2)

In my case, 0xFF for EXT XTAL 8.0MHz-16MHz, 16K CK, 14 CK, 65ms rise time.

No issue with my fuse.

The hardware has been sucessfully tested, as my main program works no problem (HID joystick), and the same program in test mode (0x0).

Must be something special that has to be done with the 328p to make the hidbootflash application to work in bootflash.

[ulao]

I use both 328 and P in my application. Boot loaders work with both. "In my case, 0xDA for boot at 0x3C00" So you tried setting both the fuse and the make to $3c00 and that did not work? Did you try writing FD:ex ( add SUT1 Select start-up time ) as a test. Also I must set a BOD to fd not ff but that cant be the issue as far as I can tell, however when I upgraded to avr 6 it disabled my brown out and I had a great deal of troubles. Once I set my brown out I was good to go.

"The hardware has been sucessfully tested, as my main program works no problem (HID joystick), and the same program in test mode (0x0)." This almost guarantees its a memory location issue. I have seen it many times. Or maybe its the Picopower and a brown out condition occurring?

[Nitz76]

Tried it with 0x3C00... Same deal

I'm pretty sure it's a memory location issue for... something. It's booting fine since trigging my button change the way it reacts.
The USB driver needs INT0 to work. I suspect the interrupt routine to not be called properly with this chip or there is a compiler error in AVRGCC.

Any toughts?

[Nitz76]

I'm seeing something pretty wierd... Interrupt vectors looks different for atmega8 and atmega328p;

atmega8:

Code: Select all

00001800 <__vectors>:
    1800:   50 c0          rjmp   .+160       ; 0x18a2 <__ctors_end>
    1802:   84 c0          rjmp   .+264       ; 0x190c <__vector_1>
    1804:   69 c0          rjmp   .+210       ; 0x18d8 <__bad_interrupt>
    1806:   68 c0          rjmp   .+208       ; 0x18d8 <__bad_interrupt>
    1808:   67 c0          rjmp   .+206       ; 0x18d8 <__bad_interrupt>
    180a:   66 c0          rjmp   .+204       ; 0x18d8 <__bad_interrupt>
    180c:   65 c0          rjmp   .+202       ; 0x18d8 <__bad_interrupt>
    180e:   64 c0          rjmp   .+200       ; 0x18d8 <__bad_interrupt>
    1810:   63 c0          rjmp   .+198       ; 0x18d8 <__bad_interrupt>
    1812:   62 c0          rjmp   .+196       ; 0x18d8 <__bad_interrupt>
    1814:   61 c0          rjmp   .+194       ; 0x18d8 <__bad_interrupt>
    1816:   60 c0          rjmp   .+192       ; 0x18d8 <__bad_interrupt>
    1818:   5f c0          rjmp   .+190       ; 0x18d8 <__bad_interrupt>
    181a:   5e c0          rjmp   .+188       ; 0x18d8 <__bad_interrupt>
    181c:   5d c0          rjmp   .+186       ; 0x18d8 <__bad_interrupt>
    181e:   5c c0          rjmp   .+184       ; 0x18d8 <__bad_interrupt>
    1820:   5b c0          rjmp   .+182       ; 0x18d8 <__bad_interrupt>
    1822:   5a c0          rjmp   .+180       ; 0x18d8 <__bad_interrupt>
    1824:   59 c0          rjmp   .+178       ; 0x18d8 <__bad_interrupt>

atmega328p:

Code: Select all

00003c00 <__vectors>:
    3c00:   71 c0          rjmp   .+226       ; 0x3ce4 <__ctors_end>
    3c02:   00 00          nop
    3c04:   a4 c0          rjmp   .+328       ; 0x3d4e <__vector_1>
    3c06:   00 00          nop
    3c08:   88 c0          rjmp   .+272       ; 0x3d1a <__bad_interrupt>
    3c0a:   00 00          nop
    3c0c:   86 c0          rjmp   .+268       ; 0x3d1a <__bad_interrupt>
    3c0e:   00 00          nop
    3c10:   84 c0          rjmp   .+264       ; 0x3d1a <__bad_interrupt>
    3c12:   00 00          nop
    3c14:   82 c0          rjmp   .+260       ; 0x3d1a <__bad_interrupt>
    3c16:   00 00          nop
    3c18:   80 c0          rjmp   .+256       ; 0x3d1a <__bad_interrupt>
    3c1a:   00 00          nop
    3c1c:   7e c0          rjmp   .+252       ; 0x3d1a <__bad_interrupt>
    3c1e:   00 00          nop
    3c20:   7c c0          rjmp   .+248       ; 0x3d1a <__bad_interrupt>
    3c22:   00 00          nop
    3c24:   7a c0          rjmp   .+244       ; 0x3d1a <__bad_interrupt>
    3c26:   00 00          nop
    3c28:   78 c0          rjmp   .+240       ; 0x3d1a <__bad_interrupt>
    3c2a:   00 00          nop
    3c2c:   76 c0          rjmp   .+236       ; 0x3d1a <__bad_interrupt>
    3c2e:   00 00          nop
    3c30:   74 c0          rjmp   .+232       ; 0x3d1a <__bad_interrupt>
    3c32:   00 00          nop
    3c34:   72 c0          rjmp   .+228       ; 0x3d1a <__bad_interrupt>
    3c36:   00 00          nop
    3c38:   70 c0          rjmp   .+224       ; 0x3d1a <__bad_interrupt>
    3c3a:   00 00          nop
    3c3c:   6e c0          rjmp   .+220       ; 0x3d1a <__bad_interrupt>
    3c3e:   00 00          nop
    3c40:   6c c0          rjmp   .+216       ; 0x3d1a <__bad_interrupt>
    3c42:   00 00          nop
    3c44:   6a c0          rjmp   .+212       ; 0x3d1a <__bad_interrupt>
    3c46:   00 00          nop
    3c48:   68 c0          rjmp   .+208       ; 0x3d1a <__bad_interrupt>
    3c4a:   00 00          nop
    3c4c:   66 c0          rjmp   .+204       ; 0x3d1a <__bad_interrupt>
    3c4e:   00 00          nop
    3c50:   64 c0          rjmp   .+200       ; 0x3d1a <__bad_interrupt>
    3c52:   00 00          nop
    3c54:   62 c0          rjmp   .+196       ; 0x3d1a <__bad_interrupt>
    3c56:   00 00          nop
    3c58:   60 c0          rjmp   .+192       ; 0x3d1a <__bad_interrupt>
    3c5a:   00 00          nop
    3c5c:   5e c0          rjmp   .+188       ; 0x3d1a <__bad_interrupt>
    3c5e:   00 00          nop
    3c60:   5c c0          rjmp   .+184       ; 0x3d1a <__bad_interrupt>
    3c62:   00 00          nop
    3c64:   5a c0          rjmp   .+180       ; 0x3d1a <__bad_interrupt>

Why there is this nop in between???

[Nitz76]

This is something wrong. According to the documentation, for a 328p it should be direct jump with "jmp 0x????" and not an indirect rjump. Do you know how to change that?

[vouvoume]

Nothing weired at all.
Please do not worry.

Even Atmega328p supports the jmp opcode, the compiler decided not to use it.
(Perhaps it uses 32Bit opcode instead of just 2byte like rjmp. Since the jump-destination is within the reach of rjmp, why not use it.)

And of course the interrupt table of ATmega8 looks different compared to ATmega328p.
First of all ATmega328p has more interrupt sources and therefore its table is longer. And second, since ATmega8 has a huger flash memory,
not every address can be jumped to via rjmp (only 8kib window). This is why "jmp" opcode is introduced. but since jmp is 32Bit opcode, every interrupt table entry need to be 32bit, too. (Atmega8 only needs 16bit, because every flash address can be jumped via 16bit rjmp).

I hope I could clearify thing to you,
BR vouvoume