eembc / energyrunner

The EEMBC EnergyRunner application framework for the MLPerf Tiny benchmark.
14 stars 5 forks source link

Energy Mode Hardware io-manager_1.0.3.hex #29

Open nolan4 opened 1 year ago

nolan4 commented 1 year ago

Hello, I'm stuck in the "Energy Mode Hardware" section where it says to flash the io-manager_1.0.3.hex image to the arduino UNO. What do we do with the command you provide? Is it possible to download the io-manager_1.0.3.hex file separately and flash it using Xloader?

I am getting this issue from the user console when I attempt to initialize the ML Energy 1.0.1 benchmark (see attached photo) screenshot1

petertorelli commented 1 year ago

Regarding your first question, it looks like you succeeded. The command C:\dev\arduino\1.6.6\hardware\tools\avr\bin\avrdude.exe -CC:\dev\arduino\1.6.6\hardware\tools\avr\etc\avrdude.conf -v -patmega328p -carduino -PCOM3 -b115200 -D -Uflash:w:io-manager_1.0.3.hex:i loads the image to the UNO using the Arduino dev kit software.

The second problem: Initialization is failing becasue the DUT is not turning on and saying "m-ready". If you look at the screenshot in the README.md file of this repo under the Selecting Energy Mode section you will see that normally, when initializing, the emon power on command waits for the DUT to say m-ready. In your case, the DUT is not responding. This isn't an EnergyRunner problem, this is an issue with the DUT communication. You need to verify that the DUT is communicating on the UART. How you do this depends on your build environment, hardware, and operating system.

nolan4 commented 1 year ago

Thanks for the fast reply! For the io manager, I went to this link (https://www.eembc.org/energyrunner/mlperftiny/) and used the IO Manager Firmware Binaries file called "ioman.hex" then flashed it using Xloader. The arduino command never worked for me.

For the second problem, I am working with the Silicon Labs xG24_DK2601B dev kit on Windows 11. I've built and flashed the "energy" version of the kws model to the device successfully. Do you happen to know how I would verify the DUT is communicating on the UART?

petertorelli commented 1 year ago

That's tricky, it requires debug based on your setup. For example, if you can route the UART to the SiLabs retargeted IO you can interact with PuTTY or any other serial app. If you cannot, then you need to probe the Tx/Rx lines of the UART with a logic analyzer.

Typical problems I see are wrong baud rate (enrgymode is 9600, perfmode is 115200), swapped tx/rx pins or incorrect level-shifter connectivity. You might want to verify that performance mode works first. That will prove the UART drivers are working, and then all you need to do is change the baud and connect the pins to the level shifters.

nolan4 commented 1 year ago

Ok, I've verified that the kws performance mode is working. I have the DUT plugged in and wired up correctly, but I keep the lpm01a and arduino uno unplugged. Here are my immediate next steps after verifying kws performance mode:

  1. switch EEMBC EnergyRunner drop down menu to energy mode
  2. plug in the lpm01a and arduino uno usb cables
  3. unplug the DUT usb cable so that only the lpm01a and arduino uno show up in the devices list on EEMBC EnergyRunner
  4. click initialize, then the system fails with the same error as before.

In addition, the system is very finicky in terms of when it will or won't recognize devices that are plugged in. As of right now I can't get it to recognize the silicon labs board anymore. How do you manually set the baud rate when switching to energy mode?

petertorelli commented 1 year ago

Regarding stability, (a) this is being fixed in a new release, and (b) a workaround is to plug everything in, then launch the application. That may help the detection issues.

Getting back to the problem at hand. Good, perf mode works. The fact that it doesn't initialize means it probably isn't hooked up correctly or properly compiled to energy mode.

Are the UART pins on the Silabs board going through level shifters that are properly connected, and then into the correct pins on the IO Manager?

Did you recompile to use 9600 baud, and set the EE_CFG_ENERGY_MODE option to 1? Setting baud rate is different for every board. Check with your IDE/configurator, or search through the code to find the UART initialization routines.

nolan4 commented 1 year ago

I am following this diagram for the connections and have attached a picture of my setup: https://github.com/mlcommons/tiny_results_v1.0/blob/main/closed/silicon_labs/systems/energy_hookup.md

To generate the .s37 firmware binaries that are flashed to the SL board, I ran "build_firmware.sh" which generates them for both energy and performance automatically (described here under the "Generation" section: https://github.com/mlcommons/tiny_results_v1.0/tree/main/closed/silicon_labs).

Just to make sure, I regenerated the firmware binaries for energy mode and specified a baud rate of 9600. Below is a pic of the error I get from EnergyRunner:

image

7a63268b-80dc-42f0-8f1d-b398bf5a1aab

(I see the resolution is not that good, but I have re-done and triple checked my connections)

petertorelli commented 1 year ago

Unfortunately there's not much I can offer for advice here. This is straight-up embedded debug. The DUT response after powering on is not making it back to the system. This is where a Salae logic analyzer comes in handy. The only other thing I can suggest is: are you sure the retargeted stdio functions are going to the correct UART? On some boards the UART that is set as a virtual com port by the debugger interface is a different peripheral (or different pins) than the one that is exposed to the board. That's all I got.

nolan4 commented 1 year ago

No worries, thanks for all of your help thus far. One last question, should the light on the silicon labs board turn on when it is receiving power from the LPM01A (like it is in the above pic when powered by micro usb)? Unfortunately, debugging embedded systems is not my area of expertise. I was hoping it would simply work as described in the README.

petertorelli commented 1 year ago

I just noticed there's a USB cable plugged into the SiLabs board. That shouldn't be there, it means power is being supplied to the board by the cable. That's a problem. The idea is to supply power via the EMON and the EMON only. Typically there is a voltage regulator that converts 5V USB to whatever the core voltage is, and most boards provide a jumper so that you can disconnect the regulator from the MCU and supply energy from the EMON. Time to break out the schematics and learn how the board is powered! I also recommend attending the MLPerf Tiny working group, there are more people there who do this regularly that can help. Tagging @jeremy-syn and @cskiraly who run the group and might be able to help more.

nolan4 commented 1 year ago

Yes, I only plug it in for performance mode and unplug it before switching to energy mode. When the DUT is isolated and only powered by the EMON, the blue indicator light does not turn on. That is what I was trying to ask - should it be on when powered by the EMON? I will look into the jumper/regulator.