bugAVR Downloader/UploaDEr - Bugs: bug #61626, jtagmkii_pdi improvements for...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #61626: jtagmkii_pdi improvements for jtag2updi use

Submitter:  mcudude <mcudude>
Submitted:  Mon 06 Dec 2021 02:39:57 PM UTC
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Privacy:  Public
Assigned to:  None Originator Name:  * MCUdude
Open/Closed:  Open Release:  * SVN snapshot
Programmer hardware:  jtagmkii_pdi Device type: 
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

( Jump to the original submission )

Mon 13 Dec 2021 08:53:11 AM UTC, comment #6: 

Regarding the jtag2updi documentation, I'll see what I can do. The only real obstacle is the lack of experience with SVN. I have no idea how I clone/fork or submit a patch. But I'm sure it's possible to figure out.

mcudude <mcudude>
Mon 06 Dec 2021 10:16:42 PM UTC, comment #5: 

comment #4:

> Would be great if the essence could be scissored out and added to the docs. A link to the repo is probably also a good idea.
>


Please do ;-)

I welcome diffs, also for documentation updates.

> Ah, the PDIUSBD12 chip!


Right.

> So if I understand you correctly, pulling DTR/RTS low before "hello" and releasing after "goodbye" shouldn't cause any harm/compatibility issues with existing hardware. Excellent!
>


Seems so.

> But there is nothing in the protocol that limits the speed to a maximum baud rate of 115200? Heck, could we theoretically use 230400, 250000, 460800 or 500000,  921600 or even 1M if Avrdude supported it (in function jtagmkII_get_baud())?
>


I'm not so sure why these baudrate checks are even necessary in that code. Maybe we could as well leave it up to the underlying OS (and driver) whether it can accept a certain baudrate.

But that needs to be verified/tested.

Joerg Wunsch <joerg_wunsch>
Project Administrator
Mon 06 Dec 2021 09:10:58 PM UTC, comment #4: 

> But that needs to be added to either avrdude.1 or doc/avrdude.taxi (I'm willing to copy it over to the other of both documents), and maybe the URL also should be documented in avrdude.conf[.in].


Would be great if the essence could be scissored out and added to the docs. A link to the repo is probably also a good idea.

> AFAICT the original JTAGICE mkII doesn't use DTR/RTS, and it is mostly talked with these days through its USB connector (which is not going to a USB-serial chip inside but to an old NXP parallel chip).


Ah, the PDIUSBD12 chip! Haven't really seen it in anything else than in AVR programming hardware; wonder why... So if I understand you correctly, pulling DTR/RTS low before "hello" and releasing after "goodbye" shouldn't cause any harm/compatibility issues with existing hardware. Excellent!

> When being talked to through the serial connection, the JTAGICE mkII behaves in a very specific way: it always uses 19200 Bd to attach to, but then switches to 115200 Bd on the fly once the connection has been established. That's why it is also necessary to correctly say "good-bye" to it, as by that, it reverts to 19200 Bd. Also, that "hello" / "good-bye" sequence is used to deactivate the unused of the two connectors while being active (RS232 vs. USB).

Thus, the jtagmkII.c code hardcodes the 19200 Bd default speed, while the baudrate configured on the commandline or in avrdude.conf is only used for the active connection.

But there is nothing in the protocol that limits the speed to a maximum baud rate of 115200? Heck, could we theoretically use 230400, 250000, 460800 or 500000,  921600 or even 1M if Avrdude supported it (in function jtagmkII_get_baud())?

Quick last question. I was very pleased to see some activity here. After all, I use Avrdude alot, and I love the fact that SO many programmers are supported.
Is the current plan to apply patches and fix critical bugs and call it a day (and that's totally OK), or will further development continue in the future, perhaps driven by bug reports, feature requests and user-applied patches? Regardless, I'm very thankful for all your contributions over the the years, resulting in a tool that's used by the entire AVR community to this very day.

mcudude <mcudude>
Mon 06 Dec 2021 07:34:32 PM UTC, comment #3: 

comment #2:

> I'm not sure I follow you regarding the documentation and what you mean by "it", sorry.


"it" = the proposed addition

> The jtag2updi project is documented on its Github repo, and the hardware required for it to work is pretty much any AVR with at least 16k flash I think.


But that needs to be added to either avrdude.1 or doc/avrdude.texi (I'm willing to copy it over to the other of both documents), and maybe the URL also should be documented in avrdude.conf[.in].

(DTR/RTS)

> Do you know if this is true for the actual JTAGICE mkII as well?


AFAICT the original JTAGICE mkII doesn't use DTR/RTS, and it is mostly talked with these days through its USB connector (which is not going to a USB-serial chip inside but to an old NXP parallel chip).

> Will support for increased baud rates cause any backwards compatibility issues for the jtagicemkii_pdi protocol?


When being talked to through the serial connection, the JTAGICE mkII behaves in a very specific way: it always uses 19200 Bd to attach to, but then switches to 115200 Bd on the fly once the connection has been established. That's why it is also necessary to correctly say "good-bye" to it, as by that, it reverts to 19200 Bd. Also, that "hello" / "good-bye" sequence is used to deactivate the unused of the two connectors while being active (RS232 vs. USB).

Thus, the jtagmkII.c code hardcodes the 19200 Bd default speed, while the baudrate configured on the commandline or in avrdude.conf is only used for the active connection.

Joerg Wunsch <joerg_wunsch>
Project Administrator
Mon 06 Dec 2021 06:52:37 PM UTC, comment #2: 

I'm not sure I follow you regarding the documentation and what you mean by "it", sorry. The jtag2updi project is documented on its Github repo, and the hardware required for it to work is pretty much any AVR with at least 16k flash I think. There are also some information scattered around in this AVRfreaks thread:
https://www.avrfreaks.net/forum/updi-programmer-software-arduino-compatible-avrdude

The ASCII-like schematic was something I made up just to illustrate how a programmer could be designed if DTR or RTS was controlled by Avrdude during upload. I don't own a physical jtagicemkii (only a chinese JTAGICE stick), but my "stick" with a CH340T USB to serial chip doesn't seem to utilize any of the hardware handshake pins. Do you know if this is true for the actual JTAGICE mkII as well?

Will support for increased baud rates cause any backwards compatibility issues for the jtagicemkii_pdi protocol?

mcudude <mcudude>
Mon 06 Dec 2021 03:03:03 PM UTC, comment #1: 

We can probably add that entry in avrdude.conf. I'd love to also see a documentation update for it, including the reference to the hardware description.

However, it's not the only UPDI programmer supported by AVRDUDE; EDBG-style programmers are supported now as well (thanks to Jan Egil), including the mEDBGs from the Curiosity Nano boards.

Joerg Wunsch <joerg_wunsch>
Project Administrator
Mon 06 Dec 2021 02:39:57 PM UTC, original submission:  

Hi!

Since there is some activity here, I might as well share my thoughts on this topic.

The only FOSS alternative for a UPDI programmer supported by Avrdude at the moment is the jtag2updi, which uses jtagmkii_pdi as its protocol.

https://github.com/ElTangas/jtag2updi

It implements its own custom programmer option in avrdude.conf:

programmer
  id    = "jtag2updi";
  desc  = "JTAGv2 to UPDI bridge";
  type  = "jtagmkii_pdi";
  connection_type = serial;
  baudrate = 115200;
;

However, there are at least two annoying issues that make the jtag2updi programmer a little "weak".

First, the maximum supported baud rate is 115200 baud. This ends up being rather slow on the UPDI side, so uploading takes a long time for larger programs. Is this something that's possible to fix?

The other one is the same as mentioned in #61624, making it possible to make use of the DTR/RTS lines to indicate that we're currently in jtag2updi mode. The official Arduino Nano Every solves this by using an ARM microcontroller with native USB and using a "1200bps touch" to force it into UPDI mode. Otherwise, it's in USB to serial mode. This is obviously not possible on AVRs with no native USB. Would it be possible to optionally pull the DTR/RTS line(s) low when Avrdude is communicating with the jtag2updi host? This would make it possible to create a programmer that has some external logic to switch the serial pins between the jtag2updi host and the microcontroller:

                                                  V_prog          V_target
                                                    +-+              +-+
                                                     |                |
 +----------+                +---------------------+ |                | +--------------------+
 | PC       |                | jtag2updi           +-+                +-+  Target            |
 | avrdude  |                | programmer          |    +----------+    |                    |
 |       TX +--------+       |                 PD6 +----+    1k    +----+ UPDI               |
 |          |        |       |                     |    +----------+    |                    |
 |       RX +------+ |       |                     |               +----+ RX                 |
 |          |      | |       |                     |               |    |                    |
 |          |      | |       |                     |               | +--+ TX                 |
 |      DTR +----+ | |       |                     |               | |  |                    |
 |          |    | | |       |      RX  TX         |               | |  +--------------------+
 +----------+    | | |       +------+---+----------+               | |
                 | | |              |   |                          | |
                 | | |       +------+---+----------+               | |
                 | | |       |      RX1 TX1        |               | |
                 | | +-------+ RX              RX2 +---------------+ |
                 | |         |                     |                 |
                 | +---------+ TX   DTR/RTS    TX2 +-----------------+
                 |           |      Switch         |
                 +-----------+ DTR                 |
                             |                     |
                             +---------------------+

mcudude <mcudude>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by mcudude (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    No changes have been made to this item

    Back to the top


    Powered by Savane 3.9