firmware, hardware, core versions

[hagikent]

@glopesdev @artursilva0 @filcarv

Hi Neurogear/OEPS team,
We AIND behavior team received several different versions of soundcards - 1.1, 2.1, 2.2, and wondering if which Firmware version we should use. We need to make them identically work in our dynamic-foraging task. (https://github.com/AllenNeuralDynamics/dynamic-foraging-task)

Earlier, we (@XX-Yin ) seems to have received only the one for v2.2 (SoundCard-fw2.2-harp1.13-hw2.2-ass0.hex), and thus, not sure what firmware we should use for others (v1.1, 2.1).

We have tested SoundCard-fw2.0-harp1.4-hw1.0-ass1 and SoundCard-fw2.0-harp1.4-hw1.1-ass0.hex which come with CSVconverter software, but this software seems to be buggy. We encountered that this operation changes hardware version as well, which I assume a fixed parameter.

To summarize:

1. which firmware to be used? Simply the latest for each hw version? Where can we find them?
2. what is core version? is this independent of hardware version? Do we need to care 1.4 vs 1.13?
3. why hardware version not fixed?

Tagging some relevant colleagues here:
@jsiegle @ZhixiaoSu @HeRodrgues @bruno-f-cruz

Thanks,
Kenta

[hagikent]

@bruno-f-cruz suggested testing the latest ones in release first.
Are those released on Dec 6, 2023 the latest and what we are supposed to use?

Given the detected hw versions in bonsai or cmd window cannot be trusted, we just need to trust the physical print on the board? (or is there a function like "factory reset"?)

[filcarv]

Hi,

Please use the attached firmware for the devices.
They are compiled for the different hardware versions but will always return as hw 2.2 on Bonsai or cmd window. This is a known bug that is already fixed in a new release that we are targeting for still this month.

This release will be a major one and will fix known issues and add funtionalities.

Replying to your questions:

1. Use the one attached.
2. The core version is independent of the hardware used. Is the versioning of the code that deals with communication, infrastructure, and protocol. The version 1.13 is the latest one.
3. It's a known bug to be fixed in the next release.

Cheers,
Filipe
harp sound card firmware.zip

[hagikent]

Thanks @filcarv . We will try them for now.

already fixed in a new release that we are targeting for still this month

Great. Will it be appearing in "release"? Once public, tagging this thread would be great (and then can be closed).

[hagikent]

Hi @filcarv ,

We have tested the firmwares received. In a nutshell, some success, some errors.
Hope you could address the following two:

1.Most of the hw=v2.2 board worked with fw2.2/core1.13/hw2.2 but when I was trouble-shooting it with @yonibrowning, we encountered a hw=v2.2 board that did not work with fw2.2/core1.13/hw2.2 but worked with fw2.0/core1.4/hw1.1 and fw2.0/core1.4/hw2.2. We have no clue what went wrong. The error we saw was the following when trying to play an uploaded sound.

2.How exactly are we supposed to bootload PIC32 firmware? As the soundcard (not the main micro-controller that has a corresponding COM port) is recognised as an USB device not a COM device, it's impossible to use the CSVconverter for targeted uploading...?

Thanks.

[filcarv]

Hi @hagikent

Replying 2 for now.
The CSVconverter should ask for the second firmware file (SoundCard.PIC32-fw) once you start uploading the SoundCard-fw

[hagikent]

Hi @filcarv

Thanks. That's what we have been doing, good to confirm.
Meanwhile, we sort of figured out that this is most likely compatibility issue with labview-based softwares.

Last Oct, Helio and I contacted you claiming that SoundcardGUI basically doesn't work in our new experimental PCs with tons of .vi error messages. This has not been solved but I switched to using Bonsai to upload sound waveforms, practically, circumvented.

I found that firmware updating doesn't works in those PCs that cannot run SoundcardGUI too.
What happened was, when uploading two firmwares (microcontroller and 32bit one), the 1st one worked but uploading 32bit fw crashed in the middle. The following window pops up and labview-based uploader(?) won't start. This keeps happening when Bruno was helping me trouble-shoot too; I believe I'm not doing something particularly wrong.

---

We are in touch with our IT to check if this labview incompatibility may be due to their security policy.
Do you have any alternative explanation/possibility?

Thanks,
Kenta

[hagikent]

Hi @filcarv

Our IT (@dorkfest1 @rachelmizuta) spent some time investigating this issue and concluded that Intel i9 CPU would be the cause.
Have you ever checked any hardware compatibility?

We AIND-behavior team have purchased >30PCs with i9 for behavior experiments and all of them cannot run those labview-based software.

---

a known bug that is already fixed in a new release that we are targeting for still this month

any update on this?

Best,
Kenta

[filcarv]

Hi @hagikent ,

That can be a good explanation for the issue. The software was compiled some years ago with an old LabVIEW version (v 2010, I believe) and it may not be compatible with recent processors.

Can you try to run it in Compatibility mode with a previous Windows version?

Can you also check if the next folders exist on your computer?

Best,
Filipe

[jsiegle]

Hi @filcarv – it doesn't seem like compatibility mode helped at all.

Would it be possible for you to compile the GUI with a more recent version of LabVIEW?

Alternatively, could a 32-bit firmware upload capabilities be added to the harp-cli tool? That would be the ideal solution in the long run.