#141

once you get a chance to do it, could you submit a PR to update the readme/makefiles? and let me know if i need to do anything else in my fork of avr32-toolchain

1 Like
#142

Another bit of labour saving advice that I’ve just started using…

There is a function is the ASF called reset_do_soft_reset()1, that will soft reset an AVR32 (not that suprisingly!).

You can use this to avoid having to power cycle your whole modular system to flash the AVR32. In fact if you use a very very long press on the front panel button to activate the soft reset, the device automatically comes up in DFU mode by virtue of the front button still being held.

Combined with the autoflash.py script I posted earlier, you can get a pretty smooth development workflow.

The only thing that would make it even better is if @scanner_darkly’s two > one worked with the DFU cable as one of the devices.

1 see libavr32/asf/avr32/drivers/cpu/avr32_reset_cause.h

5 Likes
#143

This is excellent thank you, big improvement not having to power cycle every update, gonna try it out. I have a two > one but was afraid to test it with this workflow, sad to hear it doesn’t work, I wonder why that is? Maybe powering it by usb?

1 Like
#144

Ah. I guess I wrote that as a statement rather than a question. I don’t own a ‘two > one’ and so have no idea if it works or not!

#145

this is a great tip!

you still have to powercycle to make it exit DFU mode, right, unless i’m missing something?

re: two > one, is it the fact it’ll send power to the DFU cable? i wonder if using it with a cable that has power cut off would work.

#146

Ack, can’t remember. I’ll try again next time I’ve got the case out (hopefully this evening).

And I think it’s not to exit DFU mode, but to switch the USB port back into host mode from device mode.

It’s still on my todo list to see if I can get runtime switching between host and device mode working…

1 Like
#148

Finally got back to this…

I also have this recollection that you had to power cycle to make host USB devices work properly, but…

Just went back to test this on Meadow Physics and I had no problems reconnecting my grid after flashing, didn’t need to reboot at all.

I’ve got a firmware that I’ve been messing about with here (it’s just a 16 step trigger sequencer).

If you want to test the workflow, then:

  • first connect the USB A-A cable to the computer and module
  • second hold the front button down for 10+ seconds. Once it reboots (LEDs lit) it should show up on your computer in DFU mode
  • finally flash.sh
  • et voila, reconnect grid!

I might have a play with White Whale and Ansible and see if the same can work on those too, like I said, I could have sworn you needed to reboot to fix the USB mode…

2 Likes
#149

Looks to me like using dfu-programmer ... launch, Teletype works without a power cycle. The docs and released firmware update scripts use dfu-programmer ... start rather than launch, as far as I can tell start is equivalent to launch --no-reset. Using start Teletype’s screen comes on / displays a prompt but it is not responsive to keyboard input until a power cycle, if I launch then the keyboard works right away.

3 Likes
#150

Yeah, that was my sneaking suspicion too, that was the one obvious difference I noticed in the flash.sh scripts.

I think you need a newer version of dfu-programmer to use launch, but I think dfu-programmer reset will work on older versions instead.

Probably worth patching the flash scripts for both Ansible and Teletype.

1 Like
#151

Hello,
I am having issues installing the avr32 toolchain for the monome. I am trying to follow the instructions provided via GitHub but the libraries seem to be unavailable. What do you suggest to do as a workaround for this type of issue?

brew install mpfr gmp libmpc texinfo dfu-programmer
git clone https://github.com/monome/avr32-toolchain.git
cd avr32-toolchain
PREFIX=$HOME/avr32-tools make install-cross

I get the following error:
[ -d stamps ] || mkdir stamps ;
touch stamps/extract-binutils;
cd downloads && curl -LO http://distribute.atmel.no/tools/opensource/Atmel-AVR32-GNU-Toolchain/3.4.2/avr32-patches.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:–:-- 0:00:04 --:–:-- 0
curl: (7) Failed to connect to distribute.atmel.no port 80: Network is unreachable
make: *** [downloads/avr32-patches.tar.gz] Error 7

#153

Hi, try to clone this repository

#154

To be clear

Instead of running:

git clone https://github.com/monome/avr32-toolchain.git

I should run:

git clone https://github.com/denravonska/avr32-toolchain.git

Should I run the rest of the code aftewards?

It also says in the github repo

To install on OSX in ~/avr32-tools:

This means that I should create a folder with that name right?
I am new to this and sometimes the instructions seem vague.

#155

are you actually trying to do some custom programming the avr32? or are you just trying to upgrade/flash the firmware?

#156

I am trying to program a DIY module. The module shows one LED when pressing the push-button on power on and I am getting the following error when running the update_firmware.command:

dfu-programmer: no device present.
dfu-programmer: no device present.
dfu-programmer: no device present.

#157

which module?

hold the key next to the usb port when powering up. connect the USB programmer cable prior to powering up.

#158

Teletype, I am trying to install the firmware for the first time, and the process seems a bit more complicated than what I am used to,

#160

i’ve managed to set up github actions to build avr32 toolchain and build firmware:

if you open the link you should see 2 artifacts: the tools and the built ansible firmware. i should mention that for public repos github actions and storing artifacts is free.

i’ve updated my fork of avr32_toolchain repo in the process which i think should fix some of the errors reported earlier (i also had to modify one of the download commands in my fork, was getting a cert mismatch error).

this is not a replacement for setting up the toolchain locally however - yet. it takes about 20 minutes to do a full build since it has to build the toolchain each time. this time can be shortened by just storing the built toolchain (~400Mb) somewhere. what i did was take advantage of the fact that you can create artifacts and have separate actions - so you would only need to build the toolchain once (or, more accurately, every 90 days since that’s the max time github allows for storing artifacts in public repos, still not bad). but i ran into another issue and hoping somebody with more knowledge of bash could help me figure it out.

it downloads and unpacks the toolchain artifact, but when it tries to build the firmware it shows this:

CC      ../main.o
make: execvp: avr32-gcc: Permission denied
make: *** [../main.o] Error 127
../libavr32/asf/avr32/utils/make/Makefile.avr32.in:402: recipe for target '../main.o' failed

i assume it has something to do with permissions on the unpacked toolchain files? how can i fix it? it runs fine if i use the toolchain after generating it as part of the same job.

2 Likes
#161

this is brilliant, thank you. i’ll check out the scripts, though my bash skills are only moderate. @simonvanderveldt and @ngwese are wizards at this stuff, however.

1 Like
#162

Looking at the GH action setup my guess would be that the tool chain build job and the firmware build job are running on different VMs. Since the second VM doesn’t have the packages installed on the first VM the avr32-tools artifact is missing some runtime dependencies.

TBH what might make the most sense here is packaging up the avr32 tool chain as a container (similar to how the norns kernel cross compilation is setup)… then building is just pulling down the container and going. I can help if you’d like to get a similar setup running. It would have the side benefit of creating a stable tool chain for local builds as well (using docker)

2 Likes
#163

Hi all, not about much at the moment (plague / childcare, etc, etc).

Just a quick infodump. If you’re planning on using a container, you might have an easier time just using the Atmel provided binaries we’re currently using with Travis:

See the install section of the .travis.yml file.

From what I recall the Atmel binaries are slowly starting to bitrot, so while they work just fine in the older Ubuntu distro that Travis uses as default they might not work in newer distros. AFAIK they are statically compiled so it might be quite a trivial fixup with patchelf or LD_LIBRARY_PATH.

It might even be worth having a go to see if the binaries work in the GitHub action environment. Otherwise just pick a slightly older distro for the container.

Hope that’s helpful.

1 Like