SimAVR and ATMega32U4 testing hangs

Advanced Solutions Debugging
1

Hello there,

I’m trying to do a little simulated testing for a Sparkfun Pro Micro system. I’m trying to get some automatic tests setup but I’ve hit a problem. I have a test that compiles up nicely, producing an elf and hex. When I execute ‘pio test --without-upload’, the testing hangs, saying “Testing…”

I’ve tried a couple of things. I downloaded the latest simavr and ran it against the elf that platformio created…

simavr -m atmega32u4 -f 16000000L -v .pio/build/sparkfun_promicro16/firmware.hex

I get the following:

Loaded 1 section of ihex
Load HEX flash 00000000, 4972

Looks like it’s placing the hex at the top of the memory block. Wouldn’t the bootloader normally be here? Perhaps simavr needs the sparkfun bootloader in addition to this hex? Not sure if this is the case. If it is, my question would be ‘how do I set this up in platformio?’.

However, I also tried the same test setup, but with an arduino uno, atmega328p and that worked absolutely fine, so perhaps the bootloader has nothing to do with it.

My current platformio.ini looks like this:


[env:sparkfun_promicro16]
platform = atmelavr
board = sparkfun_promicro16
; change microcontroller
board_build.mcu = atmega32u4
; change MCU frequency 
board_build.f_cpu = 16000000L ; or 8000000L if 8Mhz 3.3V version

upload_port = /dev/ttyACM*

framework = arduino
lib_deps = 
    bluerobotics/BlueRobotics MS5837 Library@^1.1.1
    sparkfun/SparkFun ISL29125 Breakout@^1.0.1
    adafruit/Adafruit BusIO@^1.14.1
    lowpowerlab/LowPower_LowPowerLab@^2.2
    RTClib
    Wire ; Needed for test only for some reason?
    SPI ; As above

platform_packages =
    platformio/tool-simavr

test_speed = 38400 ; will this cause issues as we use 38400 baud?

build_flags =
    -DSENSOR_TYPE=5 ;or SOUNDNET_V1_R5 in this case. Change depending on hardware version
    -Werror

extra_scripts =
    ; pre:apply_patches.py
    test_simulated.py

test_testing_command =
    ${platformio.packages_dir}/tool-simavr/bin/simavr
    -m
    atmega32u4
    -f
    8000000L
    ${platformio.build_dir}/${this.__env__}/firmware.elf

I thought perhaps the sparkfun stuff might not be quite right, so I also tried the test but for an arduino leonardo, which uses the same ATMega32U4. The same problem seems to occur. So this suggests something is wrong with simavr when used with the ATMega32U4.

I wonder, is this because of the USB part of this particular setup? Is it a permissions thing where the USB port can’t be created? I know the U4 has it’s own USB stack for this sort of thing. I’m running on Arch Linux so I thought, maybe try on Debian instead? Same trouble unfortunately.

Does anyone have any thoughts please? I figure I must have missed something.
Cheers
Ben

2

I would find it quite impressive if simavr had such a level of emulation / detection that it can detect a ATMega32u4 creating a USB CDC and redirecting its output to stdout. Just as a sanity check, have you tried the same simavr technique but with a regular board = uno firmware that uses the hardware UART?

3

Simavr lists the Atmega32u4 as one of the boards it supports, as does platformio, though I agree that adding usb support would indeed be some big additional steps. I suppose one could still make use of a simulated ATMega32U4 without USB support.

However, looking around, I’ve spotted this: https://groups.google.com/g/simavr/c/oc2vjBccUYo?pli=1
Simusb seems to be a thing. Not sure if this is perhaps what I need to do. Actually, looking further, it seems that simavr does indeed do something with usb - simavr/README at master · buserror/simavr · GitHub

Another option might be qemu instead of simavr. That appears to be an option in platformio - I know that USB devices can be simulated that way. It might be a bit more overkill perhaps but I suspect that would work.

Has anyone here done any simulated tested with this chip before please?
Cheers
Ben

4

I think a much painless way is to just use a different Unity configuration that uses Serial1 (hardware UART) instead of Serial (USB CDC) in hopes that this shows up natively – see

https://docs.platformio.org/en/latest/advanced/unit-testing/frameworks/unity.html

5

That’s a great idea! Thanks. It’s a shame I can’t go in over the USB - it does seem like some folks have made the effort here. It’d be nice to get an official statement from the devs - I might ask on the simavr github. Fortunately, our hardware design doesn’t use the hardware UART - the serial comms we have use software serial over different pins, so using the uart on pins 0 and 1 should be a fair comparison to the real hardware I think. I’ll give it a go. Cheers!