My meaning of "beating a dead horse" is wasting time and energy on an task, that cannot be changed.
My objective was to load the operating systems into the QSPI & eMCC module and eliminate the need for an SD card. A procedure to accomplish the task is in the vendors quick start guide. If you follow the rabbit warren, even before you get to the end, you will discover it doesn't work.
After some research and lab work I figured I had exhausted my efforts and followed Red Pitaya's instructions to email tech support. I initially avoided this offering and invested in AI to see if I could expand my knowledge. I then used AI to correlate what I had discovered and help develop specific questions.
I included my questions and supports response. The response doesn't supply sufficient information for me to continue on the operating system objective, that horse is dead. Maybe the response can help others that are on the Red Pitaya RoadTest journey with me.
At this point I've decide to pivot and focus some effort on SDR and maybe reaching the objective I offered in my application.
Vendor Response:
Thank you for the thorough report.
We are looking to update the E3 I2C controller functionality with the next major update. We have not fully confirmed the new code, so it may have some bugs in the feedback reporting.
Even though the changes are not directly reflected in the tool, you should be able to change the watchdog functionality by typing in the following command:
e3_i2c_controller -w 0x01 0xFE
That will toggle the flag.
With the current mode, you can view the HW and SW revisions by checking the error feedback log. This is something we need to fix in the E3 module code.
Alternatively, you can get around this by using the old code and manually changing the "wdt_disable" flag to "true".
Regarding your other concerns, the documentation you were looking at is the correct source of info.
Please let me know if you have any questions.
My Email:
I am working on an E14 Community RoadTest Review community.element14.com/.../engineers-wanted-to-review-the-red-pitaya-stemlab-125-14-pro-gen-2-starter-kit for Red Pitaya STEMlab 125-14 PRO Gen 2 Starter Kit.
I am working with a STEMlab 125-14 PRO Gen 2 and the QSPI/eMMC module that was provided.
The module is labelled:
STEM_ADD-ON1_V1r0(Prototype1)
Serial: 978910260036
The module is operational and reports the following through the E3 I2C controller:
e3_i2c_controller -r
E3AD0102
This identifies the module as HW ID 0x01, currently in PWR_ON.
I am trying to use the documented eMMC flashing procedure. The difficulty is that the module watchdog resets the Red Pitaya after U-Boot is interrupted, preventing sufficient time to perform the required U-Boot work.
I investigated the official RedPitaya/RedPitaya-Examples repository and found the recent E3 firmware development in the dev branch:
github.com/.../E3_source_code
In particular:
- Commit 39a82ae — "Reworked the E3 board code to allow disabling watchdog"
- Commit ee2051f — "QSPI eMMC code updated - added HW and FW revision feedback and option to disable watchdog."
- The resulting firmware is identified as QSPI_eMMC_code_v1r1.ino, with a corresponding .elf.
- The v1.1 source defines HW_ID as 0x01.
- It also implements VERSION_REQ_CMD (0xFD) and TOGGLE_WATCHDOG (0xFE).
I tested the firmware-version request against my module. The command was accepted by the Linux E3 utility, but the module continued to return:
E3AD0102
rather than the v1.1 firmware-version response. This appears consistent with the module running firmware that predates the v1.1 command interface.
Before programming the STM32, could you please confirm the following:
1. Is QSPI_eMMC_code_v1r1 in the dev branch intended and safe for the HW-ID 0x01 STEM_ADD-ON1_V1r0(Prototype1) module supplied with the STEMlab 125-14 PRO Gen 2?
2. If so, is the supplied QSPI_eMMC_code_v1r1.ino.elf the recommended firmware image to program?
3. Is ST-Link/V2 through CN7/SWD the recommended programming method for upgrading this module to v1.1?
4. After upgrading to v1.1, is the intended procedure to use the new 0xFE I2C command to temporarily disable the watchdog before interrupting U-Boot for the eMMC flashing procedure?
I have not erased or programmed the STM32 and have not modified the QSPI/eMMC module firmware.
Documentation/resources
I have also found that some of the published QSPI/eMMC documentation appears to describe earlier firmware/software behavior, while newer functionality is present in the dev branch of the RedPitaya-Examples repository.
To make sure I am working from the correct information for the STEMlab 125-14 PRO Gen 2 and QSPI/eMMC module, could you also advise:
5. Is there a newer or development documentation set specifically applicable to the STEMlab 125-14 PRO Gen 2 and current QSPI/eMMC module?
6. Are there any release notes, application notes, GitHub branches, issues, examples, or other public technical resources for the E3/QSPI-eMMC module that are more current than the published documentation?
7. Is the dev branch of RedPitaya-Examples currently the appropriate source for the latest E3/QSPI-eMMC firmware and utilities, or is there another repository or branch that should be used?
8. Is there an updated version of e3_i2c_controller that implements the new v1.1 hardware/firmware version and watchdog-disable commands by name rather than requiring the raw command values?
9. Is there an updated end-to-end eMMC installation and boot procedure specifically for the STEMlab 125-14 PRO Gen 2 hardware?
The published eMMC flashing procedure instructs the user to execute:
ums 0 mmc 0
in U-Boot and then flash the eMMC from a PC as a USB mass-storage device.
10. On the STEMlab 125-14 PRO Gen 2, what physical USB connection should be used between the Red Pitaya and the PC for this U-Boot UMS operation?
The QSPI/eMMC module CN4 micro-USB connection appears to be documented for STM32 DFU programming, which I understand to be a separate function.
11. If the documented U-Boot UMS procedure does not apply to the Gen 2 hardware, what is the current supported method for initially imaging the eMMC?
If there are newer resources or procedures that supersede the currently published QSPI/eMMC documentation, links to those resources would be very helpful.
(This email has been written with the assistance of AI. AI is over coming my lack of programming knowledge. My objective was to follow the published documentation to make the Pitaya bootable from the supplied module. I have not been successful so far.)
Thank you.
