Posted by smerrett79: Fri. May 17, 2019 - 08:59 PM
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.
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.
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:
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?
Posted by mraardvark: Thu. Jun 13, 2019 - 04:33 AM(Reply to #106)
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.
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.
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.
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
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.
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?
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
Posted by El Tangas: Thu. Aug 15, 2019 - 11:19 PM(Reply to #117)
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.
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.
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).
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.
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.
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?
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.
Posted by El Tangas: Wed. Sep 4, 2019 - 09:05 AM(Reply to #128)
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/...
Posted by linuxisgood: Wed. Dec 25, 2019 - 08:46 PM
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.
Posted by El Tangas: Wed. Dec 25, 2019 - 11:39 PM(Reply to #131)
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?
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...)
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.
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.
Posted by linuxisgood: Fri. Dec 27, 2019 - 04:25 PM(Reply to #137)
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
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?
Posted by linuxisgood: Sat. Dec 28, 2019 - 05:54 PM(Reply to #142)
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.
Posted by El Tangas: Sat. Dec 28, 2019 - 07:26 PM(Reply to #143)
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:
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" ...
Posted by linuxisgood: Sun. Dec 29, 2019 - 11:20 AM(Reply to #144)
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.
Posted by linuxisgood: Sun. Dec 29, 2019 - 11:31 AM(Reply to #145)
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.
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.
Posted by El Tangas: Mon. Dec 30, 2019 - 09:34 PM(Reply to #149)
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 inupdi_io_soft.cpp so you will need to disable interrupts inside the functions present in that file, then reenable on exit.
Posted by linuxisgood: Tue. Dec 31, 2019 - 10:15 AM(Reply to #150)
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.
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.
- Log in or register to post comments
TopIn my opinion the Curiosity Nano has a superior debugger to the old Xplained Nano, although at a slightly higher cost...
- Log in or register to post comments
TopHello.
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
Using avr-objcopy I extracted a binary.
and I'm trying to flash the bin into the chip.
I tried:
But nothing's working.
I get.
- Log in or register to post comments
TopBe 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:
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:
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.
- Log in or register to post comments
TopHello, 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?
- Log in or register to post comments
TopA 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.
- Log in or register to post comments
TopI 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.
- Log in or register to post comments
TopHow did you do this exactly?
- Log in or register to post comments
TopWell, 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
- Log in or register to post comments
Topokay, 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.
- Log in or register to post comments
TopInteresting. 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?
- Log in or register to post comments
TopIn either case, what ever is attached to the UPDI pin must be 12v tolerant or it's all for naught!
Jim
FF = PI > S.E.T
- Log in or register to post comments
TopJim, the question is whether you can use the pin as UPDI and as GPIO at the same time.
Great, now read the thread again.
- Log in or register to post comments
TopFor 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
- Log in or register to post comments
TopSo 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?
- Log in or register to post comments
TopIts 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
- Log in or register to post comments
TopI 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.
- Log in or register to post comments
TopAfter 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.
- Log in or register to post comments
TopAnd 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).
- Log in or register to post comments
TopI 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.
- Log in or register to post comments
TopYeah, 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?
- Log in or register to post comments
TopGood question. That's why i would avoid it.
- Log in or register to post comments
TopBesides, does the 12V UPDI enable actually do anything if UPDI is already enabled by fuse?
- Log in or register to post comments
TopThe 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.
- Log in or register to post comments
TopHas 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?
- Log in or register to post comments
TopThe 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.
- Log in or register to post comments
TopThanks. Does sending a BREAK without a sync afterward turn off the UPDI?
The datasheet says:
But elsewhere it just says that the BREAK sets UPDI to its "default state."
- Log in or register to post comments
TopThis, 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:
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/...
- Log in or register to post comments
TopUPDI can enable by this sequence
Thinary Electronic
https://thinaryelectronic.aliexpress.com/
- Log in or register to post comments
TopUPDIprogrammer 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.
- Log in or register to post comments
TopMy 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...
- Log in or register to post comments
TopSAMD11, 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...)
- Log in or register to post comments
TopThis 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.
- Log in or register to post comments
TopThanks 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..
- Log in or register to post comments
TopBack 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.
- Log in or register to post comments
TopWhere is "Serial" defined? Maybe you need to include that header explicitly? Or is it supposed to come from "Arduino.h"?
- Log in or register to post comments
TopI 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
- Log in or register to post comments
TopI 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?
- Log in or register to post comments
TopStrange. 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.
- Log in or register to post comments
TopIn the version of MuxTo I have, JICE_io.cpp starts with:
instead of
You need to include Arduino.h somewhere.
- Log in or register to post comments
TopWell, that helped. Now everything compiles without error. Thanks. So I'll continue with the next steps and have a look how far I get.
- Log in or register to post comments
TopNow 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):
- Log in or register to post comments
TopAs 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:
If the serial link is working, the programmer will reply with:
- Log in or register to post comments
TopIs 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'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" ...
- Log in or register to post comments
TopGuess 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.
- Log in or register to post comments
TopHi 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.
- Log in or register to post comments
TopNormally, 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.
- Log in or register to post comments
TopHi 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?
- Log in or register to post comments
TopI 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.
- Log in or register to post comments
TopI 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.
- Log in or register to post comments
TopPages