Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add AVR-EB parts #1491

Merged
merged 7 commits into from
Aug 27, 2023
Merged

Add AVR-EB parts #1491

merged 7 commits into from
Aug 27, 2023

Conversation

stefanrueger
Copy link
Collaborator

Fixes #1489

This is a quick shot at adding the bootrow memory and pdicfg fuse. Needs a careful review. @MCUdude?

It is not clear how the bootrow memory should be read using serial updi.I don't have the data sheets. @dbuchwald?

Here is an idea how to add bootrow for the various jtagXX_updi programmers:
bootrow

Is that a sensible approach, @MCUdude? Would need to be done dozen times.

@stefanrueger
Copy link
Collaborator Author

The new fuse pdicfg consists of two bytes which contain two configuration values:

  • nvmlevel with a bitmask of 0x03 that specifies the level to which non-volatile memory is protected
  • nvmkey requiring a 12-bit pattern in the mask 0xfff0 to activate the protection

Two-byte fuses are a novelty for AVRDUDE. pdicfg sits at offset 10 of the fuses memory, ie, if someone writes to location 11 in fuses it should alter the high-byte of the pdicfg fuse. This PR keeps with the tradition of also naming fuses fuseX with X now being a hex digit in in 0-9a-f. Below a little demo of these effects in the terminal with -c dryrun. No doubt @mcuee finds a way to break the code for two-byte fuses, though!

$ avrdude -cdryrun -pavr16eb32 -t

avrdude> wr pdi 0 0xb452
Writing | ################################################## | 100% 0.00 s 

avrdude> wr pdi 1 0xb4
Writing | ################################################## | 100% 0.00 s 

avrdude> c nvm -vv
# Mask 0x03 of pdicfg: NVM protection level
config nvmlevel=nvmaccdis # 2 = 0b10 = 0x02>>0 (NVM access through UPDI disabled)

# Mask 0xfff0 of pdicfg: NVM protection activation key
config nvmkey=nvmact # 0x0b45 = 0xb450>>4 (NVM protection active)

avrdude> w fuses 11 0x55
Writing | ################################################## | 100% 0.00 s 

avrdude> c nvm -vv
# Mask 0x03 of pdicfg: NVM protection level
config nvmlevel=nvmaccdis # 2 = 0b10 = 0x02>>0 (NVM access through UPDI disabled)

# Mask 0xfff0 of pdicfg: NVM protection activation key
config nvmkey=0x00000555 # reserved = 0x5550>>4

avrdude> w fuses 11 0xb4
Writing | ################################################## | 100% 0.00 s 

avrdude> c nvmkey -vv
# Mask 0xfff0 of pdicfg: NVM protection activation key
config nvmkey=nvmact # 0x0b45 = 0xb450>>4 (NVM protection active)

avrdude> d pdi
Reading | ################################################## | 100% 0.00 s 
0000  52 b4                                             |R.              |

avrdude> c -f nvm*
###########################################################
# Fuse pdicfg/fusea value 0xb452 (factory 0x03) mask 0xfff3
#
config nvmlevel=nvmaccdis # 2
config nvmkey=nvmact # 0x0b45

avrdude> w pdicfg 0x0003
avrdude error: (write) no address specified for fusea data 0x0003

avrdude> w pdicfg 0 0x0003
Writing | ################################################## | 100% 0.00 s 

avrdude> c nvm*
config nvmlevel=basic # 3
config nvmkey=notact # 0x0000

@MCUdude
Copy link
Collaborator

MCUdude commented Aug 15, 2023

With this many differences compared to the AVR-EA series we might need a sample chip or two before this can be merged. Bare chips can't be purchased from authorized distributors yet, but perhaps @xedbg has a chip that can be borrowed?

Microchip has only published information about the AVR16EB chips, but their AVR-EB product brief page reviles that there will be 8 and 32 kiB versions as well. I'll assume all we need to know would be their 3-byte signature.

@xedbg
Copy link

xedbg commented Aug 15, 2023

@MCUdude Export / shipping compliance is something that we can't take lightly these days, so even though its 'around the corner' we are subject to the same regulations, so a sample is not something I can do at this stage, I'm afraid. (not sure a CNANO connected to a personal minecraft server with VPN access token would be worth the effort?)
I would not hold up on those 8k and 32k variants - I can plausibly come up with a list of IDs with a 90% certainty, if this will help... but I think its best to stick with those known 16k parts.

@stefanrueger
Copy link
Collaborator Author

stefanrueger commented Aug 15, 2023 •
edited
Loading

This PR is what I call predictive programming, ie, going with the published info we have (.atdf), which will require most of the changes here. Maybe @xedbg can test whether this PR can cope with the pdicfg fuse using a real part? No problem of not, we can certainly wait to test this out. @MCUdude I don't think there is a regression in this PR, so I'd prefer to review & merge now, and update later, if needed, when the part is released.

@xedbg: Is the use and behaviour of the bootrow memory in the public domain? The atdf file ascribes it the same type as userrow (see below). Hence my assumption that it contains a page worth of additional data that won't be erased through chip erase. Will it need to be programmed in the same way as userrow, ie, using a key when the device is locked?

Here the memory info from the .atdf

  <memory-segment exec="0" name="IO" rw="RW" size="0x103F" start="0x00" type="io"/>
  <memory-segment exec="0" name="LOCKBITS" pagesize="0x4" rw="RW" size="0x04" start="0x1040" type="lockbits"/>
  <memory-segment exec="0" name="FUSES" pagesize="0x8" rw="RW" size="0x10" start="0x1050" type="fuses"/>
  <memory-segment exec="0" name="SIGNATURES" pagesize="0x80" rw="R" size="0x03" start="0x1080" type="signatures"/>
  <memory-segment exec="0" name="PROD_SIGNATURES" pagesize="0x80" rw="R" size="0x7D" start="0x1083" type="signatures"/>
  <memory-segment exec="0" name="BOOTROW" pagesize="0x40" rw="RW" size="0x40" start="0x1100" type="user_signatures"/>
  <memory-segment exec="0" name="USER_SIGNATURES" pagesize="0x40" rw="RW" size="0x40" start="0x1200" type="user_signatures"/>
  <memory-segment exec="0" name="EEPROM" pagesize="0x8" rw="RW" size="0x200" start="0x1400" type="eeprom"/>
  <memory-segment exec="0" name="INTERNAL_SRAM" rw="RW" size="0x800" start="0x7800" type="ram"/>
  <memory-segment exec="0" name="MAPPED_PROGMEM" pagesize="0x40" rw="RW" size="0x4000" start="0x8000" type="other"/>
  <memory-segment exec="1" name="PROGMEM" pagesize="0x40" rw="RW" size="0x4000" start="0x00" type="flash"/>
  <memory-segment exec="1" name="PROGMEM_NRWW" pagesize="0x40" rw="RW" size="0x1000" start="0x00" type="flash"/>
  <memory-segment exec="1" name="PROGMEM_RWW" pagesize="0x40" rw="RW" size="0x3000" start="0x1000" type="flash"/>

BTW, I am guessing the IO memory will have the size 0x1040 not 0x103F. This is probably wrong in all AVR-Dx and AVR-Ex .atdf's. Any chance to get someone to correct this? I still don't know how to submit an issue such as this one.

@mcuee mcuee added the enhancement New feature or request label Aug 17, 2023
@xedbg
Copy link

xedbg commented Aug 21, 2023

@stefanrueger - bootrow is a single page which is only accessible (from the MCU) to code running in the boot area. When the device is unlocked, UPDI has full read/write access, but when the device is locked UPDI has no access (unlike userrow there is no 'special' way to re-write it from UPDI)

@stefanrueger
Copy link
Collaborator Author

@xedbg Thanks - vvv useful. I have updated the documentation.

@MCUdude I was wondering whether you could eyeball the changes in this PR against regression and perhaps test whether UPDI programming still works with other modern chips. I would then merge this PR as the structural changes in AVRDUDE would defo be needed for 16 fuses (not 10) and for the bootrow cache in the terminal.

I imagine the actual UPDI progamming will be a relatively simple change in serialupdi.c when someone has the part.

@mcuee
Copy link
Collaborator

mcuee commented Aug 27, 2023

Simple test under Windows.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1491 -C .\avrdude_pr1491.conf -c dryrun -p avr16eb32 -t
avrdude_pr1491: AVR device initialized and ready to accept instructions
avrdude_pr1491: device signature = 0x1e943e (probably avr16eb32)

avrdude_pr1491: processing -t interactive terminal

avrdude> part
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
  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
  tempsense               0     0     0    0 no          2    1      0     0     0 0x00 0x00
  signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00
  prodsig                 0     0     0    0 no        125  125      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      16384   64      0     0     0 0x00 0x00
  bootrow                 0     0     0    0 no         64   64      0     0     0 0x00 0x00
  fusea       pdicfg      0     0     0    0 no          2    1      0     0     0 0x00 0x00

avrdude> dump fuses
Reading | ################################################## | 100% 0.04 s
0000  00 00 00 ff ff d0 07 00  00 ff 03 00 ff ff ff ff  |................|
avrdude> dump fusea
Reading | ################################################## | 100% 0.01 s
0000  03 00
avrdude> c nvm*
config nvmlevel=basic # 3
config nvmkey=notact # 0x0000                                            |..              |
avrdude> dump sib
Reading | ################################################## | 100% 0.09 s
0000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
avrdude> dump fuse7
Reading | ################################################## | 100% 0.01 s
0000  00                                                |.               |
avrdude> dump fuse8
Reading | ################################################## | 100% 0.00 s
0000  00                                                |.               |
avrdude> dump bootrow
Reading | ################################################## | 100% 0.17 s
0000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
avrdude> config nvmkey -vv
# Mask 0xfff0 of pdicfg: NVM protection activation key
config nvmkey=notact # 0x0000 = 0b000000000000 = 0x00>>4 (not active)
avrdude> write pdicfg 0 0xb452
Writing | ################################################## | 100% 0.01 s
avrdude> write pdicfg 1 0xb4
Writing | ################################################## | 100% 0.00 s
avrdude> config nvmkey -vv
# Mask 0xfff0 of pdicfg: NVM protection activation key
config nvmkey=nvmact # 0x0b45 = 0xb450>>4 (NVM protection active)
avrdude> config nvm -vv
# Mask 0x03 of pdicfg: NVM protection level
config nvmlevel=nvmaccdis # 2 = 0b10 = 0x02>>0 (NVM access through UPDI disabled)

# Mask 0xfff0 of pdicfg: NVM protection activation key
config nvmkey=nvmact # 0x0b45 = 0xb450>>4 (NVM protection active)
avrdude> quit

avrdude_pr1491 done.  Thank you.

@mcuee
Copy link
Collaborator

mcuee commented Aug 27, 2023

Simple regression tests using AVR64EA48.-- no regression compared to git main.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1491 -C .\avrdude_pr1491.conf -c pkobn_updi -p avr64ea48 -U median_Release_1.0.0.hex
avrdude_pr1491: AVR device initialized and ready to accept instructions
avrdude_pr1491: device signature = 0x1e961e (probably avr64ea48)
avrdude_pr1491: Note: flash memory has been specified, an erase cycle will be performed.
                To disable this feature, specify the -D option.
avrdude_pr1491: erasing chip

avrdude_pr1491: processing -U flash:w:median_Release_1.0.0.hex:i
avrdude_pr1491: reading input file median_Release_1.0.0.hex for flash
                with 5122 bytes in 1 section within [0, 0x1401]
                using 41 pages and 126 pad bytes
avrdude_pr1491: writing 5122 bytes flash ...
Writing | ################################################## | 100% 2.49 s
avrdude_pr1491: 5122 bytes of flash written
avrdude_pr1491: verifying flash memory against median_Release_1.0.0.hex
Reading | ################################################## | 100% 1.21 s
avrdude_pr1491: 5122 bytes of flash verified

avrdude_pr1491 done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c pkobn_updi -p avr64ea48 -U flash:v:median_Release_1.0.0.hex:i
avrdude_git: AVR device initialized and ready to accept instructions
avrdude_git: device signature = 0x1e961e (probably avr64ea48)

avrdude_git: processing -U flash:v:median_Release_1.0.0.hex:i
avrdude_git: verifying flash memory against median_Release_1.0.0.hex
Reading | ################################################## | 100% 1.26 s
avrdude_git: 5122 bytes of flash verified

avrdude_git done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1491 -C .\avrdude_pr1491.conf -c pkobn_updi -p avr64ea48 -t
avrdude_pr1491: AVR device initialized and ready to accept instructions
avrdude_pr1491: device signature = 0x1e961e (probably avr64ea48)

avrdude_pr1491: processing -t interactive terminal
avrdude> part
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
  tempsense               0     0     0    0 no          2    1      0     0     0 0x00 0x00
  signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00
  prodsig                 0     0     0    0 no        125  125      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
avrdude> dump fuses
Reading | ################################################## | 100% 0.11 s
0000  00 00 00 ff ff d0 07 00  00 ff ff ff ff ff ff ff  |................|
avrdude> dump userrow
Reading | ################################################## | 100% 0.19 s
0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
avrdude> quit

avrdude_pr1491 done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -C .\avrdude_pr1491.conf -c pkobn_updi -p avr64ea48 -t
avrdude_git: AVR device initialized and ready to accept instructions
avrdude_git: device signature = 0x1e961e (probably avr64ea48)

avrdude_git: processing -t interactive terminal
avrdude> dump fuses
Reading | ################################################## | 100% 0.11 s
0000  00 00 00 ff ff d0 07 00  00 ff ff ff ff ff ff ff  |................|
avrdude> dump userrow
Reading | ################################################## | 100% 0.18 s
0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
avrdude> quit

avrdude_git done.  Thank you.

@mcuee
Copy link
Collaborator

mcuee commented Aug 27, 2023

@stefanrueger

I think this PR can be merged.

We can always carry out real tests when demo boards are available.

@stefanrueger stefanrueger merged commit 54ce12a into avrdudes:main Aug 27, 2023
10 checks passed
@stefanrueger stefanrueger deleted the avr-eb branch August 27, 2023 17:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Add support for AVR-EB
4 participants
@stefanrueger @MCUdude @xedbg @mcuee