Closed mcuee closed 10 months ago
askn37
commented
10 months ago be careful...
AVR_EB has many different memory maps than other products. In particular, various problems will occur if "signature=0x1080" is overlooked.
recommendation. Create a completely new part. part; id = ".avreb";
BAN. If "lock=0x1040" and "fusea:pdicfg=0x105a" are set to a specific state at the same time, UPDI control will not return even if HV control is performed. It should be.
stefanrueger
commented
10 months ago I wonder whether the observed behaviour is a specific property of how the 2-byte pdicfg fuse works. One is supposed to unlock it first with a key:
stefanrueger
commented
10 months ago | AVR_EB has many different memory maps than other products.
True. I believe the avrdude.conf entries to be correct:
$ avrdude -c dryrun -p avr16eb*/At | grep offset | cut -f3- | sort | uniq -c
4 bootrow offset 0x1100
4 data offset 0x1000000
4 eeprom offset 0x1400
4 flash offset 0x800000
4 fuse0 offset 0x1050
4 fuse1 offset 0x1051
4 fuse2 offset 0x1052
4 fuse5 offset 0x1055
4 fuse6 offset 0x1056
4 fuse7 offset 0x1057
4 fuse8 offset 0x1058
4 fusea offset 0x105a
4 fuses offset 0x1050
4 io offset 0x0
4 lock offset 0x1040
4 prodsig offset 0x1080
4 sernum offset 0x1090
4 sib offset 0x0
4 signature offset 0x1080
4 tempsense offset 0x1084
4 userrow offset 0x1200@stefanrueger
DS40002522A - 58P
8.10.2.8 UPDI Protection - Bits 1:0 – LEVEL[1:0] UPDI Protection Level
NVMACCDIS : NVM access through UPDI disabled. Chip Erase and USERROW write are also disabled.
Even if this is effective, it does not seem to be written yet whether UPDI access rights can be regained using HV control.
stefanrueger
commented
10 months ago @MCUdude Please try writing 0x2 to the 2-byte pdicfg fuse following the procedure in the datasheet and see whether that works.
MCUdude
commented
10 months ago I'll see what I can do. I really don't want to mess this chip up, because this is the only one I got (donated by Microchip Norway), and even though I have samples from Microchip Direct on order, they won't arrive until late December.
Please try writing 0x2 to the 2-byte pdicfg fuse
But doesn't this result in a "bricked chip", as I don't have a functioning bootloader present? And even if there is a bootloader present, would it be possible to re-enable UPDI?
mcuee
commented
10 months ago @MCUdude
Better play safe in this case.
askn37
commented
10 months ago @MCUdude
But doesn't this result in a "bricked chip", as I don't have a functioning bootloader present? And even if there is a bootloader present, would it be possible to re-enable UPDI?
I've already written an optiboot compatible bootloader that "supposedly" works, but I haven't received the chip yet so I can't test it, so it's pending. (Of course, FUSE changes, HV control, etc. have not been verified)
https://github.com/askn37/multix-zinnia-sdk-modernAVR/tree/main/bootloaders
And it is ''certainly'' irreversible. PDICFG will not take effect unless LOCK is also executed at the same time. However, without Chip Erase he cannot release the LOCK even with HV control, but with PDICFG he rejects both UPDI and Chip Erase. As a logical consequence, HV control is also rejected.
So I just warn you to be very careful in this matter. . .
MCUdude
commented
10 months ago I should probably wait until I at least have one AVR-EA replacement chip.
@xedbg do you have an AVR-EB you can sacrifice for the sake of science? 😄 We want to verify that we can write to that PDICFG fuse, which is the first two-byte fuse I've encountered in an AVR.
stefanrueger
commented
10 months ago OK, understood; easy for me to make suggestions that might brick other people's parts :open_mouth:
My reading of the data sheet is that the key mechanism for pdicfg is exactly here to prevent people from inadvertently writing 0x0002 to pdicfg. Hence, I am not convinced the observed behaviour is a bug!
You could try -c dryrun to see whether the logic of reading/writing the two-byte fuse pdicfg works in principle. This fuse is supposed to have a bitmask of 0xfff3. For AVRDUDE this means that Bits 2:3 will not be verified. Note that AVRDUDE will not prevent the terminal nor the command line -U from setting these bits to any value the user likes. This is because sometimes the data sheet says unused bits must be written as 1 and sometimes it says they must be written as 0. AVRDUDE does not have that deep understanding of the 4607 memories of the 355 parts it knows about (and I doubt the ATDF files model this).
Also note that -c dryrun does not closely emulate the chip. So you will be able to write 0xffff and read back 0xffff in -c dryrun:
$ (memory-types) avrdude -qqc dryrun -p avr16eb28 -t
avrdude> r pdicfg
0000 03 00 |.. |
avrdude> w pdicfg 0 0xffff
avrdude> r pdicfg
0000 ff ff |.. |Best to test this in the branch of PR #1538: This is the next one to merge (and alters how memories are located, read or written).
askn37
commented
10 months ago This is my personal opinion, but this is how I write it in my configuration file.
# *** CAUTION ***
# The 'fuses' of the AVR_EB series is originally 11 bytes,
# but is limited to 9 bytes here to avoid irrecoverable failures.
# To overwrite the last two bytes added,
# explicitly specify 'fusea' or 'pdicfg'.
memory "fuses"
size = 9;
page_size = 16;
offset = 0x1050;
readsize = 16;
;This prevents you from accidentally touching the two bytes in question when you back up the "fuse" to a file and write it back. Regarding handling, we have clarified that, like LOCK_BITS, they are parameters that should be managed individually depending on the purpose (although they are consecutive in position).
MCUdude
commented
10 months ago I can't get SerialUPDI to work with the AVR16EB32. I also tested using PR #1543, but I'm getting the same result. I don't know enough about the UPDI protocol and the difference between the different NVM versions (@dbuchwald):
$ ./avrdude -cserialupdi -pavr16eb32 -P ch340 -Uflash:r:-:I
avrdude warning: unsupported NVM type: 5, please update software
avrdude error: decode SIB_INFO failed
avrdude error: initialization failed, rc=-1
- double check the connections and try again
- use -b to set lower baud rate, e.g. -b 57600
- use -F to override this check
avrdude done. Thank you.The jtag2updi programmer can establish connection with the AVR16EB32, but it fails to write to flash, and when I dump the flash content after an erase, there's still corrupted content present. Not sure if this is because the jtag2updi fails to erase the part or fails to read the content.
$ ./avrdude -cjtag2updi -pavr16eb32 -P ch340 -Uflash:w:0x55_16B.hex
avrdude error: bad response to set parameter command: RSP_ILLEGAL_PARAMETER
avrdude error: bad response to set parameter command: RSP_ILLEGAL_PARAMETER
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e943e (probably avr16eb32)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: processing -U flash:w:0x55_16B.hex:i
avrdude: reading input file 0x55_16B.hex for flash
with 16 bytes in 1 section within [0, 15]
using 1 page and 48 pad bytes
avrdude: writing 16 bytes flash ...
Writing | ################################################## | 100% 0.03 s
avrdude: 16 bytes of flash written
avrdude: verifying flash memory against 0x55_16B.hex
Reading | ################################################## | 100% 0.02 s
avrdude warning: verification mismatch
device 0x00 != input 0x55 at addr 0x0001 (error)
avrdude error: verification mismatch
avrdude done. Thank you.EDIT: The SerialUPDI programmer works great with the AVR64EA48, but has NVM type 3: 24-bit, page oriented. The jtag2updi also struggles with the AVR64EA48, similar to how it behaved when trying to interact with the AVR16EB32.
I don't think there's much we can do about the jtag2updi programmer, since this would require a firmware update.
To summarize:
| AVR-EA | AVR-EB | |
|---|---|---|
| SerialUPDI | ✅ | ❌ |
| jtag2updi | ❌ | ❌ |
stefanrueger
commented
10 months ago Can you read the memories OK? Seeing as you can r/w the EB part with the pkobn_updi programmer you could prep the part to have a certain contents and then try to verify with jtag2updi.
I wonder where the
avrdude error: bad response to set parameter command: RSP_ILLEGAL_PARAMETERmessages come from. I pushed a commit onto PR #1538 that shows that.
Is it just flash that cannot be written?
MCUdude
commented
10 months ago @stefanrueger I'm having a hard time getting the same error messages as earlier. It seems like the jtag2updi programmer fails with a different kind of error. I'll try to prep the AVR-EB using the pkobn_updi.
stefanrueger
commented
10 months ago to avoid irrecoverable failures [...] back up [
fuses] to a file and write back
@askn37 The AVRDUDE project likes avrdude.conf to describe the part close to its description in the data sheet or the .atdf files. Yes, there are risks of setting fuses to values one doesn't want or cannot recover. This comes with the territory of some individual fuses and, as a consequence, the fuses umbrella memory.
AVRDUDE enables backup and restoration of the full configuration state of modern chips via the fuses memory even though that entails risks. The manual warns in the description of the config terminal command: "It is quite possible, as is with direct writing to the underlying fuses and lock bits, to brick a part, i.e., make it unresponsive to further programming with the chosen programmer: here be dragons." I am sure the project would be amenable to a PR that adds similar warnings to other places.
@mcuee @MCUdude BTW, fuses as an explicit memory for the configuration state has been introduced for parts that have a UPDI interface (the "modern" parts). I like that concept and might suggest to introduce fuses for all other parts too. This enables backup and restoration of the configuration settings without having to know how many fuses a part has (and how they are called).
MCUdude
commented
10 months ago Let's focus on the AVR-EB
I'm having issues reading the fuses in terminal mode when using the pkobn_updi and PR #1538:
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -Ufuses:r:-:h
0x0,0x0,0x0,0xff,0xff,0xd0,0x7,0x0,0x0,0xff,0x3,0x0,0xff,0xff,0xff,0xff
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -Ufuse0:r:-:h
0x0
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -Ufuse1:r:-:h
0x0
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -Ufuse2:r:-:h
0xff
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -Ufuse5:r:-:h
0x3
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -Ufuse6:r:-:h
0xff
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -Ufuse7:r:-:h
0xff
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -Ufuse8:r:-:h
0x21
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -Ufusea:r:-:h
0xff,0xff
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -T 'read fuses'
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -T 'read fuse0'
0000 00 |. |
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -T 'read fuse1'
0000 00 |. |
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -T 'read fuse2'
0000 ff |. |
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -T 'read fuse5'
0000 03 |. |
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -T 'read fuse6'
0000 ff |. |
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -T 'read fuse7'
0000 ff |. |
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -T 'read fuse8'
0000 21 |! |
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -T 'read fusea'
0000 ff ff |.. |However, I'm not having any issues when using git main:
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -T 'read fuses'
0000 00 00 00 ff ff d0 07 00 00 ff 03 00 ff ff ff ff |................|EDIT:
Let me check if this is because I forgot to run make clean first.
EDIT2:
running make clean didn't help. PR #1538 breaks reading fuses in terminal mode on AVR-EBs.
Even -U fuse readings (see fusea output) is wrong:
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -Ufuses:r:-:h
0x0,0x0,0x0,0xff,0xff,0xd0,0x7,0x0,0x0,0xff,0x3,0x0,0xff,0xff,0xff,0xff
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -Ufusea:r:-:h
0xff,0xff@mcuee , @MCUdude , @stefanrueger
Important information. AVR16EB32's UPDI_SIB seems to return P:5. Please check with actual chip. After that, a new patch will be required. However, looking at the datasheet and ATDF, it is expected that it will be the same method as P:3, so it seems better to tentatively treat P:5 and P:3 equally.
[Source] https://github.com/avrdudes/avrdude/issues/1546#issuecomment-1785787992
[Related source files] "serialupdi.c" "updi_nvm.c" "updi_state.h" (And more)
[P.S. 1] JTAG2UPDI usually does not check UPDI_SIB. Switch NVMCTRLv0/2 by guessing from the page size. And there probably isn't any code for v3 yet. (To add SIB check to JTAG2UPDI, "DEDUCE_NVM_VERSION_FROM_SIB" macro definition and rebuild are required)
[P.S.2] "pkobn_updi = Curiosity nano (nEDBG) via UPDI" is running in Microchip's firmware, so the P:5 should know about it. If there is a problem with the memory map, the problem is most likely on the "avrdude" side.
PKOB nano support 1.13.715 (2023-10-25) https://packs.download.microchip.com From pack-status-202310252033.3108.xml NB: This toolpack supersedes and replaces version 1.12.711 which is now deprecated. FW5G-1305 Post-build processing of artifact to workaround MPLABX-8013 FW5G-1306 nEDBG 1.30.35 Firmware release process
askn37
commented
10 months ago @MCUdude
We have created a PR to continue this research. "serialupdi" should also allow the AVR_EB handling process to continue. Please try it.
dbuchwald
commented
10 months ago @stefanrueger sorry for delay in reply. The error message you are observing (avrdude warning: unsupported NVM type: 5, please update software) comes directly from the pymcuprog port, and is related to chip reporting NVM protocol version 5 which (at the time) has not been supported. Thing is, I don't really know if this is the right value (as @askn37 mentioned, ATDF file seems to indicate it should be NVM version 3), and even if it really is NVM v5, then the protocol doesn't seem to be documented. Maybe there is something wrong with the engineering samples batch?
I can see that fix proposal has already been posted, and I reviewed it.
If it turns out that new memory map and using NVM v5 as if it was NVM v3 doesn't work (and it might not), I will need to compare datasheets of working chips (like the EA family) against EB and see if there are any functional differences between them. Not having access to the actual device will slow things down probably, but it's not like we have other options anyway...
MCUdude
commented
10 months ago Thing is, I don't really know if this is the right value (as @askn37 mentioned, ATDF file seems to indicate it should be NVM version 3), and even if it really is NVM v5, then the protocol doesn't seem to be documented. Maybe there is something wrong with the engineering samples batch?
@xedbg probably knows whenever the AVR-EBs are NVM v3 or v5, or what the deal is. The date code on my AVR16EB32 is 2332 (week 32 year 2023), and the Curiosity Nano board it's soldered on says "2023.09.25", so they are both pretty fresh out of the oven.
I'll carry out some tests to see if the AVR-EB will work with PR #1549
xedbg
commented
10 months ago AVR EB:
pymcuprog.serialupdi.application - INFO - SIB: 'AVR P:5D:1-3M2 (A0.59B1D.0)'
also FYI: we are hoping to squeeze out an update to pymcuprog this sprint.
MCUdude
commented
10 months ago AVR EB: pymcuprog.serialupdi.application - INFO - SIB: 'AVR P:5D:1-3M2 (A0.59B1D.0)'
Good! This is exactly what I'm getting as well:
$ ./avrdude -cpkobn_updi -pavr16eb32 -qq -Usib:r:-:r
AVR P:5D:1-3M2 (A0.59B1D.0)Important information. AVR16EB32's UPDI_SIB seems to return P:5. Please check with actual chip. After that, a new patch will be required. However, looking at the datasheet and ATDF, it is expected that it will be the same method as P:3, so it seems better to tentatively treat P:5 and P:3 equally.
Are there any differences between NVM v3 and NVM v5 that we should take into account?
dbuchwald
commented
10 months ago Are there any differences between NVM v3 and NVM v5 that we should take into account?
This is very good question. @xedbg mentioned update to pymcuprog is coming - if it does provide support for NVM v5, I will be able to "copy-paste" the same thing to AVRDUDE, following the initial implementation. Otherwise we can try to compare datasheets and try to find discrepancies, but again, this is based on the assumptions that datasheets at this point will be correct and up-to-date.
mcuee
commented
10 months ago EDIT: The SerialUPDI programmer works great with the AVR64EA48, but has
NVM type 3: 24-bit, page oriented. The jtag2updi also struggles with the AVR64EA48, similar to how it behaved when trying to interact with the AVR16EB32. I don't think there's much we can do about the jtag2updi programmer, since this would require a firmware update.To summarize:
AVR-EA AVR-EB SerialUPDI ✅ ❌ jtag2updi ❌ ❌
@ElTangas
Just wondering if you can upgrade the jtag2updi FW (and maybe also avrdude codes) to support AVR EA and AVR EB. https://github.com/ElTangas/jtag2updi
askn37
commented
10 months ago Just wondering if you can upgrade the jtag2updi FW (and maybe also avrdude codes) to support AVR EA and AVR EB.
No, I'm sure you can write it... For reference, the firmware implementation of UPDI4AVR's "JTAGmkII compatible" AVR_EA (P:3) was completed half a year ago and is running very smoothly.
MCUdude
commented
10 months ago @askn37 so updi4avr is a drop-in replacement for the jtag2updi firmware that hasn't seen any updates recently?
askn37
commented
10 months ago We will explain the main points of the NVMCTRL algorithm for AVR_EA(P:3).
All memory reads on P:3 are compatible with P:2 (AVR_Dx). Flash address width is 24 bits. Others are 16bit.
Memory writing for P:3 is different from P:2. It's more like P:0. Because there is a hidden memory buffer. That is, after filling the buffer, we tell NVMCTRL to really write the memory. The difference with P:0 is that the flash address width is 24 bits instead of 16 bits. The NVMCTRL command table is also specific to P:3. Because of this, AVR-LIBC has made mistakes in the past.
Below, when writing a command to NVMCTRL, write CMD_NOCMD in advance and wait until the busy bit of NVMCTRL_STATUS becomes empty.
When writing to FLASH with P:3
When writing to EEPROM with P:3
Note
The USERROW of P:0 is EEPROM, but the USERROW of P:2 and P:3 is FLASH. Chip erase is not supported, so blocks must be erased and written in words before writing. However, terminal mode is a byte-by-byte access interface. So writing USERROW byte by byte to the unlocked device on P:2/P:3 from terminal mode requires a logic synthesis trick. (When writing in bulk with normal -U, it is not difficult if you also perform block erase as a set.)
askn37
commented
10 months ago @askn37 so updi4avr is a drop-in replacement for the jtag2updi firmware that hasn't seen any updates recently?
From avrdude, it can be treated as upward compatible with JTAG2UPDI. Works with old "jtagmkII_pdi + has_updi" or new "jtagmkii_updi + PM_UPDI" configuration files.
However, the chip running the firmware must be newer than the tinyAVR-2. The UPDI interface utilizes the single wire RS485 mode of the hardware UART. Therefore, this is not a fork or variant of JTAG2UPDI. The source code also doesn't match.
I used to be satisfied with mEDBG, but I had a job that required AVR_DB, so I created 24-bit compatible firmware, created a dedicated circuit, and created and wrote a bootloader myself. After repeated improvements, it is now possible to control the high voltage of AVR_EA. The reason I have so many bare chips is to verify my work. And the rival is "serialupdi". Well, because I always want to be fair...
"It's noble to extend a helping hand to your enemy, if only for a short while."
stefanrueger
commented
10 months ago extend a helping hand to your enemy
:smile: Yes, Open Source at its best is healthy co-petition (co-operation and competition). As you know, @askn37, AVRDUDE is quite modular, and you (or anyone else for that matter) are welcome to contribute -c programmers.
mcuee
commented
10 months ago I used to be satisfied with mEDBG, but I had a job that required AVR_DB, so I created 24-bit compatible firmware, created a dedicated circuit, and created and wrote a bootloader myself. After repeated improvements, it is now possible to control the high voltage of AVR_EA. The reason I have so many bare chips is to verify my work. And the rival is "serialupdi". Well, because I always want to be fair...
Indeed serialupdi is probably the way to go for hobbist users when it comes to UPDI parts. jtag2updi is of course another contender. For users who are willing to pay a bit more, I think Microchip SNAP may be the way to go. It is a pity that PICKit 4 is now considered obsolete.
For classic AVRs, usbasp may be the way to go for hobbist users who want to get started. Of course you can also use things like Arduino as ISP as well. For users who are willing to pay a bit more, maybe AVRISP mkII clone or Microchip SNAP is the way to go. Again it is a pity that PICKit 4 is now considered obsolete.
askn37
commented
10 months ago ＠mcuee
Indeed serialupdi is probably the way to go for hobbist users when it comes to UPDI parts.
This invention was revolutionary. It's very cheap and easy to make. Feel free to give it away to your friends for free. But there was another problem.
On the other hand, classic approaches like the STK500 version 1/2 protocol are simple on the host PC side. Basically, you can speak in your native language and let the adapter do the translation to his UPDI/PDI/TPI. Depending on the design, it is possible to maintain high communication quality. Those who create adapters are free to choose the method that works best for them. It can then be turned into a black box or its design can be made widely available for cloning. If you have someone who can handle the tedious task of updating firmware, you may want to ask that person to keep an eye on it. (I don't know if I can contact you or not)
dbuchwald
commented
10 months ago Again it is a pity that PICKit 4 is now considered obsolete.
Maybe this is not the right forum for it, but this is one of the problems I have with Microchip products - they become obsolete too often and too fast. This is probably irrelevant to corporate customers with deep pockets, but for hobbyists like myself this is showstopper.
To be fair, my whole involvement with AVRDUDE started with a hobbyist project based on 128DB64 chip, but I have never completed it, as the main issue is the availability of the chips and constant stream of "newer, better" chips which become obsolete before they get really available on the market. I don't want to spend months on writing software and designing schematic for something that simply can't be built and used by anyone else because the chip has been superseded by something no longer backwards compatible.
As for the UPDI - it seemed like a perfect solution, but it's a solution in the making. My concern is that when we finally reach some maturity level of NVM protocol it will get superseded by something "newer and better"...
Anyway, sorry for the rant.
mcuee
commented
10 months ago Maybe this is not the right forum for it, but this is one of the problems I have with Microchip products - they become obsolete too often and too fast. This is probably irrelevant to corporate customers with deep pockets, but for hobbyists like myself this is showstopper.
To be fair, the Microchip part of the current Microchip does not obsolete chips often -- for example, they still provide old PICs. The Atmel part of the current Microchip is not so well-known to keep parts alive as long as the Microchip part. Just a simple example, the first gen AT90 AVRs did not last long. Luckily I chose the right part (PIC16C72A) back in 1999 for a new project in my previous job. My colleagues in Germany liked AVR more at that time (and for sure I agreed with them that AVRs had a better architecture than PICs). Microchip still support PIC16C72A now -- just not recommended for new design. https://www.microchip.com/en-us/product/pic16c72a
On the development tool side, I think PICKit 4 is a bit unfortunate. Microchip did obsolete old tools more often compared to chips but I think usually not so fast.
In this word of 32bit MCUs (At work, we mainly use ARM Cortex MCUs now. Even Arduino Uno 4 is now based on ARM Cortex MCUs), I think we still need to pay respect to Microchip to continue the development of PICs and AVRs.
BTW, in my current job and previous job, the product life cycle is very long (it can be more than 30 years). So I am pretty careful in choosing parts. For sure, you can not avoid component obsolescences, but it is better to have less big redesigns which involves MCU changes.
The chip shortages in the past few years are probably not the norm either and indeed Microhip MCU lead time was super long, same for STM32.
askn37
commented
10 months ago @dbuchwald
As for the UPDI - it seemed like a perfect solution, but it's a solution in the making. My concern is that when we finally reach some maturity level of NVM protocol it will get superseded by something "newer and better"...
It is expected that the next 10 years or so will continue to be based on UPDI. Since there is only one wire, it is not possible to reduce the number of wires any further. Also note that the USART peripheral on modern AVRs can easily implement native host/guest for the UPDI protocol. This technology is derived from a low-speed, low-cost, single-wire communication standard for automotive applications. Microchip let the former ATMEL development team they had acquired use it. In addition to a regular CPU, all modern AVRs have a small, simple, and inexpensive sub-CPU dedicated to UPDI, and a sub-UART dedicated to UPDI with reduced circuitry. This quickly replaced the large, complex, and expensive PDI-specific logic circuits. That's probably why the wholesale price of chips has almost halved.
MPLAB SNAP
In Japan, prices have increased several times over the past few years. It's not cheap at all. We only offer low prices during the campaign period for new products. To support AVR_DA and later, a soldering iron must be prepared and modified. Also, just rewriting the firmware requires downloading dozens of GiB of his MPLAB. Since there is no insulating case, it is not suitable for children's education. Speaking of insulation, the PICkit4's decorative panels are unpainted and conduct electricity. If you put other exposed boards on top of it and turn it on, you'll be in trouble. (I did it. LIB rechargeable battery caught fire)
askn37
commented
10 months ago Anxiety about future product development
Why is AVR_DU on hold? It was a promising replacement for his outdated AT90USB. (With this, UPDI4AVR can be modified to replace USBASP.)
I don't understand why AVR_EA was created. There is no price difference with AVR_DB, but it is a mystery whether it is the same clock as the ****AVR generation.
However, one can imagine that his AVR_EB and derivative products based on it are specifically designed for certain large customers. They removed his TCA timer. Also equipped with a wave generator and new TCE/TCF. This is a much more complex circuit than his TCD for synchronous motor control, and it's hard to immediately think of what it could be used for. It feels a bit extravagant to incorporate it into hundreds of spotlights for stage lighting.
AVR_Ex appears to be an application-specific derivative series that replaces part of the PIC. The advantage is that it can be written in C/C++ and can also be easily written using assembly instructions such as PIC. It is much more reliable than ARM in terms of high temperature resistance. On the other hand, it is not very suitable for enthusiasts.
mcuee
commented
10 months ago Due to USB-CDC limitations, reliability above a certain speed cannot be expected. It is impossible for the response speed to be less than 1ms, and if you connect a hub, it will become slower and slower, and packet loss will occur frequently. Code without a retry loop will always have problems
Actually the moderin USB to Serial chip (dedicated IC like CH340x, FT232R, FT232H, FT2232H, CP2102, PL2303, etc) do not use USB CDC-ACM protocol in general. FT232H/FT2232H are capable of high speed USB.
And full speed USB (12Mbps line rate, but slower at real world) is good enough to go with 230400bps which is good enough for AVR programming. 1ms polling interval is an issue for USB interrupt endpoint (up to 64B/1ms) but not USB bulk endpoint (you can have up to 9 bulk packets within the 1ms USB frame --> 64B x 19 /ms= 1216B/1ms ). https://github.com/SpenceKonde/AVR-Guidance/blob/master/UPDI/jtag2updi.md
Even the low cost CH340x based serialupdi adapter can do 230,400 bps as per the above article (and I tested it as well).
xedbg
commented
10 months ago FYI an untested pymcuprog has been pushed to pypi-test: https://test.pypi.org/project/pymcuprog/3.16.7.38/ (its a wheel, but can be unzipped. basics work, but if there are obvious issues or glaring questions, please shout asap)
MCUdude
commented
10 months ago Thanks @xedbg!
For those who are interested, here are the source files: pymcuprog-3.16.7.38-py3-none-any.zip
It turns out that:
| NVM version | Chip family | File |
|---|---|---|
| 0 | tiny0/1/2, mega8 | nvmp0.py |
| 1 | ||
| 2 | AVR DA/DB/DD | nvmp2.py |
| 3 | AVR EA | nvmp3.py |
| 4 | AVR DU | nvmp4.py |
| 5 | AVR EB | nvmp5.py |
The only difference I can spot between version 3 and version 5 is the addition of NVMCTRLC:
$ git diff nvmp3.py nvmp5.py
diff --git a/nvmp3.py b/nvmp5.py
index 456ad1b..51e8dc1 100755
--- a/nvmp3.py
+++ b/nvmp5.py
@@ -1,21 +1,22 @@
"""
-NVM controller implementation for P:3.
+NVM controller implementation for P:5.
-Present on, for example, AVR EA
+Present on, for example, AVR EB
"""
from logging import getLogger
from .nvm import NvmUpdi
from .timeout import Timeout
from ..pymcuprog_errors import PymcuprogSerialUpdiNvmTimeout, PymcuprogSerialUpdiNvmError
-class NvmUpdiP3(NvmUpdi):
+class NvmUpdiP5(NvmUpdi):
"""
- Version P:3 UPDI NVM properties
+ Version P:5 UPDI NVM properties
"""
# NVM CTRL peripheral definition
NVMCTRL_CTRLA = 0x00
NVMCTRL_CTRLB = 0x01
+ NVMCTRL_CTRLC = 0x02
NVMCTRL_INTCTRL = 0x04
NVMCTRL_INTFLAGS = 0x05
NVMCTRL_STATUS = 0x06And NVMCTRL_CTRLC doesn't seem to be utilized anywhere...
hans@Bull:/mnt/c/Users/Hans/Downloads/pymcuprog-3.16.7.38-py3-none-any/pymcuprog$ grep -r NVMCTRL_CTRLC *
serialupdi/nvmp4.py: NVMCTRL_CTRLC = 0x02
serialupdi/nvmp5.py: NVMCTRL_CTRLC = 0x02There are, however, much longer diff between version 3 and version 4:
xedbg
commented
10 months ago "Versioning" in the SIB should not really be interpreted as "linear progression from the previous" - the Dx and Ex families have some fundamental differences (like page vs word-oriented), and the order in which these family members have been designed makes the SIB versioning more like "odds vs evens". Just how it is :)
askn37
commented
10 months ago 11. NVMCTRL - Nonvolatile Memory Controller
11.5 Register Description
11.5.3 Control C
Name: CTRLC
Offset: 0x02
Reset: 0x0
Property: Configuration Change Protection
Reset: x x x x x x 0 0
Bit 1 – BOOTROWWP Boot Row Write Protection
- Writing this bit to ‘1’ prevents further updates to the Boot Row. Only a Reset can clear this bit.
Bit 0 – UROWWP User Row Write Protection
- Writing this bit to ‘1’ prevents further updates to the User Row. Only a Reset can clear this bit.I think this Issue has undergone a bit of a shift but hope that once #1549 is merged we can close it
mcuee
commented
10 months ago I think this Issue has undergone a bit of a shift but hope that once #1549 is merged we can close it
I agree.
From here
@MCUdude found an issue with AVR EB support.