LED Build Errors, Cube no longer turns on

[ryalberti]

Today I build ImageCapture on my computer with an updated tool chain and repo (develop). Making (make -r -j 4) the 32666 firmware generated no errors. When I build the 78000 video files, I received warning errors associated with defining the LEDs and some depreciated functions. Since these errors seemed mostly harmless and were part of the updated repo, I commented out line 114 "PROJ_CFLAGS+=-Werror" in the Makefile which treats all warnings as errors. I've seen this line commented out in previous releases of the repo and believed that since everything was updated, these errors were known and should not interfere with the program. I also received the same errors when building cats-dogs video. I repeated this process with the ImageCapture and cats-dogs audio files.

I sent the attached ImageCapture files to another user who I taught how to flash the firmware onto the cube. First we put the max32625pico_32630hsp.bin file onto the MAXDAP-TYPE-C which is advised here in the readme. This resulted in the correct GITSHA via link.

I watched him do this and we followed the tutorials and completed all of the steps correctly. First we flashed the video and audio and made sure to be in the correct debug settings. we had the MAXDAP facing the screen with the perpendicular Micro-USB port down as it shows here. We did this first and not the 32666 by following the instructions here. We received a mismatched checksum error but successfully flashed both. We then flipped the MAXDAP-TYPE-C so that it was facing away from the screen and the perpendicular Micro-USB port was up as it shows here. When we flashed this, the cube went black, had no flashing lights, and never turned back on.

We did a fresh install of develop repo on his computer and had him build cats-dogs which resulted in the same build errors. He flashed cats-dogs 32666 and did not receive the checksum error, though his screen did not turn back on and the cube seemed to be entirely unresponsive.

Attached is my build of the ImageCapture that I sent along with my msys outputs from the builds. Additionally, I have the 32666 and (un)edited video build outputs from cats-dogs as well. I am confused since there were no errors in the 32666 build so I am not sure why the cube would not turn back on and simply have "No video/audio comm". Additionally, when I updated the repo, no files were changed. These were the same files I had been successfully using in the past, though now built with an updated tool chain? I'm confused what could have changed. Will we be able to get the cube to turn back on with an older version of the tool chain and/or the repo?

Sorry for linking the directions everywhere, just wanted to cover the basics. Thanks in advance! refdes_issue_07.20.23.zip

[ryalberti]

Today we loaded on an old version of the cube that was build on an old version of the toolchain. The attached version was built on 08/12/22. We loaded on the 32666 first then video then audio. This was able to turn the cube back on and the demo worked correctly. As a result, I think the issue may have something to do with the toolchain and not the refdes code itself. Should I submit an issue to the SDK or the other refdes repo?

maxrefdes178-WildLife.zip

[rotx-eva]

Thanks for providing us with more details. From what I can see, you've included everything to reproduce the problem. I've added @Jake-Carter who is the best person to help with SDK issues. If you want to, you can create an SDK issue and link it here, but it shouldn't be needed.

[Jake-Carter]

Thanks @ryalberti, we recently fixed a related issue in https://github.com/Analog-Devices-MSDK/msdk/pull/664

Can you confirm that you're building these refdes projects against the latest main branch of the MSDK repo? (Instructions here)

[ryalberti]

Yes, I have followed these steps and have the symbolic links working correctly. I have both MaximSDK and msys at C:\ Just to clarify, this how my .bat is set up. Does this correctly satisfy the command line environment setup?

[Jake-Carter]

Yes, this looks correct if the repo is cloned to C:\msdk

As a sanity check you can cd into C:\msdk and run the following command:

git log | grep "#664"

If the line above is printed, you have confirmed that https://github.com/Analog-Devices-MSDK/msdk/pull/664 is in your git history

[ryalberti]

I do have #664 in my git history. Thank you, sanity check much appreciated!

[Jake-Carter]

Ok great, this confirms a separate issue. Thanks, we'll continue investigating and keep you posted

[Jake-Carter]

@ryalberti the issue also seems to have propagated to our pre-built lib files in the repo.

Trying running make distclean from one of your refdes projects. This should clean out the PeriphDrivers library files.

Then, rebuild your project and try again

[ryalberti]

I ran the distclean in the 32666 (as you cannot in the 78000s) and remade all three of the files (attached) and received similar results. We put in the 78000 but it was unable to read the binary and rejected it (Error below). We instead put on the 32666, which resulted in the lights flashing and the screen did not come on. When we unplugged and replugged the power, it did not turn on at all. We put the previously attached wildlife binaries on it again to fix the cube. maxrefdes178-ImageCapture(2).zip

[Jake-Carter]

Thanks @ryalberti, sorry for the trouble... This maintenance on this repo/source code has slipped somewhat recently. The MSDK team will be taking more direct ownership of it. In the meantime...

When we tried your binaries locally, we could flash successfully but the MAX32666 binaries failed with the same behavior (LEDs flashing, no screen). However, the MAX78000 binaries worked. So that was helpful to localize the issue further.

I checked the .map file for your maxrefdes178_max32666 build. The build was still using C:/MaximSDK instead of C:/msdk... This is my mistake. You asked here whether your modifications to msys.bat were correct, and I said yes. The instructions I wrote for the CLI setup are wrong. You should modify setenv.bat following the same edit setenv instructions as Eclipse. I will update the readme to fix this.

Ex:

Then, when you start up your MSYS shell you can confirm that MAXIM_PATH is set correctly:

make clean.periph should work from all projects, and have the same effect as make distclean. This will remove the pre-built peripheral driver binaries, and should fix the issue upon rebuild.

Here is my ImageCapture build output against the latest MSDK main branch (commit 15b1eff8ed6152ad8d4eeb3fc118cba6de719323) buildlog.txt

Note the source files being loaded from the expected "MAXIM_PATH" value.

Please try a rebuild after setting MAXIM_PATH in "setenv.bat". Apologies again for the confusion - this was my mistake.