Is the Raspberry Pi Build HAT firmware in this repository stale?

[pmunts]

When I run a minimal program that just instantiates a Raspberry Pi Build HAT Brick object, I get the following failure:

Unhandled exception. System.IO.IOException: BuildHat firmware signture error
   at Iot.Device.BuildHat.Brick.GetBuildHatInformation()
   at Iot.Device.BuildHat.Brick..ctor(String port, GpioController controller, Int32 reset, Boolean shouldDispose)
   at Program.<Main>$(String[] args)
Aborted

This error happens even if the Build HAT firmware has already been loaded e.g. by the Python library. I conjecture that the firmware files included in the Iot.Device.Bindings NuGet package are incompatible with the current Raspberry Pi Build HAT boot loader. See the Build HAT firmware versions in this repository and the Python library repository at the very bottom of this issue submission.

Steps to reproduce

Build and run the following test program:

using Iot.Device.BuildHat;

var brick = new Brick("/dev/ttyAMA0");
brick.Dispose();

Expected behavior

Program runs successfully.

Actual behavior

Program fails with error message above.

Versions used

Build machine dotnet --info:

.NET SDK:
 Version:           9.0.302
 Commit:            bb2550b9af
 Workload version:  9.0.300-manifests.183aaee6
 MSBuild version:   17.14.13+65391c53b

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26100
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\PROGRA~1\dotnet\sdk\9.0.302\

.NET workloads installed:
 [wasm-tools]
   Installation Source: VS 17.14.36301.6
   Manifest Version:    9.0.7/9.0.100
   Manifest Path:       C:\PROGRA~1\dotnet\sdk-manifests\9.0.100\microsoft.net.workload.mono.toolchain.current\9.0.7\WorkloadManifest.json
   Install Type:              Msi

Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.7
  Architecture: x64
  Commit:       3c298d9f00

.NET SDKs installed:
  5.0.202 [C:\PROGRA~1\dotnet\sdk]
  6.0.100 [C:\PROGRA~1\dotnet\sdk]
  9.0.302 [C:\PROGRA~1\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.30 [C:\PROGRA~1\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.30 [C:\PROGRA~1\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.4 [C:\PROGRA~1\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.5 [C:\PROGRA~1\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.0 [C:\PROGRA~1\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.5 [C:\PROGRA~1\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.18 [C:\PROGRA~1\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.7 [C:\PROGRA~1\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.30 [C:\PROGRA~1\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.4 [C:\PROGRA~1\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.5 [C:\PROGRA~1\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.0 [C:\PROGRA~1\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.5 [C:\PROGRA~1\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.12 [C:\PROGRA~1\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.18 [C:\PROGRA~1\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.7 [C:\PROGRA~1\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 5.0.4 [C:\PROGRA~1\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.5 [C:\PROGRA~1\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.0 [C:\PROGRA~1\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.5 [C:\PROGRA~1\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.18 [C:\PROGRA~1\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.7 [C:\PROGRA~1\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  arm64 [C:\Program Files\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\arm64\InstallLocation]
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Target machine dotnet --info:

Host:
  Version:      9.0.7
  Architecture: arm64
  Commit:       3c298d9f00
  RID:          linux-arm64

.NET SDKs installed:
  No SDKs were found.

.NET runtimes installed:
  Microsoft.NETCore.App 9.0.7 [/usr/local/lib/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  DOTNET_ROOT       [/usr/local/lib/dotnet]

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Package versions:

  <ItemGroup>
    <PackageReference Include="Iot.Device.Bindings" Version="4.0.1" />
  </ItemGroup>

Raspberry Pi Build HAT bootloader version:

BHBL> version
BuildHAT bootloader version 1631704133 2021-09-15T12:08:53+01:00

Build HAT firmware in the dotnet/iot repository:

~/iot/src/devices/BuildHat/data$ cat version ; md5sum -b *
1636109636
c86bb5fd7aeb34c93c774e142af2fdf3 *firmware.bin
c7529d660e16b6c3e162c33a25bdcc43 *signature.bin
c43ca26e77d995b579e8626e809e758a *version

Build HAT firmware in the Python library repository:

~/python-build-hat/buildhat/data$ cat version ; md5sum -b *
1737564117
711180af1a9c2535c2874e3104174bca *firmware.bin
12caf25acaf3fdd1046f483cb7f1957f *signature.bin
3d422c3562bbacab4fab45ff4c63a920 *version

[raffaeler]

The exception is thrown here:

iot/src/devices/BuildHat/Brick.cs

Line 1515 in 7bfaaa5

throw new IOException("BuildHat firmware signture error");

I don't have the device, but I see from that source file that the firmware can have different formats.

Are you able to get the firmware (not the bootloader) version from Python and post it here?
It may help to understand whether the format has dramatically changed.

[pmunts]

This is the version string for the Build HAT firmware in the Python library:

Firmware version: 1737564117 2025-01-22T16:41:57+00:00

[raffaeler]

Thanks but the fail happens on the firmware signature.
From the source code I see you can get the signature by sending the signature command (or using the python library).
Please post also the raw signature. Apparently the mismatch is there.

[pmunts]

I have started to debug this problem and made some progress. I'm instrumenting Brick.cs with System.Console.Writeline()'s (how do I make use of the existing logging code?) and building Iot.Device.Bindings.4.0.1-dev.nupkg and installing it to my local NuGet feed. Then I build and test a small program that is supposed to spin a passive motor.

By snooping on the serial port dialog between the test program and the Build HAT, I've determined that BuildHat firmware signture error results from a classic serial port race condition: Calling PortReadLine() or PortReadExisting() immediately after PortWrite() results in incomplete response strings. Adding System.Threading.Thread.Sleep(10); after Brick.cs line 1606 eliminates the BuildHat firmware signture error when the Build HAT firmware has been loaded or not. In the latter case, the firmware is loaded correctly.

Now my motor test program runs!

[raffaeler]

Great diagnostics @pmunts, I guess you are probably using a faster Raspberry PI like Rpi5.

I am not familiar with the Build HAT, but a better option would be to ReadLine so that the read operation waits for the newline before returning which should be the case for (at least) the firmware string. On the contrary, delays can vary a lot depending on the board processor and bus and the serial port hardware.

If we are lucky and all the Build HAT commands are terminated with a newline, the change would work by just replacing the Read with ReadLine. You should be able to see this with the code you already used to sniff the traffic.

Should you be comfortable in doing more testing, I invite to do these tests and provide a Pull Request.
Are you willing to help with that?

With regards to the existing logging, the code is using the interface ILogger which is a standard and very convenient way to abstract any logging, also used in ASP.NET Core. You can find more details for Console applications here: https://learn.microsoft.com/en-us/dotnet/core/extensions/logging?tabs=command-line

Thanks again.

[krwq]

[Triage] @Ellerbach is probably your best bet here but he's out of office for longer period of time so he likely won't be able to look at this until sometime in September. @pmunts do you think you can contribute back? We could review earlier than this - we believe better solution would be using ReadLine/waiting for newline character - delay might not work on some slower OSes or when we port this code to nano-Framework