I am developing MMC driver in Linux. My system now is able to boot stably via eMMC and sdcard. But during the booting, I saw some errors generated on console.
[ 0.889357] mmc0: tuning execution failed: -5
[ 0.903700] mmc0: error -5 whilst initialising SD card
with some debug logs,
[ 0.976730] [DEBUG] mmc_sd_init_card
[ 1.143724] [DEBUG] mmc_execute_tuning
[ 1.219758] [DEBUG] tmio_mmc_execute_tuning: Tuning procedure failed = -5
[ 1.253255] [DEBUG] mmc_sd_init_uhs_card: err=-5
The error seemed to come from sd card initialization (UHS).
Despite the error, I was still able to use sdcard and eMMC once system completed the booting.
I am a little ambiguous about the error "tuning execution". Who can explain it and propose the fixing ? Thanks!
For more details, I have searched in the SD Card specification
https://www.sdcard.org/downloads/pls/index.html
And figure out some patches can deal with my issue.
https://patchwork.kernel.org/patch/9963437/
https://patchwork.kernel.org/patch/9998159/
My board has:
+ sdhi0: used for sdcard 4-bit bus width
+ sdhi2: used for on-board 8bit eMMC
+ sd-uhs-sdr50: SD UHS SDR50 speed is supported
+ sd-uhs-sdr104: SD UHS SDR104 speed is supported
+ mmc-hs200-1_8v: eMMC HS200 mode(1.8V I/O) is supported
+ mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported
Related
I was trying to program my ESP32_CAM module, but every time I got this error:
Serial port COM4
Connecting.................................
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 30:c6:f7:51:82:d4
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00005fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x0016efff...
Compressed 18528 bytes to 12759...
A fatal error occurred: Packet content transfer stopped (received 8 bytes)
A fatal error occurred: Packet content transfer stopped (received 8 bytes)
Has anyone had a similar problem?
This link says it means there is something wrong with the esp file system rendering it "broken"... Not sure if there is a way to fix the issue though.
EDIT:
I found that if I disconnected some of my peripherals from esp32, the error went away. Perhaps too much power was being drawn.
The code is working. I can build it and to mention. it was working, i could upload it to my custom made ESP32 board. From all of a sudden it stopped working. Tried with different PCB boards also different cables.
I somehow resolved my problem so i can program it, but now i get a verification error after Programming Finished
Here is my complete log from terminal.
Processing esp32dev (platform: espressif32; board: esp32dev; framework: espidf)
-----------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html
PLATFORM: Espressif 32 (3.4.0) > Espressif ESP32 Dev Module
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:
- framework-espidf 3.40301.0 (4.3.1)
- tool-cmake 3.16.4
- tool-esptoolpy 1.30100.210531 (3.1.0)
- tool-mkspiffs 2.230.0 (2.30)
- tool-ninja 1.9.0
- tool-openocd-esp32 2.1000.20210721 (10.0)
- toolchain-esp32ulp 1.22851.191205 (2.28.51)
- toolchain-riscv32-esp 8.4.0+2021r1
- toolchain-xtensa-esp32 8.4.0+2021r1
- toolchain-xtensa-esp32s2 8.4.0+2021r1
Reading CMake configuration...
LDF: Library Dependency Finder ->
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 0 compatible libraries
Scanning dependencies...
No dependencies
Building in debug mode
Retrieving maximum program size .pio/build/esp32dev/firmware.elf
Checking size .pio/build/esp32dev/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [= ] 10.1% (used 32992 bytes from 327680 bytes)
Flash: [======== ] 75.7% (used 794197 bytes from 1048576 bytes)
Configuring upload protocol...
AVAILABLE: esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa
CURRENT: upload_protocol = esp-prog
Uploading .pio/build/esp32dev/firmware.bin
Open On-Chip Debugger v0.10.0-esp32-20210721 (2021-07-21-13:34)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 1
adapter speed: 20000 kHz
WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release.
adapter speed: 2000 kHz
** Programming Started **
** Programming Finished **
** Verify Started **
Error: **** Verification failure! ****
Error: target_hash cbc6a9...992065
Error: file_hash: 773d62...93803f
embedded:startup.tcl:449: Error: ** Verify Failed **
in procedure 'program_esp'
in procedure 'program_error' called at file "/Users/USER/.platformio/packages/tool-openocd-esp32/share/openocd/scripts/target/esp_common.cfg", line 135
at file "embedded:startup.tcl", line 449
*** [upload] Error 1
Attempting to build a yocto image using the "thud" release, bitbake fails on building the version of u-boot that comes with the meta-gumstix thud branch, which is 2016.03 (which seems antique?).
The error I'm seeing is regarding conflicting types, e.g.
ERROR: u-boot-v2016.03+gitAUTOINC+df61a74e68-r0 do_compile: oe_runmake failed
…
/home/kwisatz/yocto-new/build/tmp/work/overo-poky-linux-gnueabi/u-boot/v2016.03+gitAUTOINC+df61a74e68-r0/recipe-sysroot-native/usr/include/libfdt_env.h:71:30: error: conflicting types for 'fdt64_t'
typedef uint64_t FDT_BITWISE fdt64_t;
Searching the Internet for that, one quickly comes across a range of threads explaining that the problem is the libfdt-dev.h header that comes with the dtc package. Some recommend to blacklist or uninstall the dtc package, but from what I see, it's explicitly required by the u-boot recipe in the gumstix layer for yocto:
DEPENDS += "dtc-native"
See also https://patchwork.openembedded.org/patch/147816/
However, in the thread linked to above, we're talking versions 2018.01 and 2018.03, not 2016.03
The poky layer for thud brings u-boot 2018.07 which builds fine, but with that one, my overo (Airstorm-Y) won't boot anymore:
Booting from nand with DTS...
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: attached mtd1 (name "mtd=4", size 1013 MiB) to ubi0
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
UBI: VID header offset: 512 (aligned 512), data offset: 2048
UBI: good PEBs: 8108, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1485359018
UBI: available PEBs: 0, total reserved PEBs: 8108, PEBs reserved for bad PEB handling: 160
** File not found /boot/omap3-overo-storm-tobi.dtb **
Loading file '/boot/zImage' to addr 0x82000000 with size 5097744 (0x004dc910)...
Done
Kernel image # 0x82000000 [ 0x000000 - 0x4dc910 ]
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
I'm not entirely sure if this boot problem is related to the u-boot build or to the kernel image that I've built (see my previous thread)?
Any tips on how I could solve this issue? Is there a more recent version of u-boot in a gumstix layer for yocto that I haven't discovered just yet, or do you have any other tips on how I could get a working yocto image for my overo?
P.S. Note that during the build, I'm also seeing these warning, but I don't think there's an actual problem here:
WARNING: u-boot-v2016.03+gitAUTOINC+df61a74e68-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch 0006-duovero-Read-eeprom-over-i2c.patch
patching file board/gumstix/duovero/duovero.c
patching file include/configs/duovero.h
Hunk #2 succeeded at 50 with fuzz 2 (offset -4 lines).
Now at patch 0006-duovero-Read-eeprom-over-i2c.patch
[…]
If you're looking for a new (development, not stable) image for the Overo I would recommend the Warrior branch
https://github.com/gumstix/yocto-manifest/tree/warrior
It has been tested and confirmed working for the Overo. The Thud branch was added to our repo to add support for the Raspberry Pi CM3+. For an older (stable) image, I would recommend Morty
https://github.com/gumstix/yocto-manifest/tree/morty
Thanks.
At least for me, with the same issue, i just removed
DEPENDS += "dtc-native"
and build completed.
tl;dr: flashed firmware to 0x00000000 instead of 0x08000000, am I lost?
Hello,
my device is based on a STM32F103CBTx which came with a proprietary firmware and had readout protection on.
I connect to it with a ST-Link v2 SWDIO and SWCLK connected to PA13 and PA14 and this command:
sudo openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f1x.cfg
I don't remember how I removed flash protection, but it worked as the original firmware didn't work anymore. Then I created a simple hello world firmware which pulls up and down three gpios and flashed it. The gpios are pulled up and down in 700ms intervals.
After flashing, I can't connect with openocd anymore. I forgot to specify the offset, the manual says the offset defaults to 0 and as it worked, I suppose instead of the boot loader my shitty hello world is pulling up and down some random pins happily… Is this possible? All other threads I found say the boot loader is write protected.
This is the last contact I had:
> halt
halt
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc
> flash write_image erase fw.hex
flash write_image erase fw.hex
auto erase enabled
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000003a msp: 0xffffffdc
wrote 4096 bytes from file fw.hex in 0.285697s (14.001 KiB/s)
> reset
reset
jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Any directions highly appreciated.
Edit:
What I get now, also tried another st-link:
% sudo openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f1x.cfg
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.244356
Error: init mode failed (unable to connect to the target)
in procedure 'init'
in procedure 'ocd_bouncer'
flashed firmware to 0x00000000 instead of 0x08000000, am I lost?
No, it doesn't matter at all, they are the same.
After reset, the MCU loads the word at address 0 in SP, and the next one at address 4 in PC. The BOOT0 and BOOT1 pins control which memory gets mapped to 0x00000000. Usually, BOOT0 is tied low, and flash memory at 0x08000000 gets mirrored at 0x00000000.
instead of the boot loader my shitty hello world is pulling up and down some random pins happily… Is this possible? All other threads I found say the boot loader is write protected.
The factory bootloader is indeed write protected, openocd can't overwrite it.
However, your application could have reconfigured the SWD pins, by writing a wrong value in GPIOA->CRH or AFIO->MAPR, thereby preventing openocd from working. It's the most common cause of this problem.
Fortunately, there is a way to recover.
Connect under Reset
If the reset pin of the controller is held low for a while when openocd is started, the application is prevented from starting, and messing up the GPIO configuration.
Openocd can do this automatically, when
It's told to do so, the line reset_config srst_only srst_nogate is present somewhere in the configuration script.
The MCU reset pin is connected to the debugger hardware, pin 15 on an official ST-Link/V2.
Or you can do it manually, by whatever means your board provides. If you are lucky, it has a reset button, if not, you must find a way to somehow ground the MCU reset pin.
Pull the reset pin low
Start openocd
Wait until the Info : Target voltage line appears. Maybe a second longer.
Release the reset pin.
It requires a bit of trial and error, you'll get better with practice.
Then you can flash your improved application, which carefully avoids reconfiguring the SWD pins.
I am trying to setup a eclipse development environment to work with stm32f303 nucleo 32 board.
http://www.st.com/en/evaluation-tools/nucleo-f303k8.html
So far, the all the tools seems to be correctly installed and working: I have succefully compiled and started openocd debugger for stm32f4 discovery and when I connect stm32f303 nucleo 32 board and start openocd, the led on the board indicates that it is connected. (I have flashed the board.)
The thing is openocd get lost when I do step by step debugging and this seems related to the message openocd gives me when started (look for bold line):
Open On-Chip Debugger 0.9.0 (2015-05-19-12:09)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
**Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED**
Info : STLINK v2 JTAG v27 API v2 SWIM v15 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.239293
Info : stm32f3x.cpu: hardware has 6 breakpoints, 4 watchpoints
Does someone know how to fix usb driver in that case, or it is possible that something else cause the problem?
In case you experience this issue on Linux, you have to configure udev rules to work with the device. Find the 99-openocd.rules included with the source distribution of openOCD under Contributions. Connect your ST-Link USB-device and run 'lsusb' from a terminal, it will list something like this:
Bus 004 Device 009: ID 0483:3748 STMicroelectronics ST-LINK/V2
Notice the value behind ID, you want to check the 99-openocd.rules to see if there is a matching entry supporting the device, in the above case it's this one:
# STLink v2
ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", MODE="664", GROUP="plugdev"
Copy this file to your /etc/udev/rules.d configuration directory and reboot your machine. Then try debugging again.
The OpenOCD distribution includes some libusb drivers, and recommends to run the zadig.exe tool to activate them. This will solve your problem.
http://zadig.akeo.ie/
As #silverdr mentioned in the comments, disconnecting the device and reconnecting it worked for me.