AVR Freaks

Hello.

I'm trying to setup fuses to an mega4809.

I want to setup BOOTEND and APPEND.

According to a previous post I placed a macro in my main.c file

FUSES = {
    .WDTCFG     = WINDOW_OFF_gc | PERIOD_OFF_gc,
    .BODCFG     = 0x00,
    .OSCCFG     = FREQSEL_20MHZ_gc,
    //  .TCD0CFG    =
    //  .SYSCFG0    =
    //  .SYSCFG1    =
    .APPEND     = 0xBF,
    .BOOTEND    = 0x20,
};

Using avr-objcopy I extracted a binary.

avr-objcopy -j .fuse my-app.elf -O binary fuses.bin

and I'm trying to flash the bin into the chip.

I tried:

avrdude -c jtag2updi -P com5 -p m4809 -Ufuses:w:fuses.bin
avrdude -c jtag2updi -P com5 -p m4809 -U fuses:w:fuses.bin
avrdude -c jtag2updi -P com5 -p m4809 -U fuse:w:fuses.bin

But nothing's working.

I get.

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.22s

avrdude: Device signature = 0x1e9651 (probably m4809)
avrdude: NOTE: Programmer supports page erase for Xmega devices.
         Each page will be erased before programming it, but no chip erase is performed.
         To disable page erases, specify the -D option; for a chip-erase, use the -e option.
avrdude: reading input file "fuses.bin"
avrdude: can't determine file format for fuses.bin, specify explicitly
avrdude: read from file 'fuses.bin' failed

avrdude done.  Thank you.

Hello, I'm strugling with this sentence in the datasheet of ATtiny404: "Enabling of the 1-wire interface, by disabling the Reset functionality, is either done by 12V programming or by fusing the RESET pin to UPDI by setting the RESET Pin Configuration (RSTPINCFG) bits in FUSE.SYSCFG0."

1.- Does it mean that I need another programmer to set that pin configuration register before using this UPDI programmer for Arduino that El Tangas has shared with us?

2.- Do I need 12v programming?

3.- Or, can I just program a brand new ATtiny404 with the tool that shared El Tangas?

I dont know if this is right. I happen to use the UPDI pin as a GPIO in a tiny412 (Custom board), I didnt need any 12v to get it back to UPDI.

Well, I just configure it as a GPIO, i dont remember if it was an output or input. Using ATMEL-ICE i could use the same pin as UPDI and GPIO...its an old project, I will check if it was an o/p or i/p.

however, what i do remember clearly is that I also didnt need to change the FUSE settings for the UPDI PIN...give it a try

Regards,
Moe

Interesting. There are two questions remaining:

1. What is the chance that signals on the GPIO input may trigger UPDI programming and possibly interfere with program flow?

2. Did you try this with interrupts or only with slowly changing static input signals?

Great, now read the thread again.

Has anyone figured out whether there is a well-defined serial sequence that you could send to the UPDI pin (in normal LV UPDI mode) that would cause a chip reset.

Something "send only" that could be output to the pin with a normal Serial connection, without needing the bi-directional hardware or support for more of the UPDI protocol?

Something like BREAK, <pause 10us-13.5ms>, SYNC, 'STCS RSTREQ, 59', BREAK, perhaps?

Thanks.  Does sending a BREAK without a sync afterward turn off the UPDI?
 

The datasheet says:

 

During the enable sequence the UPDI can disable itself in case of a faulty enable sequence. There are two cases which will cause an automatic disable.

• A SYNCH character is not sent within 13.5ms after the initial enable pulse described in 32.3.2.1 UPDI Enable with Fuse Override of RESET pin.

But elsewhere it just says that the BREAK sets UPDI to its "default state."

This is a strange one, and I posted recently on the arduino.cc forum about it. The MuxTO code uses a 3rd party core for the SAMD11 which hasn't been updated in a couple of years (https://github.com/mattairtech/A...). I've used this core on other projects (for SAMD11, and SAMC21 because of CAN bus) and it works well. It is itself a fork of the official Arduino SAMD core.

But I'm a little wary of having a dependency on some code that seems, at least, a little unloved. Of course, it could be forked and brought up to date, but that's beyond my skill level.

That said, it compiles and works, so maybe I shouldn't worry too much.

Back again - I took a look at the code from the megaavr project including the SAMD11.

All changes have to be done to JICE_io.cpp and JICE_io.h - and only a few lines.

So I included in JICE_io.h:

#warning "modify this to match your USB serial port name"
#define SERIALCOM Serial

and in JICE_io.cpp lines like (in io::put):

#elif __AVR_ATmega32U4__
  SERIALCOM.write(c); //test 32U4
  return c;           //test 32U4

When not using SERIALCOM it compiles fine, but with SERIALCOM I get:

JICE_io.h:16:19: error: 'Serial' was not declared in this scope

 #define SERIALCOM Serial

When writing data to USB in my other sketches using Leonardo/proMicro I use Serial for writing to USB (and Serial1 for the UART). So I'm a bit confused why I'm getting that error here.

I had never thought of that before, actually, as 'Serial' and 'Serial1' work fine with 'normal' sketches.

Therefor I took a look in Arduino.h now:

It includes 'HardwareSerial' where the normal 'Serial' are defined:

#ifdef __cplusplus
#include "WCharacter.h"
#include "WString.h"
#include "HardwareSerial.h"
#include "USBAPI.h"
#if defined(HAVE_HWSERIAL0) && defined(HAVE_CDCSERIAL)
#error "Targets with both UART0 and CDC serial not supported"
#endif

As your files are cpp ones that should work, or?

For the 32U4 it's Serial1:

#if defined(UBRR1H)
  extern HardwareSerial Serial1;

the ones for Serial (#if defined(UBRRH) || defined(UBRR0H)) are not there, as it's a USB one.

But in USBAPI.h there actually is the part for Serial.

And USBAPI.h is also included in Arduino.h

Strange. I'm using Arduino 1.8.10 and have 'Arduino Leonardo' selected (on a Win10 machine).

I first compiled having added #elif __AVR_ATmega32U4__ and 'return 0' where return was needed, and that compiled without any errors/warnings.

Would it be a good idea to add a branch 'Arduino_32U4' or alike?

And I just saw that JICE_io.h is 'incorporated' in sys.h.. I added the #define SERIALCOM Serial even there. Same error.

When I change Serial to Serial1 I get the same error when compiling.

Well, that helped. Now everything compiles without error. Thanks. So I'll continue with the next steps and have a look how far I get.

Guess you're right with the serial port. For doing that I'll have to dig in a bit how an Arduino actually works. I didn't even realize before that the 32U4 showed up with two different serial ports - one for bootloader and another one when sketch is running before. So the port get's initialized when the Sketch is starting (at 32U4). I don't know if it's the same having a 328P (or the 4809 with SAMD11) as they're both using an extra chip for USB communication. I'll have a look how the initialization of USB is done at 32U4. Maybe I'll buy a 328P in the meantime. ;-)

I didn't expect you to solve the problems with porting to a new Arduino for me - but I thought as it's a forum to get a few hints on where I'm doing wrong. The hints I got from you where really helpful pointing where to look. And it commands me admiration of all your knowledge and effort you're putting into this project. Thanks.