UPDI programmer software for Arduino - compatible with avrdude

Go To Last Post
191 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Xtronic, Moe123 and ElTangas all make good points. I think that many of the reasons I have got into a new topic is because someone has made a route into it using the things I am already familiar.

I'm certainly thankful that jtag2updi existed to get me interested and thanks for the reminder about the ATtiny xplained boards as a updi programmer. Just ordered one today.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In my opinion the Curiosity Nano has a superior debugger to the old Xplained Nano, although at a slightly higher cost... 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Be careful! Fuses that are not explicitly defined may be set to zero, resulting in a bricked MCU that would need 12V programming to ressurect.

 

So don't comment out:

    //  .TCD0CFG    =
    //  .SYSCFG0    =
    //  .SYSCFG1    =

Set every fuse to the value you want, even if it's the default value!

Read this thread carefully: https://www.avrfreaks.net/forum/...

 

Now that the warning is given, the problem you have is that you need to specify the file format explicitly, because ".bin" files really have no format so avrdude can't auto-detect it:

 

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

Where ":r" means raw binary.

 

edit: Ah, wait, now I noticed that you are using a mega4809, which has a dedicated UPDI pin, so the chance of bricking it is low.

Last Edited: Sat. Jun 8, 2019 - 10:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A brand new device has UPDI enabled by default (fused), so you can program with any "low voltage" tool. 

If you do happen to change the UPDI pin into GPIO or /reset by changing the RSTPINCFG bits in the SYSCFG0 fuse, then you will need a 12V-capable programmer to get it back into UPDI mode again to be able to program it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mraardvark wrote:
If you do happen to change the UPDI pin into GPIO or /reset by changing the RSTPINCFG bits in the SYSCFG0 fuse, then you will need a 12V-capable programmer to get it back into UPDI mode again to be able to program it.

 

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Moe123 wrote:

mraardvark wrote:
If you do happen to change the UPDI pin into GPIO or /reset by changing the RSTPINCFG bits in the SYSCFG0 fuse, then you will need a 12V-capable programmer to get it back into UPDI mode again to be able to program it.

 

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.

 

How did you do this exactly?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

okay, so here is the deal. If you want yo use the UPDI pin as a gpio and at the same time as a UPDI without getting into 12v issue, then you can use it in one case...you have to use it as an input pin. otherwise you cant.

only as an input can use the UPDI pin. if you use it as an output then you will get yourself into 12v programming.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Moe123 wrote:

you have to use it as an input pin. otherwise you cant.

only as an input can use the UPDI pin. if you use it as an output then you will get yourself into 12v programming.

In either case, what ever is attached to the UPDI pin must be 12v tolerant or it's all for naught!

 

Jim

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

Moe123 wrote:

you have to use it as an input pin. otherwise you cant.

only as an input can use the UPDI pin. if you use it as an output then you will get yourself into 12v programming.

In either case, what ever is attached to the UPDI pin must be 12v tolerant or it's all for naught!

 

Jim


Jim, the question is whether you can use the pin as UPDI and as GPIO at the same time.

Great, now read the thread again.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

drei wrote:

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?

For 1, I dont have answer, this you have to check it with an osci...in my case i never faced such a problem like this.

For 2: interrupts

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Moe123 wrote:
I also didnt need to change the FUSE settings for the UPDI PIN...give it a try

 

So the pin is in UPDI mode, but you can still read the input? But in that case, certain input sequences will put the MCU in UPDI mode. You need to be sure such sequences will never happen, right?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its like this, you cant really read the input, BUT you can flash your program again without the need for 12V. this means, the pin may work "fine" for basic functions...but you cant read whats going on...e.g. if you use it for ADC it will not be possible to read it

Last Edited: Mon. Aug 12, 2019 - 08:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have tested using the UPDI pin as I/O while keeping it configured as UPDI; you are right, it can be used as digital input for the most part. It's possible to read its logic value, and it can even trigger interrupts and events.

That is, the pin is under control of the UPDI unit, but the CPU unit can monitor and react to what is going on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After several attempts this is my solution that seems to work reliably (tested with ATtiny814):

 

 

It turned out that the UPDI pin (when in its original fuse state) has an internal pullup resistor, approx. 20 to 30 kOhm. This pullup is not disabled even if the GPIO pullup is disabled. Therefore the best solution seems to be an open collector or open drain driver with appropriate decoupling. GPIO initialization in my case is as follows, directly taken from Atmel Start:

 

    OVERC_set_dir(PORT_DIR_IN);            // Set pin direction to input
    OVERC_set_pull_mode(PORT_PULL_OFF);

 

Here the input is used as an overcurrent detect for a CCL logic block.

 

Q1 decouples the rest of the circuit from the UPDI functionality. The jumper is normally not necessary, it can be left closed, UPDI programming works anyway provided Q1 is inactive during programming.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And using the UPDI pin as input also has the advantage that it is high voltage tolerant, so probably you can connect it to 5V logic even if the MCU is running at 3.3V (untested).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would not try that. The voltage level could be near the 12V trigger point so it could inadvertently start the UPDI programming process. On the contrary I have chosen a solution that prevents input voltages exceeding Vcc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

drei wrote:
I would not try that. The voltage level could be near the 12V trigger point so it could inadvertently start the UPDI programming process.

 

Yeah, but where exactly is that trigger level? I think I read somewhere that it's about 2x VDD, but does anyone have some actual data?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

Yeah, but where exactly is that trigger level?

 

Good question. That's why i would avoid it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Besides, does the 12V UPDI enable actually do anything if UPDI is already enabled by fuse?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

Besides, does the 12V UPDI enable actually do anything if UPDI is already enabled by fuse?


The high-voltage pulse won't do anything, but a falling edge on the UPD pin will wake the PDI-oscillator, which consumes some power. After a short period on inactivity it will go back to sleep again.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The sequence I use in jtag2updi is:

1) Double BREAK

2) Configure the UPDI - not needed here, can be skipped

3) Request RESET - SYNCH, STCS ASI_RESET_REQ, 0x59

(you don't need to wait here)

4) Release RESET - SYNCH, STCS ASI_RESET_REQ, (any 8 bit value other than 0x59, I use 0x00)

5) Wait a sensible amount of time for RESET completion.

 

In jtag2updi, point 5) is not a timed wait, I read ASI_SYS_STATUS and wait until the CPU is running, but since you don't want to do reads, a timed wait will do (100ms or so, I guess?).

 

Note: After a RESET, one of bits 1-3 of ASI_SYS_STATUS  will be set. You want bit 1 to be set (normal reset), not 2 or 3, these indicate special operating modes that will never happen unless a programmer is involved.

For some unfathomable reason, bit 1 is not documented in recent datasheets, but here it is: https://www.avrfreaks.net/commen...

 

6) You are also supposed to turn off the UPDI afterwards to save power, writing the relevant bit in CTRLB.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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."

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This, I don't know. Maybe someone from Microchip can clarify?

 

In fact, how to know if the UPDI is enabled or not? By measuring power consumption? Probably not very reliable.

 

The only method I know is to observe with a scope how the UPDI pin reacts to a BREAK:

BREAK signal----4.7K--+--UPDI
                      |
                      |
                      observe with scope for ~15us

You will see a different response whether the UPDI was already enabled or not as described in this post (last 2 pics): https://www.avrfreaks.net/forum/...

Last Edited: Wed. Sep 4, 2019 - 09:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


UPDI can enable by this  sequence

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

UPDIprogrammer with Atmega32U4?

 

I just wondered if somebody compiled for the Atmega32U4?

I have some 'pro micro' boards here, but none with 328P - and a tiny202 I'd like to program.. or play around with.

 

Trying to compile gives you lots of errors when changing to 'Leonardo', mainly from io.h. Reason seams to be the missing defines for the USB2serial as that's not needed.

When I bought the pro micro not having to bother about the serial speed seemed fine for me - just until trying to UDPI up and running now after I got this tiny202.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My knowledge of USB is approximately zero, that's why jtag2updi relies on an external USB/Serial adapter doing all the USB work. So I didn't try to make it work with the Mega32U4, I'm afraid it's beyond my skills.

However, the Arduino developers made a derived version for the Nano Every that includes the USB stuff (called MuxTO), although not for the Mega32U4 but for the SAMD21 instead. But maybe it can be adapted?

Here is the link to their source code: https://github.com/arduino/Ardui...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

not for the Mega32U4 but for the SAMD21 instead.

SAMD11, actually.  It actually uses the Arduino infrastructure/libraries for a lot of it (Serialx.read() instead of raw USB IO, for example), so I'd think that a port to 32u4 (aka Arduino Leonardo or Arduino Micro) would be relatively easy.

(It's impressive how much (from jtag2updi) was changed and how much could be left alone.  It gives me warm fuzzy feelings about the modularity and quality of both the original code, and the port...)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:

not for the Mega32U4 but for the SAMD21 instead.

SAMD11, actually.  It actually uses the Arduino infrastructure/libraries for a lot of it (Serialx.read() instead of raw USB IO, for example), so I'd think that a port to 32u4 (aka Arduino Leonardo or Arduino Micro) would be relatively easy.

(It's impressive how much (from jtag2updi) was changed and how much could be left alone.  It gives me warm fuzzy feelings about the modularity and quality of both the original code, and the port...)

 

 

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.

Last Edited: Thu. Dec 26, 2019 - 05:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for that tip. I'll give it a look - if it seems to complicated I'll order some 328P and wait some days to get those..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Where is "Serial" defined? Maybe you need to include that header explicitly? Or is it supposed to come from "Arduino.h"?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried to compile on the Arduino IDE for the Leonardo and the Micro, that contain the Mega32U4, and it doesn't complain about Serial; "JICE_io.cpp.o" was built. There are other errors, hinting that some work will be needed to get it going.

 

edit: Maybe you can convince the Arduino devs to do it? Perhaps posting an issue on the GitHub repository?

Last Edited: Fri. Dec 27, 2019 - 05:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the version of MuxTo I have, JICE_io.cpp starts with:

 

// Includes
#include <Arduino.h>
#include "JICE_io.h"
#include "sys.h"

 

instead of

 

// Includes
#include <avr/io.h>
#include "JICE_io.h"
#include "sys.h"

 

You need to include Arduino.h somewhere.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now I installed SpenceKonde's megatinycore, added the 10uF cap to avoid reset and uploaded. Result: the Leonardo is not visible any longer. After disconnecting/reconnecting it appears again for about a second as 'LeonardoBootloader' then disappears again. Then the jtag2updi should be running I guess. But no port is visible any longer - neither in the IDE nor in windows device manager.

 

I was able to do a 'reset' to the Leonardo flashing another sketch while bootloader was active, but didn't have the possibility to flash the attiny.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I said, I'm not good with USB devices. You need to get that serial port showing and I can't help there. Then send this sequence with a terminal program capable of sending hex values:

0x1b 0x00 0x00 0x01 0x00 0x00 0x00 0x0e 0x01 0xf3 0x97

 

 

If the serial link is working, the programmer will reply with:

0x1B 0x00 0x00 0x1D 0x00 0x00 0x00 0x0E 0x86 0x01 0x01 0x00 0x06 0x01 0x01 0x00 0x06 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x4A 0x54 0x41 0x47 0x49 0x43 0x45 0x20 0x6D 0x6B 0x49 0x49 0x00 0x3C 0x7F   

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is the current state of your code uploaded to github or something so that it'd be easy to look at?

 

the lack of USB presence probably indicates that the Arduino USB initialization code isn't happening correctly....

 

 

I first compiled having added #elif __AVR_ATmega32U4__

I'm sort-of thinking that you DON'T want to do that in a lot of places.   You're probably getting 32u4 "bare metal" code where what you really want is "code that uses the Arduino abstraction layer" ...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi westw, I thought creating a branch '32U4' or alike in git would be nice, but I can't create one. So I raised an issue on jtag2updi, hoping the one with the rights to do that will react. Don't know it that's the right way to do.

 

I'll have a look how the USB init is done. As I needed to add 'include Arduino.h' which you don't have to do using 'normal' sketches indicates that some parts are not included here. So some part learning left for me to do. And yes, I'd rather go for abstraction layer than 'bare metal' code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

linuxisgood wrote:
I raised an issue on jtag2updi, hoping the one with the rights to do that will react. Don't know it that's the right way to do.

 

Normally, when people want to add features to jtag2updi or create some derived work like MuxTO, they start by creating a fork.

So, I recommend that you create one, this way you can work calmly on the 32U4 port independently from me. I will help, of course, in what I can. When the port is operational, you can submit a pull request and I will consider merging it into the main branch.

 

Currently I'm working on porting jtag2updi to the AVR-0/1 architecture so the timing is not the best. I like to focus on one thing at a time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi again, created a fork '32U4_support' now. I added some lines to jtag2updi.cpp for the USB interface to come up.

The reply for the hex-string sent is as expected, but in the Arduino IDE the board info is till 'Leonardo' - is it expected that way?

The COM-port used by USB is busy while up, but RealTerm shows reply as expected.I

 

I tried to upload an empty sketch to the t202. It tries to upload quite a while, ending up with: 'an error occured uploading...'

Would it be useful to watch with an oscilloscope on pin D6?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think there are conflicts because the Arduino init functions will surely enable interrupts. This will mess up the timing of the bitbang UART present in updi_io_soft.cpp so you will need to disable interrupts inside the functions present in that file, then reenable on exit.

This may or may not work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I took a look in Arduino.h. The init() seems to be empty as far as I could see. But the USB uses interrupts ISR..

 

Then I put my scope on Pin D6 - couldn't see anything there. So it's not just timing. I'll have to dig into the code a bit deeper I guess - and into differences between 328P and 32U4.

Pages