Comments (43)
dbuchwald
commented on August 24, 2024
2
@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...
from avrdude.
MCUdude
commented on August 24, 2024
1
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?
from avrdude.
askn37
commented on August 24, 2024
1
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. . .
from avrdude.
askn37
commented on August 24, 2024
1
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).
from avrdude.
MCUdude
commented on August 24, 2024
1
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 | ❌ | ❌ |
from avrdude.
MCUdude
commented on August 24, 2024
1
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
from avrdude.
askn37
commented on August 24, 2024
1
@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] #1546 (comment)
[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
from avrdude.
MCUdude
commented on August 24, 2024
1
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
from avrdude.
xedbg
commented on August 24, 2024
1
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.
from avrdude.
dbuchwald
commented on August 24, 2024
1
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.
from avrdude.
askn37
commented on August 24, 2024
1
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.
from avrdude.
askn37
commented on August 24, 2024
1
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
- Please clear the target using chip erase or flash block erase in advance.
- Write V3_CMD_FLPBCLR to NVMCTRL to empty the flash memory buffer.
- Write groups of "words" directly into memory blocks using 24-bit addresses + SPM. (offset 0x800000)
- Writes NVM_V3_CMD_FLPW to NVMCTRL. The CPU will stop for a moment.
- If necessary, set CMD_NOCMD back to NVMCTRL to complete writing one flash block.
When writing to EEPROM with P:3
- Write V3_CMD_EEPBCLR to NVMCTRL to empty the EEPROM memory buffer. EEPROM can erase and change bytes with a single command.
- Write a group of "bytes" to an EEPROM block using a 16-bit address + ST.
- Write V3_CMD_EEPERW to NVMCTRL. The CPU will stop for a moment.
- If necessary, set CMD_NOCMD back to NVMCTRL to complete writing one EEPROM block.
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.)
from avrdude.
askn37
commented on August 24, 2024
1
@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."
from avrdude.
stefanrueger
commented on August 24, 2024
1
extend a helping hand to your enemy
😄 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.
from avrdude.
askn37
commented on August 24, 2024
1
＠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.
- Host PC must speak his UPDI protocol directly. Therefore, only people with limited programming ability on the host PC can write controller programs. Supporting more platforms requires gathering more human resources and testing and debugging capabilities. This is not cheap.
- UPDI open drain line control requires at least one resistor or diode. This prevents the serial interface from being used properly. Additional circuitry and different control methods are required to coexist with the original UART application. One example is DTR/RTS control that incorporates the concept of ESP32. However, in the absence of a unified view, different and contradictory approaches have emerged. Some use this for high voltage pulse triggers. (please be surprised)
- 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.
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)
from avrdude.
dbuchwald
commented on August 24, 2024
1
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.
from avrdude.
askn37
commented on August 24, 2024
1
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)
from avrdude.
askn37
commented on August 24, 2024
1
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.
from avrdude.
xedbg
commented on August 24, 2024
1
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)
from avrdude.
MCUdude
commented on August 24, 2024
1
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 = 0x02
There are, however, much longer diff between version 3 and version 4:
diff nvmp3.py nvmp4.py
$ git diff nvmp3.py nvmp4.py
diff --git a/nvmp3.py b/nvmp4.py
index 456ad1b..4f3567a 100755
--- a/nvmp3.py
+++ b/nvmp4.py
@@ -1,21 +1,22 @@
"""
-NVM controller implementation for P:3.
+NVM controller implementation for P:4.
-Present on, for example, AVR EA
+Present on, for example, AVR DU
"""
from logging import getLogger
from .nvm import NvmUpdi
from .timeout import Timeout
from ..pymcuprog_errors import PymcuprogSerialUpdiNvmTimeout, PymcuprogSerialUpdiNvmError
-class NvmUpdiP3(NvmUpdi):
+class NvmUpdiP4(NvmUpdi):
"""
- Version P:3 UPDI NVM properties
+ Version P:4 UPDI NVM properties
"""
# NVM CTRL peripheral definition
NVMCTRL_CTRLA = 0x00
NVMCTRL_CTRLB = 0x01
+ NVMCTRL_CTRLC = 0x02
NVMCTRL_INTCTRL = 0x04
NVMCTRL_INTFLAGS = 0x05
NVMCTRL_STATUS = 0x06
@@ -25,14 +26,11 @@ class NvmUpdiP3(NvmUpdi):
# CTRLA commands
NVMCMD_NOCMD = 0x00
NVMCMD_NOOP = 0x01
- NVMCMD_FLASH_PAGE_WRITE = 0x04
- NVMCMD_FLASH_PAGE_ERASE_WRITE = 0x05
+ NVMCMD_FLASH_WRITE = 0x02
NVMCMD_FLASH_PAGE_ERASE = 0x08
- NVMCMD_FLASH_PAGE_BUFFER_CLEAR = 0x0F
- NVMCMD_EEPROM_PAGE_WRITE = 0x14
- NVMCMD_EEPROM_PAGE_ERASE_WRITE = 0x15
- NVMCMD_EEPROM_PAGE_ERASE = 0x17
- NVMCMD_EEPROM_PAGE_BUFFER_CLEAR = 0x1F
+ NVMCMD_EEPROM_WRITE = 0x12
+ NVMCMD_EEPROM_ERASE_WRITE = 0x13
+ NVMCMD_EEPROM_BYTE_ERASE = 0x18
NVMCMD_CHIP_ERASE = 0x20
NVMCMD_EEPROM_ERASE = 0x30
@@ -42,7 +40,6 @@ class NvmUpdiP3(NvmUpdi):
STATUS_EEPROM_BUSY_bp = 0
STATUS_FLASH_BUSY_bp = 1
-
def __init__(self, readwrite, device):
NvmUpdi.__init__(self, readwrite, device)
self.logger = getLogger(__name__)
@@ -51,7 +48,7 @@ class NvmUpdiP3(NvmUpdi):
"""
Does a chip erase using the NVM controller
- Note that on locked devices this is not possible and the ERASE KEY has to be used instead, see the unlock method
+ Note that on locked devices this it not possible and the ERASE KEY has to be used instead
"""
self.logger.debug("Chip erase using NVM CTRL")
@@ -65,9 +62,9 @@ class NvmUpdiP3(NvmUpdi):
# And wait for it
status = self.wait_nvm_ready()
- # Remove command
+ # Remove command from NVM controller
+ self.logger.debug("Clear NVM command")
self.execute_nvm_command(self.NVMCMD_NOCMD)
-
if not status:
raise PymcuprogSerialUpdiNvmTimeout("Timeout waiting for NVM controller to be ready after chip erase")
@@ -85,21 +82,22 @@ class NvmUpdiP3(NvmUpdi):
if not self.wait_nvm_ready():
raise PymcuprogSerialUpdiNvmTimeout("Timeout waiting for NVM controller to be ready before flash page erase")
+ # Erase command
+ self.execute_nvm_command(self.NVMCMD_FLASH_PAGE_ERASE)
+
# Dummy write
self.readwrite.write_data(address, [0xFF])
- # Erase
- self.execute_nvm_command(self.NVMCMD_FLASH_PAGE_ERASE)
-
# And wait for it
status = self.wait_nvm_ready()
- # Remove command
+ # Remove command from NVM controller
+ self.logger.debug("Clear NVM command")
self.execute_nvm_command(self.NVMCMD_NOCMD)
-
if not status:
raise PymcuprogSerialUpdiNvmTimeout("Timeout waiting for NVM controller to be ready after flash page erase")
+
def erase_eeprom(self):
"""
Erase EEPROM memory only
@@ -116,12 +114,13 @@ class NvmUpdiP3(NvmUpdi):
# And wait for it
status = self.wait_nvm_ready()
- # Remove command
+ # Remove command from NVM controller
+ self.logger.debug("Clear NVM command")
self.execute_nvm_command(self.NVMCMD_NOCMD)
-
if not status:
raise PymcuprogSerialUpdiNvmTimeout("Timeout waiting for NVM controller to be ready after EEPROM erase")
+
def erase_user_row(self, address, size=0):
"""
Erase User Row memory only
@@ -131,11 +130,9 @@ class NvmUpdiP3(NvmUpdi):
:param size: Size of user row
:type size: int, optional, not used for this variant
"""
- self.logger.debug("Erase user row")
-
# size is not used for this NVM version
_dummy = size
- # On this NVM version user row is implemented as FLASH
+ # On this NVM version user row is implemented as flash
return self.erase_flash_page(address)
def write_flash(self, address, data):
@@ -158,20 +155,40 @@ class NvmUpdiP3(NvmUpdi):
:param data: data to write
:type data: list of bytes
"""
- # On this NVM variant user row is implemented as FLASH
- return self.write_nvm(address, data, use_word_access=True)
+ # On this NVM variant user row is implemented as Flash
+ return self.write_nvm(address, data, use_word_access=False)
def write_eeprom(self, address, data):
"""
- Write data to EEPROM
+ Writes data to NVM (EEPROM)
:param address: address to write to
:type address: int
:param data: data to write
:type data: list of bytes
"""
- return self.write_nvm(address, data, use_word_access=False,
- nvmcommand=self.NVMCMD_EEPROM_PAGE_ERASE_WRITE)
+ nvm_command = self.NVMCMD_EEPROM_ERASE_WRITE
+
+ # Check that NVM controller is ready
+ if not self.wait_nvm_ready():
+ raise PymcuprogSerialUpdiNvmTimeout("Timeout waiting for NVM ready before command write")
+
+ # Write the command to the NVM controller
+ self.logger.debug("NVM EEPROM erase/write command")
+ self.execute_nvm_command(nvm_command)
+
+ # Write the data
+ self.readwrite.write_data(address, data)
+
+ # Wait for NVM controller to be ready again
+ status = self.wait_nvm_ready()
+ # Remove command from NVM controller
+ self.logger.debug("Clear NVM command")
+ self.execute_nvm_command(self.NVMCMD_NOCMD)
+
+ if not status:
+ raise PymcuprogSerialUpdiNvmTimeout("Timeout waiting for NVM ready after data write")
+
def write_fuse(self, address, data):
"""
@@ -182,14 +199,14 @@ class NvmUpdiP3(NvmUpdi):
:param data: data to write
:type data: list of bytes
"""
+ # Fuses are EEPROM-based in this variant
return self.write_eeprom(address, data)
- def write_nvm(self, address, data, use_word_access, nvmcommand=NVMCMD_FLASH_PAGE_WRITE):
+ def write_nvm(self, address, data, use_word_access=True):
"""
- Writes a page of data to NVM
+ Writes data to NVM.
- By default the PAGE_WRITE command is used, which requires that the page is already erased.
- By default word access is used (required for flash)
+ This version of the NVM block has no page buffer, so words are written directly.
:param address: address to write to
:type address: int
@@ -197,40 +214,33 @@ class NvmUpdiP3(NvmUpdi):
:type data: list of bytes
:param use_word_access: True for 16-bit writes (eg: flash)
:type use_word_access: bool, defaults to True
- :param nvmcommand: command to use for commit
- :type nvmcommand: int, defaults to NVMCMD_PAGE_WRITE
:raises: PymcuprogSerialUpdiNvmTimeout if a timeout occurred
:raises: PymcuprogSerialUpdiNvmError if an error condition is encountered
"""
+ nvm_command = self.NVMCMD_FLASH_WRITE
# Check that NVM controller is ready
if not self.wait_nvm_ready():
raise PymcuprogSerialUpdiNvmTimeout("Timeout waiting for NVM controller to be ready before page buffer clear")
- # Clear the page buffer
- self.logger.debug("Clear page buffer")
- self.execute_nvm_command(self.NVMCMD_FLASH_PAGE_BUFFER_CLEAR)
-
- # Wait for NVM controller to be ready
- if not self.wait_nvm_ready():
- raise PymcuprogSerialUpdiNvmTimeout("Timeout waiting for NVM controller to be ready after page buffer clear")
+ # Write the command to the NVM controller
+ self.logger.debug("NVM write command")
+ self.execute_nvm_command(nvm_command)
- # Load the page buffer by writing directly to location
+ # Write the data
if use_word_access:
self.readwrite.write_data_words(address, data)
else:
self.readwrite.write_data(address, data)
- # Write the page to NVM, maybe erase first
- self.logger.debug("Committing data")
- self.execute_nvm_command(nvmcommand)
-
# Wait for NVM controller to be ready again
- if not self.wait_nvm_ready():
- raise PymcuprogSerialUpdiNvmTimeout("Timeout waiting for NVM controller to be ready after page write")
+ status = self.wait_nvm_ready()
- # Remove command
+ # Remove command from NVM controller
+ self.logger.debug("Clear NVM command")
self.execute_nvm_command(self.NVMCMD_NOCMD)
+ if not status:
+ raise PymcuprogSerialUpdiNvmTimeout("Timeout waiting for NVM controller to be ready after data write")
def wait_nvm_ready(self, timeout_ms=100):
"""from avrdude.
stefanrueger
commented on August 24, 2024
1
I think this Issue has undergone a bit of a shift but hope that once #1549 is merged we can close it
from avrdude.
askn37
commented on August 24, 2024
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.
from avrdude.
stefanrueger
commented on August 24, 2024
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:
from avrdude.
stefanrueger
commented on August 24, 2024
| 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
from avrdude.
askn37
commented on August 24, 2024
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.
from avrdude.
stefanrueger
commented on August 24, 2024
@MCUdude Please try writing 0x2 to the 2-byte pdicfg fuse following the procedure in the datasheet and see whether that works.
from avrdude.
mcuee
commented on August 24, 2024
Better play safe in this case.
from avrdude.
MCUdude
commented on August 24, 2024
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.
from avrdude.
stefanrueger
commented on August 24, 2024
OK, understood; easy for me to make suggestions that might brick other people's parts 😮
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).
from avrdude.
MCUdude
commented on August 24, 2024
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.
Verbose output:
$ ./avrdude -cserialupdi -pavr16eb32 -P ch340 -vvvv
avrdude: Version 7.2-20230720
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /Users/hans/Downloads/avrdude-terminal/src/avrdude.conf
User configuration file is /Users/hans/.avrduderc
Using Port : /dev/cu.usbserial-1410
Using Programmer : serialupdi
avrdude: opening serial port ...
avrdude: sending 1 bytes [0x00]
avrdude: send: . [00]
avrdude: recv: . [00]
AVR Part : AVR16EB32
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse0 wdtcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse1 bodcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse2 osccfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse5 syscfg0 0 0 0 0 no 1 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse6 syscfg1 0 0 0 0 no 1 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse7 codesize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse8 bootsize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuses 0 0 0 0 no 16 16 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
lock 0 0 0 0 no 4 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
prodsig sigrow 0 0 0 0 no 128 128 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
tempsense 0 0 0 0 no 4 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
sernum 0 0 0 0 no 16 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
userrow usersig 0 0 0 0 no 64 64 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
data 0 0 0 0 no 0 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
io 0 0 0 0 no 4160 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
sib 0 0 0 0 no 32 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 0 0 0 0 no 512 8 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
flash 0 0 0 0 no 16384 64 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fusea pdicfg 0 0 0 0 no 2 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
bootrow 0 0 0 0 no 64 64 0 0 0 0x00 0x00
Programmer Type : serialupdi
Description : SerialUPDI
avrdude: STCS 0x08 to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x08]
avrdude: send: U [55] . [c3] . [08]
avrdude: recv: U [55] . [c3] . [08]
avrdude: STCS 0x80 to address 0x02
avrdude: sending 3 bytes [0x55, 0xc2, 0x80]
avrdude: send: U [55] . [c2] . [80]
avrdude: recv: U [55] . [c2] . [80]
avrdude: LDCS from 0x00
avrdude: sending 2 bytes [0x55, 0x80]
avrdude: send: U [55] . [80]
avrdude: recv: U [55] . [80]
avrdude: recv: 0 [30]
avrdude: received 1 bytes [0x30]
avrdude: UDPI init OK
avrdude: UPDI link initialization OK
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: send: U [55] . [8b]
avrdude: recv: U [55] . [8b]
avrdude: recv: . [82]
avrdude: received 1 bytes [0x82]
avrdude: sending 2 bytes [0x55, 0xe6]
avrdude: send: U [55] . [e6]
avrdude: recv: U [55] . [e6]
avrdude: recv: A [41] V [56] R [52] [20] [20] [20] [20] [20] P [50] : [3a] 5 [35] D [44] : [3a] 1 [31] - [2d] 3 [33] M [4d] 2 [32] [20] ( [28] A [41] 0 [30] . [2e] 5 [35] 9 [39] B [42] 1 [31] D [44] . [2e] 0 [30] ) [29] . [00]
avrdude: received 32 bytes [0x41, 0x56, 0x52, 0x20, 0x20, 0x20, 0x20, 0x20, 0x50, 0x3a, 0x35, 0x44, 0x3a, 0x31, 0x2d, 0x33, 0x4d, 0x32, 0x20, 0x28, 0x41, 0x30, 0x2e, 0x35, 0x39, 0x42, 0x31, 0x44, 0x2e, 0x30, 0x29, 0x00]
avrdude: received SIB: [AVR P:5D:1-3M2 (A0.59B1D.0)]
avrdude: Device family ID: AVR
avrdude: NVM interface: P:5
avrdude: Debug interface: D:1
avrdude: PDI oscillator: 3M2
avrdude: Extra information: (A0.59B1D.0)
avrdude serialupdi_decode_sib() [serialupdi.c:169] warning: unsupported NVM type: 5, please update software
avrdude serialupdi_initialize() [serialupdi.c:631] error: decode SIB_INFO failed
avrdude main() [main.c:1399] 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: leaving NVM programming mode
avrdude: sending reset request
avrdude: STCS 0x59 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude: send: U [55] . [c8] Y [59]
avrdude: recv: U [55] . [c8] Y [59]
avrdude: sending release reset request
avrdude: STCS 0x00 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x00]
avrdude: send: U [55] . [c8] . [00]
avrdude: recv: U [55] . [c8] . [00]
avrdude: STCS 0x0C to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x0c]
avrdude: send: U [55] . [c3] . [0c]
avrdude: recv: U [55] . [c3] . [0c]
avrdude done. Thank you.
from avrdude.
stefanrueger
commented on August 24, 2024
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_PARAMETER
messages come from. I pushed a commit onto PR #1538 that shows that.
Is it just flash that cannot be written?
from avrdude.
MCUdude
commented on August 24, 2024
@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.
$ ./avrdude -cjtag2updi -pavr64ea48 -P ch340 -Uflash:w:0x55_64B.hex:i -v
avrdude: Version 7.2-20230720
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /Users/hans/Downloads/avrdude-terminal/src/avrdude.conf
User configuration file is /Users/hans/.avrduderc
Using Port : /dev/cu.usbserial-1410
Using Programmer : jtag2updi
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
boot-loader FW version: 1
firmware version: 6.00
hardware version: 1
S_MCU:
boot-loader FW version: 1
firmware version: 6.00
hardware version: 1
Serial number: 00:00:00:00:00:00
Device ID: JTAGICE mkII
AVR Part : AVR64EA48
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse0 wdtcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse1 bodcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse2 osccfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse5 syscfg0 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse6 syscfg1 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse7 codesize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse8 bootsize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuses 0 0 0 0 no 16 16 0 0 0 0x00 0x00
lock 0 0 0 0 no 4 1 0 0 0 0x00 0x00
prodsig sigrow 0 0 0 0 no 128 128 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
tempsense 0 0 0 0 no 4 1 0 0 0 0x00 0x00
sernum 0 0 0 0 no 16 1 0 0 0 0x00 0x00
userrow usersig 0 0 0 0 no 64 64 0 0 0 0x00 0x00
data 0 0 0 0 no 0 1 0 0 0 0x00 0x00
io 0 0 0 0 no 4160 1 0 0 0 0x00 0x00
sib 0 0 0 0 no 32 1 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 512 8 0 0 0 0x00 0x00
flash 0 0 0 0 no 65536 128 0 0 0 0x00 0x00
Programmer Type : JTAGMKII_UPDI
Description : JTAGv2 to UPDI bridge
M_MCU HW version: 1
M_MCU FW version: 6.00
S_MCU HW version: 1
S_MCU FW version: 6.00
Serial number : 00:00:00:00:00:00
avrdude: silicon revision: 2.0
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e961e (probably avr64ea48)
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_64B.hex:i
avrdude: reading input file 0x55_64B.hex for flash
with 64 bytes in 1 section within [0, 0x3f]
using 1 page and 64 pad bytes
avrdude: writing 64 bytes flash ...
Writing | -------------------------------------------------- | 0% 0.15 s
avrdude jtagmkII_paged_write() error: bad response to write memory command: RSP_NO_TARGET_POWER
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
***failed;
avrdude: 64 bytes of flash written
avrdude: verifying flash memory against 0x55_64B.hex
Reading | -------------------------------------------------- | 0% 0.01 s
avrdude jtagmkII_paged_load() error: bad response to read memory command: RSP_NO_TARGET_POWER
avrdude jtagmkII_read_byte() error: bad response to read memory command: RSP_NO_TARGET_POWER
avrdude avr_read_mem() error: unable to read byte at address 0x0000
avrdude avr_read_mem() error: read operation not supported for memory flash
avrdude do_op() error: unable to read all of flash memory, rc=-2
avrdude jtagmkII_program_disable() error: bad response to leave progmode command: RSP_NO_TARGET_POWER
avrdude jtagmkII_close() error: bad response to GO command: RSP_NO_TARGET_POWER
avrdude jtagmkII_close() error: bad response to sign-off command: RSP_NO_TARGET_POWER
avrdude done. Thank you.
from avrdude.
stefanrueger
commented on August 24, 2024
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).
from avrdude.
askn37
commented on August 24, 2024
We have created a PR to continue this research. "serialupdi" should also allow the AVR_EB handling process to continue. Please try it.
from avrdude.
MCUdude
commented on August 24, 2024
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?
from avrdude.
mcuee
commented on August 24, 2024
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 | ❌ | ❌ |
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
from avrdude.
MCUdude
commented on August 24, 2024
@askn37 so updi4avr is a drop-in replacement for the jtag2updi firmware that hasn't seen any updates recently?
from avrdude.
mcuee
commented on August 24, 2024
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.
from avrdude.
mcuee
commented on August 24, 2024
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.
from avrdude.
mcuee
commented on August 24, 2024
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).
from avrdude.
xedbg
commented on August 24, 2024
"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 :)
from avrdude.
askn37
commented on August 24, 2024
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.
from avrdude.
mcuee
commented on August 24, 2024
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 avrdude.
Related Issues (20)
- Error when using linuxgpio HOT 3
- v7.3 detected as malware HOT 1
- Add support for libgpiod v2+ API HOT 2
- "jtag2 is not a unique start of a programmer name"
- `-F` option not honored
- Add support for more AVR-DU parts HOT 2
- Add support for emscripten HOT 6
- Trouble with Raspberry pi 5 HOT 13
- linuxgpio sysfs fallback improvement to deal with shifted GPIO numbering in new kernel version HOT 1
- usbasp_write_byte in TPI mode; all writes have to be done at page level HOT 15
- cmake enabling LINUXGPIO on ubuntu 20.04 fails HOT 4
- arduino uno atmga328p HOT 2
- macOS github action failed. HOT 9
- CMake improvement -- using pkg-find to find the libraries HOT 1
- format mismatch warnings HOT 3
- Misleading error message: cannot find programmer id
- custom programmer broken in v7.3 HOT 4
- ATtiny11 does not have EEPROM
- Misleading error message when specifying wrong AVR-Ex part HOT 11
- Multi-memory files HOT 13
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from avrdude.