Flashing a coral dev board per the getting started guide results in the the error Wrong image format for "source" command. This error is what is displayed in the serial console when the SD card is inserted in the board and the board is powered up - full output below. I didn't find any documentation for this problem so I am posting it here in case anyone else has this issue.
U-Boot SPL 2019.04.1 (Apr 29 2020 - 18:40:05 +0000)
power_bd71837_init
Board id: 2
DDRINFO: start DRAM init
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
Normal Boot
Trying to boot from MMC2
hdr read sector 300, count=1
U-Boot 2019.04.1 (Apr 29 2020 - 18:40:05 +0000), Build: jenkins-enterprise.uboot-imx-1
CPU: Freescale i.MX8MQ rev2.0 1500 MHz (running at 1000 MHz)
CPU: Commercial temperature grade (0C to 95C) at 33C
Reset cause: POR
Model: Freescale i.MX8MQ Phanbell
DRAM: 1 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
BuildInfo:
- ATF
- U-Boot 2019.04.1
flash target is MMC:0
Net:
Error: ethernet#30be0000 address not set.
Error: ethernet#30be0000 address not set.
eth-1: ethernet#30be0000
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot: 0
** No partition table - mmc 1 **
## Executing script at 40480000
Wrong image format for "source" command
## Starting auxiliary core at 0x00000000 ...
u-boot=>
This error results from a bad SD card, or perhaps one that has already been used (formatted) for other uses. I was able to bypass this error and successfully install the OS by burning the image per the the getting started guide on a brand new SD card (I used a Samsung 128GB Pro Endurance card). I used balenaEtcher on a mac, which burns the image in just a few minutes.
For work I've had to provision dozens of these and they are super finicky about sd cards. I've bought 4 brand new completely identical (same brand, size, etc.) sd cards and burn them all identically. 1 will work on one board but not another, another will work in the 2nd but not the first, etc. So the only advice I have is "keep trying".
Thanks for the answers from Oliver and j2abro. I just dug the Coral Dev Board out of my project drawer and started trying to get it running.
First of all, make sure you read the directions and set the DIP switches properly (this dip, me, didn't do that, at first). I finally got it to work, but Oliver's answer seems to match my experience (Dev Board is finicky about SD Cards). Here's the cards used and result. All flashed with BalenaEtcher on a MacBook Pro (M1 2020, Monterrey 12.6):
SanDisk UltraPlus 256GB (multiple FAILS: didn't set DIPs correctly. derp!)
SanDisk UltraPlus 32GB #1 (FAILED with DIPs correctly set: same result as OP)
SanDisk UltraPlus 32GB #2 (FAILED with DIPs correctly set: same result as OP)
SanDisk UltraPlus 256GB (SUCCESS: set DIPs correctly) same card as #1
All these cards were brand new, right out of the retail packaging; nothing else was written to them before the Coral Dev Board image.
Theory: I tried the 32GB cards thinking that this board might have a problem with exFAT (above 32GB) storage formatting, similar to the Raspberry Pi boot limitation. However, given my and j2abro's success with larger SD Cards, I'd recommend trying a larger SD Card (more than 32GB) rather than the typical 32GB or less you'd use for a Pi. Seems like the Dev Board likes exFAT formatting better?
Tip: I strongly recommend connecting to the board using the Serial Console while setting up the board (link below), otherwise you'll be doing a lot of guessing as to what's going on with the setup and waste your time:
https://coral.ai/docs/dev-board/serial-console/
Here's what I saw (finally) in the Serial Console after the second reboot after a successful flash with the 256GB card:
...
[ 8.788556] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
Mendel GNU/Linux (eagle) lime-jet ttymxc0
lime-jet login:
Hope this helps you get to a successful setup.
Related
I have the problems with both SAVIHost v1.43 and VSTHost v1.57 for the case of Dexed 0.9.6. As I am a hobbist only, related to both MIDI and IT, I wish to ask some help to overcome these problems detailed below.
My problem with SAVIHost V1.43:
I copied savihost.exe (extracted from savihost3x64.zip) copied into directory "C:\Program Files\Common Files\VST3" (i.e. into the installation directory of Dexed.vst3) then renamed it to Dexed.exe, and launched this Dexed.exe.
I set "loopMIDI Port 1" (created prior by "loopMIDI v1.0.16 (27)") as "Input Port 1" via "Devices|MIDI..." and "1764 samples (25 b/s)" via "Devices|Wave...". (The sample rate was 44100 Hz, and both ports were "MME: Microsoft Sound Mapper).
Then I played some sounds by use of the virtual keyboard, and changed Dexed's programs (instruments) randomly - and Dexed seemed to work well, it played the different sounds with the actually selected instruments. Then I sent some MIDI Messages by Cakewalk by Bandlab to "loopMIDI 1"; Dexed produced the appropriate sounds, according to MIDI Note On/Off messages received - except that all the MIDI Program Change messages (C0 xx) were ignored.
Finally, when I clicked onto icon of Dexed.exe (i.e. renamed savihost.exe) in the Windows 10 Taskbar on the screen: the main window of Dexed.exe was minimized,
but when I clicked onto its icon again, although its main window is restored but crashed immediately. A dialog titled as "Dexed" appered,
containing an error message:
Unhandled exception 0xC0000005 at 00000014005BEBA
reading from FFFFFFFFFFFFFFFF
(followed by a list of the recent content of registers).
Furthermore, I noticed that resizing of window of Dexed.exe (moving its bottom edge upward) also causes a crash, but only after when Dexed.exe received some MIDI messages through "loopMIDI Port 1".
(i.e. playing on virtual keyboard, followed by similar resizing did not cause crashes - at least, I have not realized that.)
The situation was ditto for the case of SAVIHost V1.44 beta.
Problem with VSTHost V1.56 x64:
In the second case, I started VTSHost.exe, then loaded Dexed.vst3 via File|New Plugin... . Dexed.vst3 also seemed to work well at the beginning, i.e. while I played on the virtual keyboard bar, and changed the programs (instruments) and modified some parameters by the knobs on the screen. But when VSTHost received the first MIDI messages through the "loopMIDI Port 1", Dexed does not played any notes anymore. Instead, some extra message lines appeared in the dialog "Info" below the line "Chained as Insert before 1: Engine Output":
...
Processing is turned off (errors in PlugIn?)
ProcessReplacing
Exception 0xC0000005 at 000000014007ABF6 reading from 0000000000000000
...
Stack Trace:
...
Unfortunately, the situation was the same in case of VSTHost V1.57 beta x64.
Comments:
Dexed.vst3 worked without problems in case of other VST host apps (e.g. CakeWalk by BandLab and Cantabile 4 Lite), i.e. also the MIDI Program Change messages were executed properly.
(CakeWalk by Bandlab used Dexed.vst3 directly, Cantabile 4 Light received MIDI messages from CakeWalk by BandLab through "loopMIDI Port 1".)
similarly, the original standalone Dexed application also processed the MIDI Program Change messages through "loopMIDI Port 1" correctly.
version number of Dexed.vst3 reported as 1.0.0 by VSTHost (although is is originated from unzipping of "dexed-0.9.6-win.zip").
my PC has the followings:
-- OS: MS Windows 10, 22H2, build: 19045.2311 (x64)
-- CPU: Intel(R) Core(TM) i5-4460 CPU # 3.20GHz
-- RAM: 8 GB
-- motherboard: Gigabyte Technology Co., Ltd. B85M-D2V
-- sound: Realtek, High Definition Audio (on-board)
Finally, I wish to mention that I have tried other VSTs than Dexed's one with both SAVIHost and VSTHost: "sforzando.vst3" and "Roland Sound Canvas VA.dll".
There were no problem at all - no interception of any MIDI Message, no crash, etc -, they had been worked without any problem for hours. So I am not really sure, what and where are the root of the problems above: maybe in SAVIHost or VSTHost - or maybe in Dexed.
I wish ask some help, how I shall continue to determine, which component - ie. savihost/svthost or Dexed - is failed and resulted the problem?
Thank you very much for you kind efforts in advance!
Intro
I wanna give a last chance to this board before put it in a trash haha :). Right now I prefer use standard motherboards, Ubuntu server, automatic main power switch and perif. to have something reliable over the time though.
Raspberry Pi wanted configuration
-wanna use Rasbian 11.
-no boot from external hdrive.
-will mount external hdrive using the UUID for the data
My questions
1 - Enable overlay and readOnly mode (in raspi-config) doesn't seem good enough- With this method rootfs parition in fstab is not 'ro'. So what?
2 - Is it more reliable to have the both partiton in readOnly (boot and rootfs) ?
3 - What about the log, temp, ram,...? Is there anything else to think about? What would be the complete list with a bit of explanation?
Thank you!
I have try to edit fstab, and add 'ro' to the rootfs partition but doesn't keep after a reboot.
I'm just creating an app(kivy) for a raspberry pi(3b) with 7 inch touchdisplay. In addition I implemented a light sensor (TSL2591), which can regulate the brightness of the backlight using following command:
os.system('sudo sh -c "echo '+str(brightness)+' > /sys/class/backlight/rpi_backlight/brightness"')
with values of brightness 0 to 255
Works fine so far, but I do update the brightness once a second. If I'm not wrong, the command overwrites a config file and I mind of write access to the SD Card that often. I think the SD card will be corrupt after a short period of time.
For sure I can try to get less write operations, but it also leads to less smoothness:
update slower than 1 sec
only write if brightness value really changes
don't use all of the 255 steps
So the main question is: is there any other way to control the brightness? Or any workaround? I could not find a "real" Datasheet or any other advice on the internet. So maybe there is another way.
That's not a conventional disk file; it's a "device special file" which the kernel artificially creates to look like a disk file. It allows you to "talk" to device drivers using standard read() and write() calls.
You need not worry about SD card wear.
I'm trying to configure a RaspberryPi2 to record video data from the camera module to a rosbag. To get the camera working with ROS, I used code I found here: https://github.com/fpasteau/raspicam_node.
This works fine, but I have a problem capturing the data to a rosbag. When capturing in raw mode at a high frame rate, it captures smoothly for a few seconds, then freezes for a few seconds, then captures smoothly for a few seconds, then freezes, ...
For instance, I tried capturing a file with 640x480#30FPS and this is what rosbag info yields:
duration: 2:51s (171s)
size: 2.9 GB
messages: 5049
compression: none [2504/2504 chunks]
types: rosgraph_msgs/Log [acffd30cd6b6de30f120938c17c593fb]
sensor_msgs/CameraInfo [c9a58c1b0b154e0e6da7578cb991d214]
sensor_msgs/Image [060021388200f6f0f447d0fcd9c64743]
topics: /camera/camera_info 2505 msgs : sensor_msgs/CameraInfo
/camera/image 2504 msgs : sensor_msgs/Image
/rosout 22 msgs : rosgraph_msgs/Log (2 connections)
/rosout_agg 18 msgs : rosgraph_msgs/Log
So if we have 171 seconds of video, at 90FPS, that should give 15390 messages, we only got 2504, which is about 14FPS. The file itself is 2.9GB in size. This means it had an average writing speed of ~17.5MB/s. Eventually I found a command to test the write speed of the SD card (dd if=/dev/zero of=~/test.tmp bs=500K count=1024), which says my writing speed is about ~19MB/s on average.
So my questions are:
If the SD writing speed is causing the problem, how come the RaspberryPi can't utilise the full 90MB/s?
Can I tune the RaspberryPi to write quicker to the SD card?
I thought about getting a BananaPi, which comes with SATA, so I could connect a SATA drive and shouldn't run into any write speed issues. Before making that investment, does anyone have experience with BananaPis? I saw a test here: http://314256.blogspot.co.uk/2014/11/banana-pi-sata-disk-throughput-test.html, which looks like the BananaPi should be able to handle it.
Any other ideas how to make it work on the RaspberryPi?
It looks like the raspicam_node publishes images with bgra8 encoding (raspicam_raw_node.cpp#L266), so we need to store 4*640*480*30 Bytes/second = 36.86 MB/s.
However ~18 MB/s seems to be pretty much the limit on a Raspberry 2 (microSD card performance comparison).
Instead of trying to save all the raw data, have rosbag store the sensor_msgs/CompressedImage from the /camera/image/compressed topic. You can tune the <base_topic>/compressed/jpeg_quality parameter (see compressed_image_transport's dynamic reconfigure parameters), but with the default of 80 you should get around 30:1 compression ratio, i.e. 1.23 MB/s.
The Raspberry should be able to handle this easily. Given the image quality of the tiny Raspberry camera, you will probably not even perceive any difference in quality.
I'm very new to WebIOPi and I'm trying my first tests. First of all I apologize for my english.
I'm trying to get to work a RPi with a MCP3008 on CE0 and a MCP23S17 on CE1 with SPI bus.
My problem is that devices only work when connected on CE1 (so, when 23017 is on CE0 I am not able to set pins to be inputs or outputs and to set it on 1 or 0, but 3008 is on CE1 and I see its levels changing. When - vice versa - 23017 is on CE1 it is fully functional, but 3008 outputs stay still).
Due to this, I think it is not an hardware issue (I don't have much expertise in electronics, but luckily I don't build my circuits by myself :) ), I think it is a problem in WebIOPi config. Here is my WebIOPi config:
[DEVICES]
mcp1 = MCP23S17 chip:1 slave:0x27
adc0 = MCP3008 chip:0
I only added these two lines to my config file.
I did not touch anything else of my original WebIOPi installation.
In this case (adc0 fully functional, mcp1 not working), when loading the WebIOPi devices monitor I see adc0 levels working good and mcp1 pins randomly changing between being a input and an output and from 0 and 1.
May it be a config error?
Use python and spidev module instead! Look my answer on another thread for function for the mcp3008 chip.