Uploading to AVR using Raspberry Pi GPIO (avrdude GPIO reset)

Historically my project has used a modified avrdude which triggers a GPIO pin to reset the AVR at the correct point rather than the standard UART RST. Would it be possible to either:

  • Instruct platformio to use a GPIO toggle avr rest on upload?

  • Or tell platform io to upload via system avrdude which already has the avrdude gpio reset hack installed

That is easy to do with new PlatformIO 3.0 and decentralized architecture for development platforms where you will be able to control packages, versions and etc.

As for the temporary solution with PlatformIO 2.0, please take a look at this comment:

I’ve just remembered that we implemented this feature for raspduino:
https://github.com/platformio/platformio/blob/develop/platformio/builder/scripts/atmelavr.py#L52

What is the name of your Arduino board behind RPi?

Sounds good, when is 3.0 due to be released? I won’t hold you to it… :wink:

It’s an emonPi, its got an ATmega328 with Uno bootloader and GPIO 4 / pin 7 used for reset.

Could you (or I?) create a custom board in platformio for the emonPi?

It is quite complicated question :blush: I hope, this summer.

I’ll add it. Please specify here the own board manifest using this example platform-atmelavr/raspduino.json at develop · platformio/platform-atmelavr · GitHub. Thanks.

Done: emonPi manifest PR:

I have not been able to test this custom board since I seem to encounter an error while adding any custom board, I created a new topic:

I have also added the corresponding entry for GPIO4 / pin7 reset:

I have just tried to test GPIO and I’m having permissions error

scons: *** [upload] /sys/class/gpio/gpio18/direction: Permission denied

I’m not sure why there is a permissions error since I can successfully control the GPIO using non root commands (pi user) bash e.g.

   echo 4 >  /sys/class/gpio/export
   echo out > /sys/class/gpio/gpio4/direction 
   echo 1 > /sys/class/gpio/gpio4/value 
   echo 0 > /sys/class/gpio/gpio4/value 
   echo 4 >  /sys/class/gpio/unexport 

Does platformio run as pi user on a RaspberryPi? If not I will need to add platformio to the gpio user group.

Keep up the good work, love patformio. I’ve just donated.

Bountysource :slight_smile:

1 Like

Thanks a lot for your donation! :moneybag: :blush:

Did you try PlatformIO 2.9.5.dev1 ?

PlatformIO runs from the current user. This is a generic command.

No I haven’t. I have installed via python pip. How can I switch branch and update?

This is what Ii suspected. However it’s strange I can manipulate the GPIO via bash commands but when the same bash commands are executed by platformio we get a permissions error?

I can give you remote access to my RasPi to debug if this would help?

See Redirecting...

Good idea! Please contact here with PM message and credentials. Thanks.

Done!

I’ve managed to install the dev version, took a couple of goes, seemed to install ok in the end but did get a def open_serial_connection(*, SyntaxError: invalid syntax error from the serial library.

sudo pip install -U https://github.com/platformio/platformio/archive/develop.zip
Downloading/unpacking https://github.com/platformio/platformio/archive/develop.zip
  Downloading develop.zip (11.8MB): 11.8MB downloaded
  Running setup.py (path:/tmp/pip-RShPDr-build/setup.py) egg_info for package from https://github.com/platformio/platformio/archive/develop.zip
    
Requirement already up-to-date: bottle<0.13 in /usr/local/lib/python2.7/dist-packages (from platformio==2.9.5.dev1)
Requirement already up-to-date: click>=3.2,<6 in /usr/local/lib/python2.7/dist-packages (from platformio==2.9.5.dev1)
Requirement already up-to-date: lockfile>=0.9.1,<0.13 in /usr/local/lib/python2.7/dist-packages (from platformio==2.9.5.dev1)
Downloading/unpacking requests>=2.4.0,<3 from https://pypi.python.org/packages/99/b4/63d99ba8e189c47d906b43bae18af4396e336f2b1bfec86af31efe2d2cb8/requests-2.10.0-py2.py3-none-any.whl#md5=abf5a77de3e8a5973c738cca884502a0 (from platformio==2.9.5.dev1)
  Downloading requests-2.10.0-py2.py3-none-any.whl (506kB): 506kB downloaded
Downloading/unpacking colorama from https://pypi.python.org/packages/b7/8e/ddb32ddaabd431813e180ca224e844bab8ad42fbb47ee07553f0ec44cd86/colorama-0.3.7-py2.py3-none-any.whl#md5=7d474974709d63d1f249ec61f8e62663 (from platformio==2.9.5.dev1)
  Downloading colorama-0.3.7-py2.py3-none-any.whl
Downloading/unpacking pyserial<4 from https://pypi.python.org/packages/aa/e7/e3109a5db1d76f459987ee3def5a34cd4ea825ac2320bd0704a8189cbc15/pyserial-3.1-py2.py3-none-any.whl#md5=dd199d56fbb257b3277690bcb8591f36 (from platformio==2.9.5.dev1)
  Downloading pyserial-3.1-py2.py3-none-any.whl (93kB): 93kB downloaded
Installing collected packages: requests, colorama, pyserial, platformio
  Found existing installation: requests 2.4.3
    Not uninstalling requests at /usr/lib/python2.7/dist-packages, owned by OS
  Found existing installation: colorama 0.3.2
    Not uninstalling colorama at /usr/lib/python2.7/dist-packages, owned by OS
  Found existing installation: pyserial 2.6
    Not uninstalling pyserial at /usr/lib/python2.7/dist-packages, owned by OS
Compiling /tmp/pip-build-wx4XOQ/pyserial/serial/aio.py ...
  File "/tmp/pip-build-wx4XOQ/pyserial/serial/aio.py", line 366
    def open_serial_connection(*,
                                ^
SyntaxError: invalid syntax

  Running setup.py install for platformio
    
    Installing platformio script to /usr/local/bin
    Installing pio script to /usr/local/bin
Successfully installed requests colorama pyserial platformio
Cleaning up...

After installing the dev version I could see our emonpi board listed :+1:

Trying to upload resulted in the same gpio permission error:

scons: *** [upload] /sys/class/gpio/gpio4/direction: Permission denied

I tried uninstalling platformio then installing it under user environment using pip install -- user, this time I get error when trying to upload:

scons: *** [upload] Device or resource busy

I’m not sure if this is progress or not? I can upload fine on ttyAMA0 using avrdude-rpi

Let me know if anything else I can try

For the record this issue has now been fixed thanks to @ivankravets :thumbsup:

1 Like

Hi @glynhudson,

How did you solve the problem? I’m running into exactly the same issues when trying to upload a modified firmware on emonpi.

pi@emonpi:~/emonpi/firmware $ ~/.local/bin/pio --version
PlatformIO, version 2.11.1

First time I run, I get:

pi@emonpi:~/emonpi/firmware $ ~/.local/bin/pio run -t upload
[Sat Jul 16 15:48:01 2016] Processing emonpi (framework: arduino, lib_install: 19,54,116,252,576, build_flags: -DBUILD_TAG=0.0.0, platform: atmelavr, board: emonpi, upload_port: /dev/ttyAMA0)
-------------------------------------------------------------------------------
BeforeUpload(["upload"], ["/home/pi/data/pioenvs/emonpi/firmware.hex"])
Looking for upload port/disk...
Manually specified: /dev/ttyAMA0
scons: *** [upload] /sys/class/gpio/gpio4/direction: Permission denied
========================= [ ERROR ] Took 5.18 seconds =========================

Second time, I get

pi@emonpi:~/emonpi/firmware $ ~/.local/bin/pio run -t upload
[Sat Jul 16 15:54:58 2016] Processing emonpi (framework: arduino, lib_install: 19,54,116,252,576, build_flags: -DBUILD_TAG=0.0.0, platform: atmelavr, board: emonpi, upload_port: /dev/ttyAMA0)
-------------------------------------------------------------------------------
BeforeUpload(["upload"], ["/home/pi/data/pioenvs/emonpi/firmware.hex"])
Looking for upload port/disk...
Manually specified: /dev/ttyAMA0
scons: *** [upload] Device or resource busy
========================= [ ERROR ] Took 5.18 seconds =========================

Thanks in advance!

grtz, Koen

Could you try with sudo ~/.local/bin/pio run -t upload?

Running with sudo reinstalls the complete platformio environment, now in /root directory and results in the same error:

...
Check program size...
text	   data	    bss	    dec	    hex	filename
18854	     94	    857	  19805	   4d5d	/root/data/pioenvs/emonpi/firmware.elf
avr-objcopy -O ihex -R .eeprom /root/data/pioenvs/emonpi/firmware.elf /root/data/pioenvs/emonpi/firmware.hex
BeforeUpload(["upload"], ["/root/data/pioenvs/emonpi/firmware.hex"])
Looking for upload port/disk...
Manually specified: /dev/ttyAMA0
scons: *** [upload] Device or resource busy
======================== [ ERROR ] Took 21.94 seconds ======================

Note, that I’m able to manually upload the firmware.hex without sudo using:

pi@emonpi:~/emonpi/firmware $ avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/home/pi/data/pioenvs/emonpi/firmware.hex 
avrdude-original: Using autoreset DTR on GPIO Pin 7

avrdude-original: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude-original: Device signature = 0x1e950f
avrdude-original: NOTE: "flash" memory has been specified, an erase cycle will be performed
                  To disable this feature, specify the -D option.
avrdude-original: erasing chip
avrdude-original: reading input file "/home/pi/data/pioenvs/emonpi/firmware.hex"
avrdude-original: input file /home/pi/data/pioenvs/emonpi/firmware.hex auto detected as Intel Hex
avrdude-original: writing flash (18948 bytes):

Writing | ################################################## | 100% 2.68s

avrdude-original: 18948 bytes of flash written
avrdude-original: verifying flash memory against /home/pi/data/pioenvs/emonpi/firmware.hex:
avrdude-original: load data flash data from input file /home/pi/data/pioenvs/emonpi/firmware.hex:
avrdude-original: input file /home/pi/data/pioenvs/emonpi/firmware.hex auto detected as Intel Hex
avrdude-original: input file /home/pi/data/pioenvs/emonpi/firmware.hex contains 18948 bytes
avrdude-original: reading on-chip flash data:

Reading | ################################################## | 100% 2.00s

avrdude-original: verifying ...
avrdude-original: 18948 bytes of flash verified

avrdude-original: safemode: Fuses OK (E:00, H:00, L:00)
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe

avrdude-original done.  Thank you.

strace: |autoreset: Broken pipe

As I learnt now, is that the avrdude in emonpi has been modified, so I also tried replacing the avrdude in ~/data/.platformio/packages/tool-avrdude executable by the modified one, but this results in the same error.

Have you stopped emonhub python service? This will be using the serial port

$ sudo service emonhub stop

Yes, I’ve stopped emonhub before runnig pio and before running avrdude manually.

Hi all,

Next, I tried after rebooting the emonpi. Now, sudo pio -t upload works, but pio -t upload as regular user still doesn’t. This is strange as both gpio and dialout are in groups:

pi@emonpi:~ $ groups
pi adm dialout cdrom sudo audio video plugdev games users input netdev gpio i2c spi

I looked at the source code builder/scripts/atmelavr.py and notice the following:

    if env.subst("$BOARD") in ("raspduino", "emonpi"):

        def _rpi_sysgpio(path, value):
            with open(path, "w") as f:
                f.write(str(value))

        pin_num = 18 if env.subst("$BOARD") == "raspduino" else 4
        _rpi_sysgpio("/sys/class/gpio/export", pin_num)
        _rpi_sysgpio("/sys/class/gpio/gpio%d/direction" % pin_num, "out")
        _rpi_sysgpio("/sys/class/gpio/gpio%d/value" % pin_num, 1)
        sleep(0.1)
        _rpi_sysgpio("/sys/class/gpio/gpio%d/value" % pin_num, 0)
        _rpi_sysgpio("/sys/class/gpio/unexport", pin_n

However, my /sys/class/gpio doesn’t have 18 or 4, but:

pi@emonpi:/sys/class/gpio $ ls -al
total 0
drwxrwx---  2 root gpio    0 Jul 16 17:07 .
drwxr-xr-x 48 root root    0 Jul 16 17:17 ..
-rwxrwx---  1 root gpio 4096 Jul 16 17:07 export
lrwxrwxrwx  1 root gpio    0 Jul 16 17:07 gpio17 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpio17
lrwxrwxrwx  1 root gpio    0 Jul 16 17:07 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0
lrwxrwxrwx  1 root gpio    0 Jul 16 17:07 gpiochip100 -> ../../devices/platform/soc/soc:virtgpio/gpio/gpiochip100
-rwxrwx---  1 root gpio 4096 Jul 16 17:07 unexport

Could this explains the issue?

@glynhudson I remember that you had the same problem. Have we resolved it?