ATMEGA32-16PU fuses

[louigi600]

This is not really an issue but I wanted to get some specific help for the virgin MCU I have and intend to use with internal 8Mhz rc clock for the moment. I looked for any other option to contact the author but was not able ti find any better way: sorry. So I have avrdude with linuxgpio enabled and working on RPI0 (running on slackwareARM 14.2). I've tested and recovered a bricked ch340 NANO clole that proved to be not recoverable with Arduino as ISP sketch and a working NANO clone. Arduino IDE is not working on alskcwareSRM 14.2 probabbly bcause that version of the distro I use is still softfloat. So I haveto load whatever from command line using a compiled avrdude. Can you help me with selecting the right bootloader and efuses to set ? This is what I used to unbrick the NANO: avrdude.conf -v -patmega328p -crpi -Pgpio -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDA:m -Ulfuse:w:0xFF:m and then avrdude.conf -v -patmega328p -crpi -Pgpio -e -U flash:w:/root/optiboot_atmega328.hex -U lock:w:0x0F:m I figured out that the part fro my atmega32-16pu is probabbly m32, but I've no idea which bootloader and efuses should be set. Can you please help me ?

[MCUdude]

Here's the avrdude command for setting the 8 MHz internal oscillator and 2.7V BOD and a bootloader upload speed of 38400 baud:

avrdude -C/path/to/avrdude.conf -v -patmega32 -crpi -e -Ulock:w:0x3f:m -Uhfuse:w:0b11010110:m -Ulfuse:w:0b10100100:m -Uflash:w:/path/to/MightyCore/avr/bootloaders/optiboot_flash/bootloaders/atmega32/8000000L/optiboot_flash_atmega32_UART0_38400_8000000L_B0.hex

You will obviously have to change the path.

[louigi600]

Thanks so much for the help and for the Mighty and Mega Core Libraries.Sorry for opening an issue for this, can I drop you a line should I need help in the future ? or maybe you don't want people to bother you ? ATB David

Il lunedì 18 maggio 2020, 22:36:19 CEST, Hans <notifications@github.com> ha scritto:  

Here's the avrdude command for setting the 8 MHz internal oscillator and 2.7V BOD and a bootloader upload speed of 38400 baud: avrdude -C/path/to/avrdude.conf -v -patmega32 -crpi -e -Ulock:w:0x3f:m -Uhfuse:w:0b11010110:m -Ulfuse:w:0b10100100:m -Uflash:w:/path/to/MightyCore/avr/bootloaders/optiboot_flash/bootloaders/atmega32/8000000L/optiboot_flash_atmega32_UART0_38400_8000000L_B0.hex

You will obviously have to change the path.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[MCUdude]

can I drop you a line should I need help in the future ? or maybe you don't want people to bother you ?

Sure! Just re-use this one if you can't figure it out, or open a new issue if you're having other issues. I usually try to help out as much as possible, but I was quick to close this because it's a question and not an issue itself. But I'm still getting notifications from closed issues, and I'll happily help out more if you need to 🙂

[louigi600]

Cool ... now that I'm thinking about actually wiring the atmega32 to the RPI I was wondering if I should power it up with 3.3v or 5v. You said that BOD is set to 2.7v so maybe I should power it up 3.3v ? (hi have both on the RPI pinout but currently it's wired for 5v atmega328p ... as I unbricked a NANO)The datasheed says that the non L version operating voltage is 4.5 to 5.5v ... so 2.7V seems low fror Brown Out Detection ... or I misunderstood something ? Damn as I write to you more questions come in to my mind ... hope you don't get mad at me.The bootloader goes at the end of the flash ... but how does avrdude figure out that the boot loader is to be written at the end ... I can't pick up that from the options: does it depend on how the hex file was built ?

Should I want to flash directly a program compiled manually ? in that case I don't need the bootloader ... I took some notes when I compiled and flashed a small test progam on NANO: avr-gcc -Os -DF_CPU=16000000UL -mmcu=atmega328p -c -o blink.o blink.cavr-gcc -mmcu=atmega328p blink.o -o blink#optional to strip the elf of al unnecessary symbols (including debugging simbols)#I think that avr-objcopy ino intel hex format will strip anyway.avr-strip blink avr-objcopy -O ihex -R .eeprom blink blink.hexavrdude -C $TOOLCHAINDIR/etc/avrdude.conf -F -V -D -carduino -patmega328p  -P/dev/ttyUSB0 -b57600 -U flash:w:blink.hex:i The flas part of the avrdude in this case had an extra flag:-U flash:w:blink.hex:i

does that tell avrdure that it is not bootloader so it can go at the beginning of flash ? without the :i avrdude loads it 512 bytes from the end of the flash ?or is the difference made by which type of programmer is used -carduino uses the bootloader to write itself while -crpi uses the bitbanged linux gpio programmer setuop I configured in avrdude.conf .... but then I was able to brick an arduino by incorrect use of -carduino and I wiped the bootloader ... so I think this later thing I said is wrong. There are 2 bootloaders for 8mhz clock, uart0 @ 38400 one with B0 and one with B7: what's the difference ?

BTW: I use system wide avrdude config file in /usr/local/etc/avrdude.conf ... so no neet to specify one.avrdude complains about no port specification so the -Pgpio is mandatory. Saluti Davide Rao

Il lunedì 18 maggio 2020, 22:55:21 CEST, Hans <notifications@github.com> ha scritto:  

can I drop you a line should I need help in the future ? or maybe you don't want people to bother you ?

Sure! Just re-use this one if you can't figure it out, or open a new issue if you're having other issues. I usually try to help out as much as possible, but I was quick to close this because it's a question and not an issue itself. But I'm still getting notifications from closed issues, and I'll happily help out more if you need to 🙂

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[MCUdude]

Damn as I write to you more questions come in to my mind ... hope you don't get mad at me.

Don't worry 🙂

Cool ... now that I'm thinking about actually wiring the atmega32 to the RPI I was wondering if I should power it up with 3.3v or 5v. You said that BOD is set to 2.7v so maybe I should power it up 3.3v ? (hi have both on the RPI pinout but currently it's wired for 5v atmega328p ... as I unbricked a NANO)The datasheed says that the non L version operating voltage is 4.5 to 5.5v ... so 2.7V seems low fror Brown Out Detection ... or I misunderstood something ?

Historically, The ATmega32L was used from 0-8 MHz, and the ATmega32 from 8-16 MHz. Now we have the ATmega32A which supports both. Even though it's out of spec, you can run an ATmega32 at 3.3V. It's just that they don't guarantee anything. I suggest you give it a try; you won't damage anything.

The bootloader goes at the end of the flash ... but how does avrdude figure out that the boot loader is to be written at the end ... I can't pick up that from the options: does it depend on how the hex file was built ?

Avrdude doesn't care about this. It just sends the hex file to the microcontroller, and all the memory addresses are located in the hex file. For all user applications, the hex file starts at address 0 and grows to depend on the size of the program. The bootloader hex file is built with this address offset. This is specified in the bootloader makefile. The fuse bits are also set up to reserve a given size for a bootloader at the end of the flash.

Should I want to flash directly a program compiled manually ? in that case I don't need the bootloader ...

If you don't upload to the chip using a serial interface, there's no need for a bootloader. In this case, use the fuses below can be used instead. These are set up so there's no reserved memory for a bootloader, and gives you 512 bytes for flash for your application at the top. If you're curious what the fuse byts actually do I recommend checking out the Engbedded Fusecalc. It's super helpful!

-Uhfuse:w:0b11010111:m -Ulfuse:w:0b10100100:m 

Note that the upload command flag -e will erase the bootloader too, but it has to be there. Use -D instead if using the bootloader to upload. The :i at the end of the hex file just specify to Avrdude that you're giving it an Intel hex. However, it's usually pretty good at automatically figuring out what type of hex file it is. You can look up the Avrdude manual if you want to know what all the flag means.

There are 2 bootloaders for 8mhz clock, uart0 @ 38400 one with B0 and one with B7: what's the difference?

The only difference here is the pin used for LED flashing; PB0 or PB7. The bootloader is programmed to flash twice when a hardware reset occurs. The reason why two variants are provided is because this Arduino core has two pinout variants, Standard and Bobuino. Standard uses PB0 to flash its LED, while Bobuino uses PB7.

[louigi600]

At some point (probabbly when I can salvage a 16mhz crystal from some electronics device) I will transition to 16Mhz clock ... so in the meantime I will read the fuse information.

Yes a bad combination of -c and -e while desparately trying to get Arduino as ISP to write bootloader to the really old atmega32 I have (sample I've had for some 3 years collecting dust) I managed to erase the bootloader on the working ch340 NANO clone I was using for the job. I came to the conclusion that the comments on the Arduino as ISP sketch are insufficient to get it to work correctly that's whi I moved to RPI gpio. Initially I didn't even know that avrdude can do bitbanging on the pure GPIO ... but I started looking in that direction because the RPI actually has SPI dedicated pins. Well pity they don't use the native SPI but I guess bitbangig on generic io pins can get avrdude to work on anything that has gpio without actually requiring native SPI support.

Anyway I had the wiring done for the 5v NANO and after having checked the m23 datasheet I supposed that setting BOD to 2.7v might not make sense but will not harm the MCU, and the 5v was totally safe on the MCU I have. So last night I managed to burn the bootloader into the m32. One day I might salvage ch340 from one of the NANOS I've physically damaged ... but for the meantime I will probabbly upload sketches from programmer and 512 bytes don't seem to bug me for the minute as I've not yet hit the flash memory limit on any of my sketches. Thanks so much again for your precious help and information. If I ever make an article on slackware docs about plying with atmega you will definitely get a mention there.

[MCUdude]

Yes a bad combination of -c and -e while desparately trying to get Arduino as ISP to write bootloader to the really old atmega32 I have (sample I've had for some 3 years collecting dust) I managed to erase the bootloader on the working ch340 NANO clone I was using for the job. I came to the conclusion that the comments on the Arduino as ISP sketch are insufficient to get it to work correctly that's whi I moved to RPI gpio. Initially I didn't even know that avrdude can do bitbanging on the pure GPIO ... but I started looking in that direction because the RPI actually has SPI dedicated pins. Well pity they don't use the native SPI but I guess bitbangig on generic io pins can get avrdude to work on anything that has gpio without actually requiring native SPI support.

I would recommend you get a dedicated programmer. It makes like so much easier! My favorites are the USBasp and USBtinyISP.

One day I might salvage ch340 from one of the NANOS I've physically damaged

I thought you just deleted the bootloader? If so, it's pretty straight forward to re-upload that to it.

Thanks so much again for your precious help and information.

You're welcome!

[louigi600]

I read this: Library_porting.md:* The library relies on pin change interrupt (which the ATmega8535/16/32 doesn't support)

But according to the atmega32 datasheet interrupt on change is supported:

Table 34. Interrupt 1 Sense Control

ISC11 ISC10 Description 0 0 The low level of INT1 generates an interrupt request. 0 1 Any logical change on INT1 generates an interrupt request. 1 0 The falling edge of INT1 generates an interrupt request. 1 1 The rising edge of INT1 generates an interrupt request.

I'm puzzeled :On the NANO I use interrupt on change to drive sensored BLCD motor according to the changes in the hall sensor readings ... will I be able to use the same thing also on the m32 ?

A RPI Zero is not that much more expensive then USBtiny but can do so much more. I think it's a a very nice alternative ... and if I put on it the current slackwareARM (that is hardfloat) I can probabbly get the whole arduino ide to work from it. But I will see if I can get a cheap chinese clone of the USBtiny for a bargain price.

[MCUdude]

Library_porting.md:* The library relies on pin change interrupt (which the ATmega8535/16/32 doesn't support)

There is a difference between pin change interrupt (aka PCINT) and interrupt on change. PCINT (which the ATmega32 does not have) watches an entire port, and will fire if one or more pins change. It will be up to the user to determine which pin triggered the interrupt. "Regular" interrupts (INT0, INT1 etc.) also supports change, but it's only for one pin.

For reference, Arduino's attachInterrupt does not utilize PCINTs, and will only work for "regular" interrupts, INT0, INT1, etc. So everything should work as expected for your application.

The ATmega328P, used on the Nano has two regular interrupt pins, and PCINT on the rest. ATmega32 has three interrupt pins and no PCINT.

A RPI Zero is not that much more expensive then USBtiny but can do so much more. I think it's a a very nice alternative ... and if I put on it the current slackwareARM (that is hardfloat) I can probabbly get the whole arduino ide to work from it. But I will see if I can get a cheap chinese clone of the USBtiny for a bargain price.

The zero is a full-blown computer, while the programmer is just a tiny board with a microcontroller that's tricked into talking USB. I have little to no experience with Raspberry Pin GPIO latency, but all I know is that the USBasp and USBtinyISP "just works". (The USBasp seems to be favored amongst these two.)

[louigi600]

Oh then I think my code breaks on the m32. 2 pins with regular interrupts was not enough typical sensored BLDC motor has 3 windings and 3 hall sensors. Here are the relative lines that setup what I use for reading the 3 hall sensors connected to arduino pins 8,9 and 10

  PCMSK0 = 7; //enable interruts on chabge for pins 8,9 and 10
  PCIFR = 0;  //clearing all interrupt flags
  PCICR = 1;  //enabling interrupts on pins 8 to 13
//and later on the ISR:
ISR (PCINT0_vect)
{ byte bitpos;
  unsigned long M;

  if ( (bitpos = GetPosition()) != NBP ) return;
  (*PPfptr)(bitpos,TD);
  BitPos=bitpos;
  //do the rotation counting to keep track of distance  and rotation speed
  PhaseChanges++; //count each phase change
  if ( PhaseChanges >= (PCPR * 6) ) //turn the Phasechanges into revolutions
  { PhaseChanges=0;
    Rotations++;
    M=millis();
    FRM=min(FRM,M-LRM);
    LRM=M;
  }
}

Where GetPosition() returnes a byte of which only the lowest 3 bits are of intrest (the 3 hall sensor status bits).

But I can have 3 regular interrupts so I think I can work around the problem... after all I need to keep track of the status of 3 hall sensors that can be regarded ad digital output (not really true but for the pourpose of driving the motor it is an acceptable assumption).

Anyway I suppose I will have 3 ISR one for each interrupt ISR (INT0_vect) ISR (INT1_vect) ISR (INT2_vect) and a global volatile variable wich will hold the updated bitpos ... each ISR will target just one of the bits at a time.

Yes the RPI Zero is one of the smallest fully functional computers around, and is rather cheap for what it is (5 Euro or 6 Euro for the Wifi version). But I forgot one thing ... The core of the RPI Zero cannot run the slackwareARM hardfloat current port, not sure if I can get another hardfloat distro on it .... might haveto compile the cross toolchain for ATmega. The cheapest I could find a USBtinyISP or USBasp is about 3 Euro ... I still think that a fully functional computer for just 2 more Euro is a better bargain ... souds like I want to convince you but I'm just motivating my choice.

[MCUdude]

Seems like your current code uses PCINTs, which the ATmega32 doesn't have. If you need that, you can get the ATmega324 instead. It's pin-compatible with ATmega32, but have some extra features, like PCINT.

However, since you have three hall-effect sensors, INT0-INT2 should be sufficient!

[louigi600]

Hi again ,,, I'm trying to compile gcc for my RPI0 but I'm running into an issue. I've compiled it and several other things required but I don't get support for the atmega devices: root@rpi4:~/arduino_from_command_line# avr-gcc -mmcu=atmega328p blink.o -o blink /usr/local/avr/lib/gcc/avr/7.3.0/../../../../avr/bin/ld: cannot find -latmega328p collect2: error: ld returned 1 exit status root@rpi4:~/arduino_from_command_line#

I think that maybe I need some patches for gcc but I can't seem to be able to find them. Can you help ? I'm doing manual build ... none of that devops nonsence I'm ols style sysadmin.

ATB David

[MCUdude]

Sorry, that's something I've never done and have no experience with. I'll recommend asking your question over at the Avrfreaks forum. They have an answer for everything!