ATMEGA32-16PU fuses #182
Comments
|
Here's the avrdude command for setting the 8 MHz internal oscillator and 2.7V BOD and a bootloader upload speed of 38400 baud: You will obviously have to change the path. |
|
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.
|
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 🙂 |
|
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.
|
Don't worry 🙂
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.
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.
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! Note that the upload command flag
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. |
|
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. 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. |
I would recommend you get a dedicated programmer. It makes like so much easier! My favorites are the USBasp and USBtinyISP.
I thought you just deleted the bootloader? If so, it's pretty straight forward to re-upload that to it.
You're welcome! |
|
I read this: But according to the atmega32 datasheet interrupt on change is supported: Table 34. Interrupt 1 Sense Control ISC11 ISC10 Description 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. |
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.
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.) |
|
Oh then I think my code breaks on the m32. 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 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. |
|
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! |
|
Hi again ,,, I think that maybe I need some patches for gcc but I can't seem to be able to find them. ATB |
|
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! |
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 ?
The text was updated successfully, but these errors were encountered: