MacOS Compilation Error for cbor about solo1

[0x0ece]

I'm still on High Sierra unfortunately so I can't repro in the short time.

Are you able to remove that option -mmacosx-version-min=10.9 from tinycbor build process?
As an alternative you could try building on a linux Docker container?

[wakefieldite]

Unset CPPFLAGS for build, seemed to work
$ unset CPPFLAGS
go through compile process, merged hex files, and re-set CPPFLAGS environment variable.
$ export CPPFLAGS='-D_FORTIFY_SOURCE=2 -mmacosx-version-min=10.9'

I'll keep this open in case there are any other issues that come up in the process of testing.
If all goes well, I will close this issue. Thanks for the advice @0x0ece

[0x0ece]

Yes, good idea, let's keep it open until we have a smooth make process on Mac.

[wakefieldite]

For the sake of Googling, here are some of the errors I had going forward.
STM32CubeProgrammer.app/Contents/MacOs/bin/STM32_Programmer_CLI -c port=USB1 -halt -d /Users/$foo/Documents/GitHub/solo/targets/stm32l442/all.hex
USB1 needs to be lowercase, but that process is still not ready to be done.

-------------------------------------------------------------------
                        STM32CubeProgrammer v1.3.0
      -------------------------------------------------------------------

Error: Cannot open port USB, it may be used by another application or port name is invalid.

From Building

# Makes it boot to ST DFU once
python tools/programmer.py --st-dfu

Errors that come up need fido2 and ecdsa installed so:
pip install fido2 ecdsa

Now you can run the programmer.py above to get into dfu mode
once set in DFU mode, you will notice the light on your Solo Key is no longer on.

Now, I probably shouldn't have run:
STM32CubeProgrammer.app/Contents/MacOs/bin/STM32_Programmer_CLI -c port=usb1 -halt -d /Users/$foo/Documents/GitHub/solo/targets/stm32l442/all.hex

Because

To program a Solo Hacker device, run the following. Note you should only specify the application firmware, not the combined bootloader+application! I.e. not all.hex from above.
python tools/programmer.py target/stm32l442/solo.hex

Despite the return from STM32_Programmer_CLI:

      -------------------------------------------------------------------
                        STM32CubeProgrammer v1.3.0
      -------------------------------------------------------------------



USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : STM32  BOOTLOADER
SN          : 205F336C4648
FW version  : 0x011a
Device ID   : 0x0435
Device name : STM32L43xxx/STM32L44xxx
Device type : MCU
Device CPU  : Cortex-M4

Warning: halt command is not supported with this port: usb1


Memory Programming ...
Opening and parsing file: /
  File          : /
  Size          : 82824 Bytes
  Address       : 0x08000000


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 7]
Erasing memory corresponding to segment 1:
Erasing internal memory sectors [10 43]
Erasing memory corresponding to segment 2:
Erasing internal memory sector 108
Erasing memory corresponding to segment 3:
Erasing internal memory sector 113
Download in Progress:
[==================================================] 100%

File download complete
Time elapsed during download operation: 00:00:02.057

Because now, when trying to run
programmer.py target/stm32l442/solo.hex
Results with:

Traceback (most recent call last):
  File "/Users/$foo/Documents/GitHub/solo/tools/programmer.py", line 304, in <module>
    p.find_device()
  File "/Users/$foo/Documents/GitHub/solo/tools/programmer.py", line 85, in find_device
    raise RuntimeError('No FIDO device found')
RuntimeError: No FIDO device found

This same result is seen when trying to use the programmer.py to restart to dfu mode.

If the application gets bricked, you can hold down the button for 2 seconds while plugging it in the token make it stay in the bootloader. Holding the button an additional 5 seconds will return it to the ST DFU.

This also does not allow for writing via STM32CubeProgrammer.
Green light: Same error
No light: Same error
Orange and Green light together: Same error.

Using a second device, setting into DFU mode with programmer.py gives you this same error, so perhaps the first device is still in DFU mode, but that doesn't make sense why it would able to be written to by STM32.

Rebooting the second device, flashing the bootloader with:
python ~/Documents/GitHub/solo/tools/programmer.py ~/Documents/GitHub/solo/targets/stm32l442/solo.hex
Returns:

Bootloader not active.  Attempting to boot into bootloader mode...
Solo rebooted.  Reconnecting...
Exception ignored in: <bound method MacOsHidDevice.__del__ of <fido2._pyu2f.macos.MacOsHidDevice object at 0x10c293e48>>
Traceback (most recent call last):
  File "/Users/$foo/anaconda3/lib/python3.6/site-packages/fido2/_pyu2f/macos.py", line 458, in __del__
    self.device_handle,
AttributeError: 'MacOsHidDevice' object has no attribute 'device_handle'
erasing...
downloaded 100%
time: 7.66 s
Verifying...

Now, with the second device, getting the same issues.
However, manually rebooting to the orange and yellow light works enough to let me flash with STM32.
Then, when trying to get it to boot to the App instead of DFU as it is documented to do:

If you want it to always boot application, set nBOOT0=1
STM32_Programmer_CLI -c port=usb1 -ob nBOOT0=1

It hangs at:

      -------------------------------------------------------------------
                        STM32CubeProgrammer v1.3.0
      -------------------------------------------------------------------



USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : STM32  BOOTLOADER
SN          : 2084336E4648
FW version  : 0x011a
Device ID   : 0x0435
Device name : STM32L43xxx/STM32L44xxx
Device type : MCU
Device CPU  : Cortex-M4


UPLOADING OPTION BYTES DATA ...

  Bank          : 0x00
  Address       : 0x1fff7800
  Size          : 36 Bytes

[==================================================] 100%


PROGRAMMING OPTION BYTES AREA ...

  Bank          : 0x00
  Address       : 0x1fff7800
  Size          : 36 Bytes

[==================================================] 100%

After about 5 minutes of waiting, no movement, so ctrl+c.
Reboot to orange/green, no FIDO device found, and no joy with STM32.
No light without key press while powering on: no joy.
One thing I've noticed at this point is the documentation says 2 seconds holding the button while plugging in should get it in bootloader, 5 seconds for DFU.
orange/green comes on at 2 seconds, holding for 5 or longer shows no change.
It seems holding it slightly less than 2 seconds can get the green light while not holding it at all when plugging in gives no light. However, still no joy from programmer.py or STM32.

Before I brick my other two devices, any ideas on where to go from here?

[0x0ece]

@wakefieldite did you fix? I just upgraded to Mojave, all working fine for me.
I'd recommend a make clean, and then re-follow the instructions in the readme step by step. Also other people have had issues w/ python2, current instructions use python3.

(Also, please remember to hold down the button for a couple seconds when you plug Solo Hacker in.)

[wakefieldite]

@0x0ece I was able to get the solokey A's to work via building on Arch Linux, however it seems like there is something wrong with the USB-C versions. I'll make a different issue for that so we can close this issue and keep things on topic.