Component build fails

[joustava]

Have the AtomVM (0.6.5) repo and IDF (5.4) related dependencies/tools installed on a Mac (using fish shell)
When I. add this repo to components and run menuconfig I see this component checked. But building it give me the following error:

xtensa-esp-elf/bin/ld: unrecognized option '--whole-archive /Users/joost/Workspace/atomvm/AtomVM/src/platforms/esp32/build/esp-idf/atomvm_dht/libatomvm_dht.a -Wl'

Did I miss anything?

[UncleGrumpy]

You probably did not miss anything, I believe this driver has been neglected for a while. The DHT-11 is a bit of a flakey sensor, usually something like a BME-180 (280 or BMP-180/280), or SHT-3x are more reliable. There are drivers for these in the atomvm_lib repo.

I will try to get this driver updated soon, it had not been updated to work with IDF-v5.x yet, but that should be a small fix. 🤞

[joustava]

It's the only type of temperature sensor I have lying around at the moment and I thought it would be a good exercise to familiarize myself with building custom components. When you'd be able to fix it great! Or point me in the right direction to make a PR that's fine too.

Thanks for your time!

[UncleGrumpy]

Completely understandable! I would want to try any sensor I had access too. ;-)

If you are already familiar with ESP-IDF it is a matter of making the changes necessary to migrate from ESP-IDF v4.x to version 5.x builds. There were changes to the way libraries are linked in version 5. If not, this may not be the best first PR for you attempt for an AtomVM project.

I have not looked closely yet to know if there are any differences among supported 5.x versions, that apply to this driver, which need to be handled differently with some ifdef macros, but I suspect not.

[UncleGrumpy]

I don't have a DHT-11 handy at the moment to test the functionality, but PR #3 should take care of any build problems. If you don't mind testing it and reporting the results. ;-)

[joustava]

The build itself seems to go fine, but running into some issues further down the line.

For reference:

Earlier I was able to flash a 0.6.5 release image with these steps

$ esptool.py --chip auto --port /dev/tty.usbserial-0001 --baud 921600 erase_flash
esptool.py v4.8.1
Serial port /dev/tty.usbserial-0001
Connecting.......
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6 (revision v1.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: b4:e6:2d:b2:40:89
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Erasing flash (this may take a while)...
Chip erase completed successfully in 7.1s
Hard resetting via RTS pin...


$ esptool.py \
       --chip auto \
       --port /dev/tty.usbserial-0001 --baud 921600 \
       --before default_reset --after hard_reset \
       write_flash -u \
       --flash_mode dio --flash_freq 40m --flash_size detect \
       0x1000 \
       AtomVM-esp32-elixir-v0.6.5.img
esptool.py v4.8.1
Serial port /dev/tty.usbserial-0001
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...............
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6 (revision v1.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: b4:e6:2d:b2:40:89
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Flash will be erased from 0x00001000 to 0x0021dfff...
SHA digest in image updated
Wrote 2228224 bytes at 0x00001000 in 28.4 seconds (627.6 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

Then I created a new mix project,
added {:exatomvm, git: "https://github.com/atomvm/ExAtomVM"} as dependency
created an avm_deps folder in project root and added the atomvmlib-v0.6.5.avm file to it (from 0.6.5 release).

added to the project settings in mix

atomvm: [
        start: Tinker,
        # https://github.com/atomvm/exatomvm/issues/30
        esp32_flash_offset: 0x210000
      ]

and the actual module

defmodule Tinker do
  @doc """
  Application entry point.
  """
  def start do
    :io.format("Hello World~n")
  end
end

then flashed it

mix atomvm.esp32.flash --port /dev/tty.usbserial-0001
===> Analyzing applications...
===> Compiling uf2tool
==> exatomvm
Compiling 8 files (.ex)
    warning: variable "flash_offset" is unused (if the variable is not meant to be used, prefix it with an underscore)
    │
 94 │   defp parse_args([<<"--flash_offset">>, "0x" <> hex = flash_offset | t], accum) do
    │                                                        ~~~~~~~~~~~~
    │
    └─ lib/mix/tasks/esp32_flash.ex:94:56: Mix.Tasks.Atomvm.Esp32.Flash.parse_args/2

Generated exatomvm app
==> tinker
Compiling 1 file (.ex)
Generated tinker app
esptool.py v4.8.1
Serial port /dev/tty.usbserial-0001
Connecting......
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting.....
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6 (revision v1.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: b4:e6:2d:b2:40:89
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Flash will be erased from 0x00250000 to 0x002a7fff...
Writing at 0x00250000... (4 %)
Writing at 0x00254000... (9 %)
Writing at 0x00258000... (13 %)
Writing at 0x0025c000... (18 %)
Writing at 0x00260000... (22 %)
Writing at 0x00264000... (27 %)
Writing at 0x00268000... (31 %)
Writing at 0x0026c000... (36 %)
Writing at 0x00270000... (40 %)
Writing at 0x00274000... (45 %)
Writing at 0x00278000... (50 %)
Writing at 0x0027c000... (54 %)
Writing at 0x00280000... (59 %)
Writing at 0x00284000... (63 %)
Writing at 0x00288000... (68 %)
Writing at 0x0028c000... (72 %)
Writing at 0x00290000... (77 %)
Writing at 0x00294000... (81 %)
Writing at 0x00298000... (86 %)
Writing at 0x0029c000... (90 %)
Writing at 0x002a0000... (95 %)
Writing at 0x002a4000... (100 %)
Wrote 360448 bytes at 0x00250000 in 31.7 seconds (91.0 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

And I could see from console that I was able to flash sucessful

AtomVM init.
I (932) sys: Loaded BEAM partition main.avm at address 0x210000 (size=1048576
bytes)
Starting application...
Hello World
AtomVM finished with return value: ok
I (972) AtomVM: AtomVM application terminated.  Going to sleep forever ...

After some failed attempts getting dht lib with a basic code on the target, I went back to try to get the official release back like above. But now whenever I try to flash it I get

AtomVM init.
I (883) sys: Loaded BEAM partition main.avm at address 0x250000 (size=1048576 bytes)
Starting application...
Unable to allocate space for modules list.  No stacktrace will be created
CRASH
======
pid: <0.1.0>

Stacktrace:
undefined

cp: #CP<module: 0, label: 34, offset: 0>

x[0]: error
x[1]: function_clause
x[2]: undefined

Stack
------



Mailbox
--------


Monitors
--------

or

---
AtomVM init.
I (883) sys: Loaded BEAM partition main.avm at address 0x250000 (size=1048576 bytes)
Failed app start: invalid_avm.
Starting network...
I (973) network_driver: AP ssid: AtomVM-ESP32
I (973) network_driver: AP

I suspect something in my setup has changed but I cannot pinpoint what exactly. What I do notice is that it tries to find the entry point from 0x250000 instead of 0x210000. And related to that did find
atomvm/exatomvm#22

I understand this is not directly related to the original issue but I'd like to be able to review the changes. Any idea what I might have messed up? :)

[joustava]

Ah, seems the entry point addres had changed (maybe I had a bit older AtomVM image version earlier because of trying different things) my bad, and now when I return :ok from the start function I do get a wonderful error message:

Starting application...
CRASH
======
pid: <0.1.0>

Stacktrace:
[{io,undefined,0,[{file,"/home/runner/work/AtomVM/AtomVM/libs/estdlib/src/io.erl"},{line,37}]}]

cp: #CP<module: 4, label: 11, off

I guess I understand the error that it cant find io 'module' but I'd expected that to be available by default in the image/avm plus this seemed to work fine earlier. So still have some issue with my setup.

UPDATE: change

:io.format("Hello World~n") -> :io.format(~c"Hello World~n") 

and then it works.
Ok, now on to trying to setup this component.

[UncleGrumpy]

Ok. I just submitted a PR to update the ExAtomVM README and the AtomVM documentation with the new correct offset to use. It should actually be 0x250000. We changed that recently to accommodate the extra Elixir modules we have been adding.

Also the avm_dep folder is not needed (except for stm32) if you are using a release image.

That should get you working as expected.

[UncleGrumpy]

You will need to reflash the image one more time first... when you flashed the app to 0x210000 some if the boot.amv partition (the area Elixir modules occupy) would have been overwritten with your application... also note that if you are working with rebar3 and the atomvm_rebar_plugin with an Elixir support image it defaults to the Erlang only image default of 0x210000, so be sure to change the offset in rebar.conf or with the --offset parameter, or you would encounter the same problem.

[joustava]

I managed to create a esp32 build with the component based on AtomVM sources on master and creating the specific esp32 build but this seems to look at old address for the application:

And needed to set

flash_offset: 0x210000

instead of

esp32_flash_offset: 0x210000

But seems to work:

AtomVM init.
I (893) sys: Loaded BEAM partition main.avm at address 0x210000 (size=1048576 bytes)
Starting application...
Hello World ESP32
Temperature: 22.4C  Humidity: 32.8%
AtomVM finished with return value: ok
I (1003) AtomVM: AtomVM application terminated.  Going to sleep forever ...

[UncleGrumpy]

My apologies, I have been helping resolve a few issues here on GitHub as well as in the AtomVM Telegram chat and I think I got my wires crossed and was thinking you were using an Elixir supported image... they use a different offset to accommodate the extra modules.

If you are using the non Elixir images then 0x210000 is the correct offset.

Glad to hear you got it working despite my bad advice! 😂

[joustava]

No apologies needed, you got me on the right track!
Out of curiosity: How would I build such an Elixir supported image (didn't realize I wasn using a non-elixir version tbh)? What is the benefit?

[UncleGrumpy]

If you want to build an elixir supported image you first need a version of elixir (compatible with your OTP version) installed on your system. Then you either need to copy partitions-elixir.cvs to partitions.cvs or just select partitions-elixir.cvs as the custom partition map in menuconfig. And then when using build/mkimage.sh you need to pass the path to the elixir_esp32boot.avm that is created when doing the initial generic_unix/libraries build... like this (from inside the AtomVM/src/platforms/esp32 directory):

./build/mkimage.sh --boot ../../../build/libs/esp32boot/elixir_esp32boot.avm

The advantage is you can use either Erlang or Elixir applications with these images... Our Elixir support has been rapidly catching up with our Erlang support, and is getting a lot of attention lately... not to say Erlang support is slowing down either, we hope to have disterl support in the next 0.7.0 release.

But if you are mostly interested in Erlang development you are better off just sticking with the thinner images, as our atomvm_rebar3_plugin defaults to using the Erlang only 0x210000 offset. This way you don't need to remember to change your rebar.config file or pass the parameter every time.

[joustava]

Got the Elixir build to work as well, thanks for your help!
I am using exatomvm in a Mix project so I thought an Elixir was a requirement.

Did some more test runs, now reading in a spawned loop:

AtomVM init.
I (893) sys: Loaded BEAM partition main.avm at address 0x250000 (size=1048576 bytes)
Starting application...
ESP32 temperature and humidity sensor starting...
Temperature: 22.1C  Humidity: 33.0%
Temperature: 22.1C  Humidity: 33.2%
Temperature: 22.1C  Humidity: 33.1%
Temperature: 22.1C  Humidity: 33.1%
Temperature: 22.1C  Humidity: 33.0%
Temperature: 22.1C  Humidity: 33.0%
Temperature: 22.1C  Humidity: 33.0%
Temperature: 22.1C  Humidity: 33.0%
Temperature: 22.1C  Humidity: 33.0%
Temperature: 22.1C  Humidity: 33.0%
Temperature: 22.1C  Humidity: 36.8%
Temperature: 22.2C  Humidity: 38.8%
Temperature: 22.4C  Humidity: 39.3%
Temperature: 23.2C  Humidity: 96.3%
Temperature: 23.9C  Humidity: 99.9%
Error taking reading: {error,bad_read}
Temperature: 24.9C  Humidity: 99.9%
Temperature: 24.8C  Humidity: 99.9%
Temperature: 24.3C  Humidity: 99.9%
Temperature: 23.9C  Humidity: 99.9%
Temperature: 23.5C  Humidity: 99.9%
Temperature: 23.3C  Humidity: 99.9%
Temperature: 23.2C  Humidity: 89.8%
Temperature: 23.2C  Humidity: 73.7%
Temperature: 23.3C  Humidity: 60.1%
Temperature: 23.3C  Humidity: 49.6%
Temperature: 23.3C  Humidity: 43.6%
Temperature: 23.3C  Humidity: 40.1%

The bad_read should probably a bad_breath :) but it seems to be working fine.