SpenceKonde / DxCore

Arduino core for AVR DA, DB, DD, EA and future DU-series parts - Microchip's latest and greatest AVRs. Library maintainers: Porting help and adviccee is available.
Other
179 stars 48 forks source link

platformio question setting PF6 (RESET) to be used as Reset (and not GPIO) #460

Closed mrWheel closed 10 months ago

mrWheel commented 1 year ago

@SpenceKonde I know you do not have the time to dive into platformio questions, but I hope someone else is willing to help me!

I am trying to get my AVR128DB28 MCU to reset using .. well, the RESET pin (PF6). I'm using the reset circuit as conform Spence's advice.

Using the Arduino IDE and the option [Reset pin function: "Hardware Reset (recommended)"] it works like a charm (thanks Spence).

But I'm shifting towards Visual Code and Platformio and I can not get the same code/hardware to reset if the [reset] button is pressed..

This is my platform.ini file:

[platformio]
workspace_dir = .pio.nosync
default_envs = AVRxDB28
name = testReset
description = test Reset circuit

[env]
framework = arduino
build_unflags = 

[env:AVRxDB28]
platform = atmelmegaavr
board = AVR128DB28
build_flags = 
    -DIS_AVR128DB28
upload_protocol = jtag2updi
upload_flags = 
board_hardware.bod = 2.7v
board_hardware.eesave = yes
board_hardware.uart = no_bootloader
board_hardware.rstpin = reset

This is the (test) code I'm using:

/*------------------------------------------------------
*  Chip: "AVR128DB28"
*  Clock Speed: "24 MHz internal"
*  millis()/micros() timer: |TCB2 (recommended)"
*  Reset pin function: "Hardware Reset (recommended)"
*  Startup Time: "8ms"
*  MultiVoltage I/O (MVIO): "Disabled"
*  --
*  Programmer: "jtag2updi"
*-----------------------------------------------------*/

//==============================================================
void setup() 
{
  pinMode(PIN_PA7,  OUTPUT);
  pinMode(PIN_PF6,  INPUT_PULLUP);

  Serial.begin(115200);
  Serial.println("\n\n\nAnd than it begins ....");

  for (int i=0; i<10; i++)  
  {
    digitalWrite(PIN_PA7, CHANGE);
    delay(500);
  }
  Serial.println();

} //  setup()

//==============================================================
void loop() 
{
  digitalWrite(PIN_PA7, CHANGE);
  delay(100);
  if (!digitalRead(PIN_PF6))
    Serial.println("RESET is LOW");
}  // loop()

I'm so close but still so far away.

I hope someone can and will help me!

SpenceKonde commented 1 year ago
  1. You should look at the compile output logs from Arduino and from platform.io - make sure that build_flags includes all the things that get used as build flags by the arduino IDE. I do not think all the build flags that should be there are (this is what I hate about platform IO, as a core developer - I would have to duplicate a whole bunch of logic to blow up every compile attempt that missed any #defines that were required.

and -DIS_AVR128DA28 shouldn't be there - there's already a builtin compiler supplied macro (__AVR_AVR128DB28__ I think), plus I supply a shitload of macros, see Ref_Defines.md. which can be used to identify parts.

  1. The configuration of PF6 however is completely outside of the realm of what any code running on the AVR can do, the code uploaded has no bearing on it. The function of the reset pin is configured by the fuses, so you need to set it, it's in one of the sysconfig fuses (I forget which of the two or which bits it is) to the correct value) when writing the fuses.

On Fri, Jul 21, 2023 at 8:26 AM mrWheel @.***> wrote:

@SpenceKonde https://github.com/SpenceKonde I know you do not have the time to dive into platformio questions, but I hope someone else is willing to help me!

I am trying to get my AVR128DB28 MCU to reset using .. well, the RESET pin (PF6). I'm using the reset circuit https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/Ref_Reset.md as conform Spence's advice.

Using the Arduino IDE and the option [Reset pin function: "Hardware Reset (recommended)"] it works like a charm (thanks Spence).

But I'm shifting towards Visual Code and Platformio and I can not get the same code/hardware to reset if the [reset] button is pressed..

This is my platform.ini file:

[platformio] workspace_dir = .pio.nosync default_envs = AVRxDB28 name = testReset description = test Reset circuit

[env] framework = arduino build_unflags =

[env:AVRxDB28] platform = atmelmegaavr board = AVR128DB28 build_flags = -DIS_AVR128DB28 upload_protocol = jtag2updi upload_flags = board_hardware.bod = 2.7v board_hardware.eesave = yes board_hardware.uart = no_bootloader board_hardware.rstpin = reset

This is the (test) code I'm using:

/*------------------------------------------------------

  • Chip: "AVR128DB28"
  • Clock Speed: "24 MHz internal"
  • millis()/micros() timer: |TCB2 (recommended)"
  • Reset pin function: "Hardware Reset (recommended)"
  • Startup Time: "8ms"
  • MultiVoltage I/O (MVIO): "Disabled"
  • --
  • Programmer: "jtag2updi" -----------------------------------------------------/

//============================================================== void setup() { pinMode(PIN_PA7, OUTPUT); pinMode(PIN_PF6, INPUT_PULLUP);

Serial.begin(115200); Serial.println("\n\n\nAnd than it begins ....");

for (int i=0; i<10; i++) { digitalWrite(PIN_PA7, CHANGE); delay(500); } Serial.println();

} // setup()

//============================================================== void loop() { digitalWrite(PIN_PA7, CHANGE); delay(100); if (!digitalRead(PIN_PF6)) Serial.println("RESET is LOW"); } // loop()

I'm so close but still so far away.

I hope someone can and will help me!

— Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/DxCore/issues/460, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW5U3XYPCZ4PL4VST4DXRJYQ3ANCNFSM6AAAAAA2SYXRME . You are receiving this because you were mentioned.Message ID: @.***>

--


Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore https://github.com/SpenceKonde/ATTinyCore: Arduino support for all pre-2016 tinyAVR with >2k flash! megaTinyCore https://github.com/SpenceKonde/megaTinyCore: Arduino support for all post-2016 tinyAVR parts! DxCore https://github.com/SpenceKonde/DxCore: Arduino support for the AVR Dx-series parts, the latest and greatest from Microchip! Contact: @.***

mrWheel commented 1 year ago

Thanks Spence,

It's a bit of a catch22.

This is what the boards.txt file has:

#----------------------------------------#
# Reset pin as input option              #
#________________________________________#
avrdb.menu.resetpin.reset=Hardware Reset (recommended)
avrdb.menu.resetpin.reset.bootloader.resetpinbits=10
avrdb.menu.resetpin.input=Input
avrdb.menu.resetpin.input.bootloader.resetpinbits=00

So I guess the resetpinbits=10 is what I need.

Now if only I new how to set this in a platform.ini file....

If anyone could help me with this I would much appreciate it!

and -DIS_AVR128DA28 shouldn't be there

I know. Just could not find out how the define was named (now I know and shall change that in my program).

mrWheel commented 1 year ago

Update I have compared the ArduinoIDE upload output for both AVR128DB28 and AVR128DB32 with selecting both "Reset pin function" as "Input" and as "Hardware Reset"

The differences are:

AVR128DB32
PF6 = Input:  -Ufuse5:w:0b11000001:m -Ufuse6:w:0b00010100:m -Ufuse7:w:0x00:m 
PF6 = Reset:  -Ufuse5:w:0b11001001:m -Ufuse6:w:0b00010100:m -Ufuse7:w:0x00:m -Ufuse8:w:0x00:m 
------------------------------^

AVR128DB28
PF6 = Input:  -Ufuse5:w:0b11000001:m -Ufuse6:w:0b00010100:m -Ufuse7:w:0x00:m -Ufuse8:w:0x00:m 
PF6 = Reset:  -Ufuse5:w:0b11001001:m -Ufuse6:w:0b00010100:m -Ufuse7:w:0x00:m -Ufuse8:w:0x00:m 
------------------------------^

The only difference is in fuse5 and the missing setting for fuse8 when "Input" is selected!

But the strange thing is: For the AVR128DB32 it makes no difference in the Reset function of PF6! In both cases Reset button works as "Reset"!

Next going to investigate if I can set fuse5 with platformio ..

mrWheel commented 1 year ago

Well.. in platformio open the "Project Task" (click on the 'ant-head') than click on "set Fuses"

This is the output:

Processing AVRxDB28 (platform: atmelmegaavr; board: AVR128DB28; framework: arduino)
-------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelmegaavr/AVR128DB28.html
PLATFORM: Atmel megaAVR (1.8.0) > AVR128DB28
HARDWARE: AVR128DB28 24MHz, 16KB RAM, 128KB Flash
PACKAGES: 
 - framework-arduino-megaavr-dxcore @ 1.5.6 
 - tool-avrdude @ 1.70100.0 (7.1.0) 
 - toolchain-atmelavr @ 3.70300.220127 (7.3.0)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 19 compatible libraries
Scanning dependencies...
Dependency Graph
|-- RF24 @ 1.4.7
|-- SPI @ 1.1.2
Building in release mode

TARGET CONFIGURATION:
-------------------------
Target = avr128db28
Clock speed = 24000000L
Oscillator = internal
BOD level = 2.6v
Save EEPROM = yes
MVIO enable = no
Reset pin mode = reset
-------------------------
Auto-detected: /dev/cu.wchusbserial14210

Selected fuses:
-------------------------
[fuse0 / wdtcfg   = 0x00]
[fuse1 / bodcfg   = 0x00]
[fuse2 / osccfg   = 0x00]
[fuse4 / tcd0cfg  = 0x00]
[fuse5 / syscfg0  = 0xC9]
[fuse6 / syscfg1  = 0x16]
[fuse7 / codesize = 0x00]
[fuse8 / bootsize = 0x00]
[lock  / lockbit  = 0x5CC5C55C]
-------------------------

Looking for port...
Using manually specified: /dev/cu.wchusbserial14210
Setting fuses...

avrdude: Version 7.1-arduino.1
         Copyright the AVRDUDE authors;
         see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

         System wide configuration file is /Users/WillemA/.platformio/packages/tool-avrdude/avrdude.conf
         User configuration file is /Users/WillemA/.avrduderc
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cu.wchusbserial14210
         Using Programmer              : jtag2updi
avrdude jtagmkII_getsync() warning: attempt 1 of 10: sign-on command: status -1
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                      : AVR128DB28
         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
           fuse4       tcd0cfg     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          9   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         32   32      0     0     0 0x00 0x00
           data                    0     0     0    0 no          0    1      0     0     0 0x00 0x00
           eeprom                  0     0     0    0 no        512    1      0     0     0 0x00 0x00
           flash                   0     0     0    0 no     131072  512      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
         Vtarget         : 5.0 V

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e970e (probably avr128db28)
avrdude: reading input file 0x00 for fuse0/wdtcfg
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse0/wdtcfg ...
avrdude: 1 byte of fuse0/wdtcfg written
avrdude: verifying fuse0/wdtcfg memory against 0x00
avrdude: 1 byte of fuse0/wdtcfg verified
avrdude: reading input file 0x00 for fuse1/bodcfg
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse1/bodcfg ...
avrdude: 1 byte of fuse1/bodcfg written
avrdude: verifying fuse1/bodcfg memory against 0x00
avrdude: 1 byte of fuse1/bodcfg verified
avrdude: reading input file 0x00 for fuse2/osccfg
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse2/osccfg ...
avrdude: 1 byte of fuse2/osccfg written
avrdude: verifying fuse2/osccfg memory against 0x00
avrdude: 1 byte of fuse2/osccfg verified
avrdude: reading input file 0x00 for fuse4/tcd0cfg
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse4/tcd0cfg ...
avrdude: 1 byte of fuse4/tcd0cfg written
avrdude: verifying fuse4/tcd0cfg memory against 0x00
avrdude: 1 byte of fuse4/tcd0cfg verified
avrdude: reading input file 0xC9 for fuse5/syscfg0
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse5/syscfg0 ...
avrdude: 1 byte of fuse5/syscfg0 written
avrdude: verifying fuse5/syscfg0 memory against 0xC9
avrdude: 1 byte of fuse5/syscfg0 verified
avrdude: reading input file 0x16 for fuse6/syscfg1
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse6/syscfg1 ...
avrdude: 1 byte of fuse6/syscfg1 written
avrdude: verifying fuse6/syscfg1 memory against 0x16
avrdude: 1 byte of fuse6/syscfg1 verified
avrdude: reading input file 0x00 for fuse7/codesize
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse7/codesize ...
avrdude: 1 byte of fuse7/codesize written
avrdude: verifying fuse7/codesize memory against 0x00
avrdude: 1 byte of fuse7/codesize verified
avrdude: reading input file 0x00 for fuse8/bootsize
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse8/bootsize ...
avrdude: 1 byte of fuse8/bootsize written
avrdude: verifying fuse8/bootsize memory against 0x00
avrdude: 1 byte of fuse8/bootsize verified
avrdude: reading input file 0x5CC5C55C for lock
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte lock ...
avrdude: 1 byte of lock written
avrdude: verifying lock memory against 0x5CC5C55C
avrdude: 1 byte of lock verified

avrdude done.  Thank you.

======================================== [SUCCESS] Took 7.35 seconds ========================================

Environment    Status    Duration
-------------  --------  ------------
AVRxDB28       SUCCESS   00:00:07.345
======================================== 1 succeeded in 00:00:07.345 ========================================
 *  Terminal will be reused by tasks, press any key to close it. 

After that the [Reset] function of PF6 works as expected. Uploading other program's to the chip do not interfere with the fuse settings and PF6 stay's a Reset pin!

I have not yet found a way to make PF6 a GPIO-input pin again, but who cares! I'm a happy Camper!

No idea what happens behind the service, maybe someone else can elaborate.

SpenceKonde commented 1 year ago

SYSCFG0=0xC9 = PF6 RESET, So to turn it back to input, set it to 0xC1 instead


Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: @.***

On Sat, Jul 22, 2023, 09:36 mrWheel @.***> wrote:

Well.. in platformio open the "Project Task" (click on the 'ant-head') than click on "set Fuses"

This is the output:

Processing AVRxDB28 (platform: atmelmegaavr; board: AVR128DB28; framework: arduino)

Verbose mode can be enabled via -v, --verbose option CONFIGURATION: https://docs.platformio.org/page/boards/atmelmegaavr/AVR128DB28.html PLATFORM: Atmel megaAVR (1.8.0) > AVR128DB28 HARDWARE: AVR128DB28 24MHz, 16KB RAM, 128KB Flash PACKAGES:

  • framework-arduino-megaavr-dxcore @ 1.5.6
  • tool-avrdude @ 1.70100.0 (7.1.0)
  • toolchain-atmelavr @ 3.70300.220127 (7.3.0) LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf LDF Modes: Finder ~ chain, Compatibility ~ soft Found 19 compatible libraries Scanning dependencies... Dependency Graph |-- RF24 @ 1.4.7 |-- SPI @ 1.1.2 Building in release mode

TARGET CONFIGURATION:

Target = avr128db28 Clock speed = 24000000L Oscillator = internal BOD level = 2.6v Save EEPROM = yes MVIO enable = no Reset pin mode = reset

Auto-detected: /dev/cu.wchusbserial14210

Selected fuses:

[fuse0 / wdtcfg = 0x00] [fuse1 / bodcfg = 0x00] [fuse2 / osccfg = 0x00] [fuse4 / tcd0cfg = 0x00] [fuse5 / syscfg0 = 0xC9] [fuse6 / syscfg1 = 0x16] [fuse7 / codesize = 0x00] [fuse8 / bootsize = 0x00] [lock / lockbit = 0x5CC5C55C]

Looking for port... Using manually specified: /dev/cu.wchusbserial14210 Setting fuses...

avrdude: Version 7.1-arduino.1 Copyright the AVRDUDE authors; see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

     System wide configuration file is /Users/WillemA/.platformio/packages/tool-avrdude/avrdude.conf
     User configuration file is /Users/WillemA/.avrduderc
     User configuration file does not exist or is not a regular file, skipping

     Using Port                    : /dev/cu.wchusbserial14210
     Using Programmer              : jtag2updi

avrdude jtagmkII_getsync() warning: attempt 1 of 10: sign-on command: status -1 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 : AVR128DB28 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
       fuse4       tcd0cfg     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          9   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         32   32      0     0     0 0x00 0x00
       data                    0     0     0    0 no          0    1      0     0     0 0x00 0x00
       eeprom                  0     0     0    0 no        512    1      0     0     0 0x00 0x00
       flash                   0     0     0    0 no     131072  512      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
     Vtarget         : 5.0 V

avrdude: AVR device initialized and ready to accept instructions avrdude: device signature = 0x1e970e (probably avr128db28) avrdude: reading input file 0x00 for fuse0/wdtcfg with 1 byte in 1 section within [0, 0] avrdude: writing 1 byte fuse0/wdtcfg ... avrdude: 1 byte of fuse0/wdtcfg written avrdude: verifying fuse0/wdtcfg memory against 0x00 avrdude: 1 byte of fuse0/wdtcfg verified avrdude: reading input file 0x00 for fuse1/bodcfg with 1 byte in 1 section within [0, 0] avrdude: writing 1 byte fuse1/bodcfg ... avrdude: 1 byte of fuse1/bodcfg written avrdude: verifying fuse1/bodcfg memory against 0x00 avrdude: 1 byte of fuse1/bodcfg verified avrdude: reading input file 0x00 for fuse2/osccfg with 1 byte in 1 section within [0, 0] avrdude: writing 1 byte fuse2/osccfg ... avrdude: 1 byte of fuse2/osccfg written avrdude: verifying fuse2/osccfg memory against 0x00 avrdude: 1 byte of fuse2/osccfg verified avrdude: reading input file 0x00 for fuse4/tcd0cfg with 1 byte in 1 section within [0, 0] avrdude: writing 1 byte fuse4/tcd0cfg ... avrdude: 1 byte of fuse4/tcd0cfg written avrdude: verifying fuse4/tcd0cfg memory against 0x00 avrdude: 1 byte of fuse4/tcd0cfg verified avrdude: reading input file 0xC9 for fuse5/syscfg0 with 1 byte in 1 section within [0, 0] avrdude: writing 1 byte fuse5/syscfg0 ... avrdude: 1 byte of fuse5/syscfg0 written avrdude: verifying fuse5/syscfg0 memory against 0xC9 avrdude: 1 byte of fuse5/syscfg0 verified avrdude: reading input file 0x16 for fuse6/syscfg1 with 1 byte in 1 section within [0, 0] avrdude: writing 1 byte fuse6/syscfg1 ... avrdude: 1 byte of fuse6/syscfg1 written avrdude: verifying fuse6/syscfg1 memory against 0x16 avrdude: 1 byte of fuse6/syscfg1 verified avrdude: reading input file 0x00 for fuse7/codesize with 1 byte in 1 section within [0, 0] avrdude: writing 1 byte fuse7/codesize ... avrdude: 1 byte of fuse7/codesize written avrdude: verifying fuse7/codesize memory against 0x00 avrdude: 1 byte of fuse7/codesize verified avrdude: reading input file 0x00 for fuse8/bootsize with 1 byte in 1 section within [0, 0] avrdude: writing 1 byte fuse8/bootsize ... avrdude: 1 byte of fuse8/bootsize written avrdude: verifying fuse8/bootsize memory against 0x00 avrdude: 1 byte of fuse8/bootsize verified avrdude: reading input file 0x5CC5C55C for lock with 1 byte in 1 section within [0, 0] avrdude: writing 1 byte lock ... avrdude: 1 byte of lock written avrdude: verifying lock memory against 0x5CC5C55C avrdude: 1 byte of lock verified

avrdude done. Thank you.

======================================== [SUCCESS] Took 7.35 seconds ========================================

Environment Status Duration


AVRxDB28 SUCCESS 00:00:07.345 ======================================== 1 succeeded in 00:00:07.345 ========================================

  • Terminal will be reused by tasks, press any key to close it.

After that the [Reset] function of PF6 works as expected. Uploading other program's to the chip do not interfere with the fuse settings and PF6 stay's a Reset pin!

I have not yet found a way to make PF6 a GPIO-input pin again, but who cares! I'm a happy Camper!

No idea what happens behind the service, maybe someone else can elaborate.

— Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/DxCore/issues/460#issuecomment-1646585763, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW7YX243JAYGDGBVVHLXRPJL7ANCNFSM6AAAAAA2SYXRME . You are receiving this because you were mentioned.Message ID: @.***>

mrWheel commented 1 year ago

@Spence,

The problem is the fuse settings are located in a file deep in the platformio stuff ("/<home>/.platformio/platforms/atmelmegaavr/builder/fuses.py").

I have not yet found a way to simple change these fuse settings in the platform.ini file (multiple hits if you search for it, but the answers are all different from each other and none of them works!).

But for me it is not a problem as I have no need for PF6 to be used other than as a Reset pin.

But did you read this:

But the strange thing is: For the AVR128DB32 it makes no difference if you select PF6 to be a GPIO-Input pin or as the Reset pin! In both cases PF6 works as "Reset"!

That is in the ArduinoIDE.

SpenceKonde commented 1 year ago

I will see if I can reproduce, that is not correct behavior if so.

SpenceKonde commented 1 year ago

The problem is the fuse settings are located in a file deep in the platformio stuff ("/<home>/.platformio/platforms/atmelmegaavr/builder/fuses.py").

I have not yet found a way to simple change these fuse settings in the platform.ini file (multiple hits if you search for it, but the answers are all different from each other and none of them works!). @mrWheel - you might be able to get more info on how the fuses are calculated in platform IO from one of tthe people who has a lot of experience with it - @mcudude is such a person, and IIRC he was the one who waved the fuse wand over at least mTC and maybe DxC as well.
(when I try waving a fuse wand, it seems okay for a few seconds, then the wand starts shooting flaming balls and exploding things... Maybe I'm thinking the wrong kind of fuse - (those wands that shot sparks and fire did look remarkably like roman candles...).)

MCUdude commented 1 year ago

If you need to have exact fuse values, you can define them like so, and the built-in fuses.py will use these instead of calculating them:

board_fuses.wdtcfg = 0x00
board_fuses.bodcfg = 0x00
board_fuses.osccfg = 0x01
board_fuses.tcd0cfg = 0x00
board_fuses.syscfg0 = 0xC9
board_fuses.syscfg1 = 0x06
board_fuses.codesize = 0x00 # append for MegaCoreX and megaTinyCore
board_fuses.bootsize = 0x00 # bootend for MegaCoreX and megaTinyCore

But I can't reproduce @mrWheel's issue. When I use the platformio.ini file he provided, and changes board_hardware.rstpin from reset to gpio, I get syscfg0=0xC1 instead of syscfg0=0xC9. And that seems about right.

> pio run -t fuses -e AVRxDB28

[...]

TARGET CONFIGURATION:
-------------------------
Target = avr128db28
Clock speed = 24000000L
Oscillator = internal
BOD level = 2.7v
Save EEPROM = yes
MVIO enable = no
Reset pin mode = gpio
-------------------------

Selected fuses:
-------------------------
[fuse0 / wdtcfg   = 0x00]
[fuse1 / bodcfg   = 0x54]
[fuse2 / osccfg   = 0x00]
[fuse4 / tcd0cfg  = 0x00]
[fuse5 / syscfg0  = 0xC1]
[fuse6 / syscfg1  = 0x16]
[fuse7 / codesize = 0x00]
[fuse8 / bootsize = 0x00]
[lock  / lockbit  = 0x5CC5C55C]
-------------------------
> pio run -t fuses -e AVRxDB28

[...]

-------------------------
Target = avr128db28
Clock speed = 24000000L
Oscillator = internal
BOD level = 2.7v
Save EEPROM = yes
MVIO enable = no
Reset pin mode = reset
-------------------------

Selected fuses:
-------------------------
[fuse0 / wdtcfg   = 0x00]
[fuse1 / bodcfg   = 0x54]
[fuse2 / osccfg   = 0x00]
[fuse4 / tcd0cfg  = 0x00]
[fuse5 / syscfg0  = 0xC9]
[fuse6 / syscfg1  = 0x16]
[fuse7 / codesize = 0x00]
[fuse8 / bootsize = 0x00]
[lock  / lockbit  = 0x5CC5C55C]
-------------------------
mrWheel commented 1 year ago

@MCUdude Thanks for explaining.

And indeed: setting "board_hardware.rstpin = reset" does what is is supposed to do .. but only if you run "Project Tasks -> Set Fuses" which I did not know (before).

I did found posts and issue answers about the "baurd_hardware.rstpin" but had no idea that I had to run a separate command!

PlatformIO has a steep learning curve! If only the atmelmegaavr/AVR128DB28 documentation was half as voluminous and half as good as Spence's documentation about his cores!

Question: Is there a way to set the fuses during uploading? Just like the ArduinoIDE does?

But besides that: thanks.

MCUdude commented 1 year ago

Yes, Project Tasks -> Set Fuses or a pio run -t fuses -e some_environment has to be executed first. Fuses are not set automatically when you upload using a UPDI programmer, which is different than how Arduino does it.

I don't see why you would want to set the fuses every time you upload. It's only needed once. You can add custom upload flags that Avrdude can utilize, but then you'll have to know the values of the fuses you want to set.

upload_flags =
  -U wdtcfg:w:0x00:m
  -U syscfg0:w:0xC9:m
  -U syscfg1:w:0x16:m

This would also work if you have your fuses defined in a separate environment (so you can run the fuses command):

upload_flags =
  -U wdtcfg:w:${env:custom_fuses.board_fuses.wdtcfg}:m
  -U syscfg0:w:${env:custom_fuses.board_fuses.syscfg0}:m
  -U syscfg1:w:${env:custom_fuses.board_fuses.syscfg1}:m

I do agree that the PlatformIO documentation for AVR/ megaAVR isn't all that good. That's why I've provided a template and a simple readme for MegaCoreX that was later adopted by DxCore. However, since PlatformIO is so powerful and lets the user play around with all the 3rd party tools PlatformIO utilizes, like Avrdude, you can do very complex and neat things straight from platformio.ini.

If someone were to document every possible thing you could do with the PlatformIO build system, it would become quite a heavy book!

Pro tip: Since PlatformIO uses Avrdude 7.1 (unlike DxCore) you can increase the upload speed of your jtag2updi programmer if you're tired of waiting for slow uploads. Higher speeds than 115200 baud was added to the jtag2updi firmware in January 2022, so if your firmware is newer than this, you should be good to go.

Try adding upload_speed = 250000 and see if it works.

[env:AVRxDB28]
platform = atmelmegaavr
board = AVR128DB28
build_flags = 
    -DIS_AVR128DB28
upload_protocol = jtag2updi
upload_speed = 250000
upload_flags = 
board_hardware.bod = 2.7v
board_hardware.eesave = yes
board_hardware.uart = no_bootloader
board_hardware.rstpin = reset
SpenceKonde commented 1 year ago

The reason you want to set fuses everytime you upload, well first almost half my issues were confusion about 16/20 MHz speeds.

So then that fuse got autoset on updi uploads.

Then I realized that a UPDI upload after bootloader had been in use, uploaded over UPDI would delete the bootloader, but not reset the fuses correctly, so it would think the vectors were in the wrong place and the whole thing would go up in a ball of fire. , resulting in guaranteed not to work state.

Okay so bootend and append should be set every time (especially the equivalent on DxCore, because we have adjustable size APPDATA section for writes from the app to flash without doing anything dirty)

And at that point someone asked "Why aren't all fuses written?!" and I say "Well you can't do SYSCFG1 because that could brick the chip we should enforce a bit of consideration there" "And what about the rest of them?" "Well BODCFG is also hazardous, because you could be soldered to a board sharing supply rail with parts that can see 3.6v max, but you set the BOD voltage to 4.3V - parts would have to be desoldered. And why should we touch a fuse that we don't have a submenu that controls - either they're at the default where we left them or the user changed them and we probable are not doing what they want if we're resetting those." And since then that's been my standard - If the fuse has options to configure it in the core, it gets set on upload unless it's an "unsafe" fuse that could brick the chip or make the chip hard to reprogram (BODCFG and anything that lets you turn off UPDI. For a while MVIO was classified as unsife, but I eventually tested it, finding that it did not connect VDDIO2 and VDD internally (which would have made it a chip-burner if MVIO wasn't enabled and the lower voltage supply could both source and sink) and did not appear to be short-term destructive to the device) (They did MVIO status wrong IMHO - They should have given a status of 0 (not working) whenever MVIO was disabled, instead of 1, which is what it does. Nobody not using MVIO is going to check MVIO status, so you don't care what those people see. So effectively 100% of the people checking that register think MVIO is enabled, and want to see if the port is powered. If MVIO is disabled and we don't know if the port is powered, dear lord shouldn't we say something other than "all clear!"?)

And yeah., that's why the fuses that are written upon upload in almost all cases.

The exceptions being BODCFG, and SYSCFG1 if that fuse lets updi be disabled, plus any fuse we have no submenu to configure.
All of those fuses are written, even ones the core normally does not change, and dangerous one, if you do burn bootloader. which tries to get the chip back to a known state.

Microchip assured me that there would not be a fuse longevity problem doing this, indicating they're more like EEPROM than flash

But the root reason the cores do is that it generates too many support inquiries to not set OSCCFG, and to be consistent with our policy of trying not to knowingly leave the chip in state that we can guarantee will not function correctly (as would be the case if we didn't fix BOOTSIZE) and you'd need to burn bootloader if you wanted to change the size of sized SPM, which would be obnoxious so maybe CODESIZE gets in too, and from there, the consistency argument leads to, well, this.

And - the original reason NOT to set fuses on all uploads dated to classic AVR times. On classic AVRs, most of the time every single fuse had at least one bit that would brick the chip - a fucked low fuse was easy enough to recover by supplying and external clock. A fucked high fuse required HV programming (in reach if the patient was a t85, 84, or 841, as those use hvsp. HVPP was used by everything else and required around 20 connections to the target and all of which were used. And a fucked efuse had varying effects depending on the part, sometimes these were non-fatal on non-optiboot configurations except if the sketch got up to the last 512b of flash). But on modern AVRs, there are only 1-2 dangerous fuses, and the one present on all parts is only extrinsically hazardous (ie, if the chip were alone on a board it is totally safe). The intentionally dangerous "break the wrong key off in the lock on your way out" fuses will never be written by the core. Yes, in addition to locking there is yet another way to throw barricades into the path of people trying to exfiltrate your firmware.

mrWheel commented 11 months ago

@MCUdude

Hans,

"Set Fuses" works great but I now have the following issue: "Set Fuses" will not comply with the selected port!

Screenshot 2023-08-20 at 13 11 35

I have to explicitly set upload_port = /dev/cu.usbserial-142430 or set fuses will use a (probably used before) upload port.

But that means every time I change the port the platformio.ini file changes (and git changes).

Is this a bug and will it be dealt with in the near future or is there something I do wrong (and maybe a quick patch)?

Regards

SpenceKonde commented 11 months ago

Is there by any chance a program_port or a bootload_port? (program because that keyword was sometimes used by arduino to refer to using an external programmer instead of a bootloader mostly in the classic avr days, though it lives on in the platform.txt)

All these IDEs seem to do a piss poor job of this sort of thing. I think it comes down to settings, and their management.

There are several kinds of settings. There are some settings that should definitely be associated with a user and a machine - the path to his sketchbook, his warning and verbosity choices, that sort of thing. Arduino manages this ok.

There are some settings (like all the tools submenu entries, EXCEPT port) that should be associated with the sketch - Wouldn't it be great if Arduino dropped a sketch.ini with the values that were selected on each tools submenu every time they saved it? Or better still, sketch-boardname.ini, so you can have one sketch folder, and if you select a tinyAVR board it would build with one set of menu options and if it was a Dx it would use another set of options).

Finally, there are settings like the port number. They are ephemeral, the same board will have one port number one day, another the next... - I'm not even sure quite what the right behavior is bearing in mind what computers can and can't do to serial ports (for example, it doesn't seem like there's a way to see which serial ports are available and which are already in use), that some serial adapters have "names", others just have an "address" (ex, FT232RL will get a COM number, and then that number will follow it around into any USB port. Different FT232RL, different port number - they each have their own name. CH340 will get a COM number that depends on, exactly, where in the tree-like USB topology the CH340 is connected. (Usually the logic seems to be that they're numbered in chronological order, and if you have a USB hub, each of it's ports are different, and each port it can be plugged into is different, and so on). But if you remove the CH340 from USB and plug in a different CH340, it will get the same COM port numbers as the first one did when plugged into the same port. The CH340 only depends on where it's located, so it has an address but no name).

serial adapters known by their name might even make sense to save with the sketch! Whereas serial adapters known only by their address should probably only be retained on a per-window basis. But I don't know if there's a way to determine which type of adapter each one is...

This may be a case of "It sucks cause the tools we got suck" - it does kind of look like particularly on windows the toolkit that developers get consists of a vacuum cleaner, a black hole, and the front half of an jet engine (so it sucks air in, and the fuel and air combust, and wherever it's back end happens to be will develop thrust and blast out hot jet exhaust).... and it's not clear to me that linux is all that much better. They may just not give you much information about themselves. They date to an era where a computer had maybe 1 or 2 serial ports, and the connectors that were used were generally screwed in, etc, etc. Since they didn't come and go very often, they didn't need to report very much information, because you'd know "okay, I have a port labeled 1 and 2 on the back of my desktop, I guess that's COM1 and COM2". Little bit more confusing now :-P

mrWheel commented 11 months ago

@SpenceKonde Hm.. I think I did not presented my issue very good.

I’m using Visual Code with platformio and with that IDE you can define an upload_port and if you do everything works as expected. But as you wrote the port can change depending on using a hub or not or plugging the UPDI programmer in a different connector.

The other way is to nót define an upload_port and select one as in the image on my previous comment. That works great for flashing the firmware but the “Set Fuses” option of the “Project Task” does not use the selected port, witch is, I think, a bug. As @MCUdude helped with the “Set Fuses” and has a lot of knowledge of platformio I hope he has a solution for this too.

MCUdude commented 11 months ago

@mrWheel I'm able to reproduce the issue. I've selected /dev/cu.usbserial-1410 on the blue toolbar, but it still thinks I want to use /dev/cu.usbserial-1410. This is probably something @ivankravets or @valeros would have to look into.

image
*  Executing task: platformio run --target fuses --environment fuses_bootloader 

Processing fuses_bootloader (platform: atmelmegaavr; framework: arduino; board: ATmega4809)
--------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelmegaavr/ATmega4809.html
PLATFORM: Atmel megaAVR (1.6.0+sha.cacb22b) > ATmega4809
HARDWARE: ATMEGA4809 16MHz, 6KB RAM, 48KB Flash
PACKAGES: 
 - framework-arduino-megaavr-megacorex @ 1.1.1 
 - tool-avrdude @ 1.70100.0 (7.1.0) 
 - toolchain-atmelavr @ 1.70300.191015 (7.3.0)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 11 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode

TARGET CONFIGURATION:
-------------------------
Target = atmega4809
Clock speed = 16000000L
Oscillator = internal
BOD level = 2.7v
Save EEPROM = yes
Reset pin mode = reset
-------------------------
Auto-detected: /dev/cu.usbserial-1420

Selected fuses:
-------------------------
[fuse0 / wdtcfg   = 0x00]
[fuse1 / bodcfg   = 0x00]
[fuse2 / osccfg   = 0x01]
[fuse4 / tcd0cfg  = 0x00]
[fuse5 / syscfg0  = 0xC9]
[fuse6 / syscfg1  = 0x06]
[fuse7 / append   = 0x00]
[fuse8 / bootend  = 0x00]
[lock  / lockbit  = 0xC5]
-------------------------

Looking for port...
Using manually specified: /dev/cu.usbserial-1420
Setting fuses...
avrdude error: bad response to sign-on command: Unknown JTAG ICE mkII result code 0x01
avrdude error: unable to open programmer jtag2updi on port /dev/cu.usbserial-1420

avrdude done.  Thank you.

*** [fuses] Error 1
============================================ [FAILED] Took 1.17 seconds ============================================

Environment       Status    Duration
----------------  --------  ------------
fuses_bootloader  FAILED    00:00:01.168
====================================== 1 failed, 0 succeeded in 00:00:01.168 ======================================

[platformio]
; Default build target
default_envs = Upload_UPDI

; Parameters used for all environments
[env]
platform = atmelmegaavr
framework = arduino

; Chip in use
board = ATmega4809
; Clock frequency in [Hz]
board_build.f_cpu = 16000000L
; Oscillator type (internal or external)
board_hardware.oscillator = internal
; Arduino pinout variant
board_build.variant = 48pin-standard

; Unflag build flags
build_unflags =
; Extra build flags
build_flags =

; Monitor port is auto detected. Override here
;monitor_port = ${env:Upload_UPDI.upload_port}
monitor_speed = 9600
monitor_dtr = 0

; Run the following command to upload with this environment
; pio run -t upload
[env:Upload_UPDI]
; Upload protocol for UPDI upload
upload_protocol = jtag2updi
;upload_port = /dev/cu.usbserial-1410
upload_speed = 115200
upload_flags =

; run the following command to set fuses
; pio run -e fuses_bootloader -t fuses
; run the following command to set fuses + burn bootloader
; pio run -e fuses_bootloader -t bootloader
[env:fuses_bootloader]
; Inherit upload settings from the Upload_UPDI environment
extends = env:Upload_UPDI

; Hardware settings
board_hardware.bod = 2.7v
board_hardware.eesave = yes
board_hardware.uart = no_bootloader
board_hardware.rstpin = reset
mrWheel commented 11 months ago

@MCUdude Hans, thanks for looking into this. May I conclude this is a bug that will be solved in the (near) future? Do I have to do something to make this happen?

MCUdude commented 11 months ago

It is most likely a bug (and hopefully not a "feature"), but I think you should report it in the PlatformIO VSCode plugin repo:

https://github.com/platformio/platformio-vscode-ide

SpenceKonde commented 10 months ago

Thanks guys. Closing this since this appears to be a bug in VSCode/PIO (I thought those were totally different things, shows how qualified I am to be working on this).

I'd probably do better as an amateuir rocket scientist than trying to make PIO stuff work. (You know the college I went to, my departments (ChE)'s main building was named after the father or rocketry, Robert H. Goddard. I remember hearing that way back in the old days as a student, that he accidentally blew up a small outbuilding or something as a student. Times sure have changed. Back then, they paid tuition by making things in the workshops and selling them. Pretty sure these days, that would earn you an expulsion, not a building named after you. shrug)