i don’t know why teh video locks up at 0.47, but up to that point, it’s flashing (cylon) pattern…
the biggest problem, the flashing procedure maxes out the current draw off the processor, there is a good chance with usb power, the flashing will fail… It’s recommended to use the 5VDC power jack…
As long as the cylon pattern stops and the board shut’s down it worked correctly…
Regards,
It’s not the video that’s locking up, that’s the BBBlack locking up at 0:47. The video continues for another 45 seconds to show that the BBBlack didn’t continue for some time.
I ran the flash again with a barrel plug and I get the same result. Locks up with an LED (3) on. Could it just be I have the wrong file I’m trying to flash?
I have a logic pirate, though I’ve never used it, as well as an Arduino. I’m going to setup up one of them to use the J1 connector, pins 4 and 5 from the looks of it, and see what I can see. No idea if that will be useful or not.
Okay, i didn’t even see the camera move, so yeah…
Sadly, led (3) doesn’t mean anything, as the cylon task just cycles on it’s own:
Yeah, a 3v3 Arduino would work just fine to convert the rs232 on j1 to a usb…
Regards,
That board you found may have a smaller EMCC device. I have found that the newer images no longer fit on my old BBB boards. Same issue as you mentioned, it flashes the cylon pattern for a while and then fails by hanging. I now run these boards directly from the SD card with the added benefit of much more storage to work with.
Thank you petski, that seems to make sense and aligns with what I am seeing. Odd that would happen, but who knows. I’d like to look into the eMMC capacity that I have and truly determine if this is the case. I’ll just flash an older image that fits if I need to. At this point I’m not too worried about latest and greatest, I just want to be able to play with it.
On a side note, I was getting an HDMI signal this weekend and the Linux duck with a blinking cursor appears in the upper left corner of my monitor. However, when the board locks up so does the cursor and it’s back to nothing.
Thank you petski, you were correct. Booting from SD is working just fine. I have “bone-debian-10.3-iot-armhf-2020-04-06-4gb” running right now. I don’t seem to be able to flash my eMMC without locking everything up. I would like to have a desktop so that’s my next adventure.
Hi there, you can try my instruction below to flash eMMC for your BBBlack:
Step1: Download minimal version of BBBlack eMMC Flasher image (because it is lightweight and has the basic OS for booting up BBBlack)
-Reference link:
-I recommend download this file: am335x-eMMC-flasher-debian-11.7-minimal-armhf-2023-09-02-2gb.img.xz 10
-You may need to verify the checksum of your downloaded image vs source to avoid any issue could happen later
Step 2: Download “balenaEtcher” software (select the right version for your PC), it is recommended tool to flash image to microSD card
-Please use microSD card storage <= 32GB since there’s an issue with larger storage (happened to me) cause failed to flash image to Beagle Bone
Step 3: Run balenaEtcher as administrator, select the image downloaded from Step 1, select your microSD card, click “Flash” and wait till Flash completed
Step 4: Disconnect BBBlack power, insert microSD card to BBBlack, connect BBBlack power, wait until Flashing process completed
-During Flashing process, BBBlack’s User LEDs should blinking in order for example: 1-2-3-4, 4-3-2-1 until the flash process finished. When flash process completed, BBBlack will power off (if you connect BBBlack’s UART debug to PC, you will see all the messages of the flash process)
Step 5: Disconnect BBBlack power, remove microSD card, connect BBBlack power again
At this point, your BBBlack should work normally
If there are any failures, you should connect UART debug of BBBlack to PC to monitor what’s happening
In step 4, I still need to press and hold the boot button on power up, correct?
Hello @bmwbykrydr2 ,
Not specifically, i.e. depending on your kernel and image. Most or all of the newer kernels and images are for SD Card use. I know there is a minimal image available also that might just fit on the eMMC.
If you grabbed an updated image Debian 12 Bookworm from a recent post on this forum, you should not need to push the S2 button near the SD Card carriage when booting.
If you are using the Bullseye image, I still think you do not need to push the S2 button near the SD Card carriage when booting.
What specific image are you grabbing from this forum, i.e. link and/or location?
Seth
P.S. Once the board is booted via SD Card, it should work like you stated earlier in this post. The main issue is that the eMMC onboard the BBB and other am335x styled boards is that the are 2GB to 4GB of space. This is really not nearly enough room for packages and updates/upgrades and installs.
Update
sudo apt install beagle-flasher will allow you to smash the contents of the SD Card to eMMC onboard.
If that does not work, you can go into uEnv.txt under the /boot/ file and change things manually. Also, I found this to handle flashing. It is called bb-config: BB-Config Detail — BeagleBoard Documentation
Yes, that is correct. Both of the RCN images work fine. All I did was burn the SD, insert, power on and its up. The emmc flasher image does take a while to install.
Still bugs me that I can’t flash an image onto eMMC on this device. Even flashing a small 2gb image fails.
I’ve got my Arduino serial monitor setup and I’ve tried several different start up’s. Most of this means little to me, but I can stumble my way through some of it. I’m hoping the Wise One’s can see more meaning in these files. Not sure why I’m getting the junk characters. I couldn’t get anything to change as I tried different serial settings. All of these images were flashed with balenaEtcher onto an 8GB SSD Card. Powered with the 5V barrel plug. I’m able to get to a command prompt and log in with the 10.3-iot-armhf-2020-04-06 image.
Stock boot up:
Stock_Startup.log (90.3 KB)
bone-debian-10.3-iot-armhf-2020-04-06-4gb startup with the Button pressed on boot:
bone-debian-10.3-iot-armhf-2020-04-06-4gb Button_On_Boot.txt (4.2 KB)
bone-debian-10.3-iot-armhf-2020-04-06-4gb startup WITHOUT the Button pressed on boot:
bone-debian-10.3-iot-armhf-2020-04-06-4gb No_Button_On_Boot.txt (5.7 KB)
am335x-eMMC-flasher-debian-11.7-minimal-armhf-2023-09-02-2gb startup with the Button pressed on boot:
am335x-eMMC-flasher-debian-11.7-minimal-armhf-2023-09-02-2gb Button_On_Boot.txt (46.0 KB)
am335x-eMMC-flasher-debian-11.7-minimal-armhf-2023-09-02-2gb startup WITHOUT the Button pressed on boot:
am335x-eMMC-flasher-debian-11.7-minimal-armhf-2023-09-02-2gb No_Button_On_Boot.txt (41.8 KB)
ok that is some serious corruption.
What serial interface are you using ?
I would check that the cables connecting to the board are not broken, at least the TX from the BeagleBone and the GND connection.
I think a broken or bad ground may be the cause.
Going to be hard to see what is going on when the output is so corrupted.
Well it is a 4GB eMMC…
[ 5.103168] mmcblk1: mmc1:0001 W62704 3.56 GiB
[ 5.114090] mmcblk1boot0: mmc1:0001 W62704 partition 1 2.00 LiB
[ 5.126048] mmcblk1boot1: mmc1:0001 W62704 partition 2 2.00 MiB
and looking at the eMMC u-boot…
U-Boot SPL 2017.09-00002-g0f3f1c7907 (Oct 09 2007 - 15:30:22)
Trying to boot from MMC2
U-Boot 2017.09-00002-g0f3f1c7907 (Oct 09 2017 - 15:30:22 -0500), Build: jenkhns-githbooeur0
Oh my! 2017 build… just erase the eMMC…
I’m using an Arduino clone and a serial UART sketch to read the Tx pin on J1. Then PuTTY to capture the text and save to a TXT file.
I made a different ground wire, made sure it has a good connection, get the same results. I’m running the UART at 115200, fastest the Arduino library can run, maybe I need something faster?
I suggest to use FTDI module since this device is cheap and easy to find (the level signals of BBBlack J1 Serial are 3.3V).
Connect FTDI module to PC via USB, you will find your COM device under Windows Device Manager, serial speed 115200 is totally fine.
Connect BBBlack’s J1 Serial Headers PIN 1 (Ground), PIN 4 (Receive) and PIN 5 (Transmit) (Refer to User manual) to FTDI module’s uart pins.
Insert microSD card with the image installed (balenaEtcher is recommended) to BBBlack, hold boot button down (to boot from microSD card), plug in power supply for BBBlack and monitor putty for boot up message.
If it boot up successful with eMMC-Flasher-Image, flashing process should work right away (I recommend to use this method).
If it boot up successful with microSD-Image, you are able to flash that image directly to eMMC using Linux ‘dd’ command or simply run build-in script to make flash eMMC happen. Note that the eMMC is around 3.6GB usable, select suitable microSD image.
PS:
BBBlack boots to eMMC by default. You need to hold boot button to select boot from microSD before board power on. Sorry my bad!
You should refer to user manual since it mentioned very clearly.
Hope this helps!
I doubt the problem is a lack of speed. If it was just that you would be dropping the occasional character, not getting the random junk.
It might be down to the fact that neither the Beagle or the Arduino board can generate exactly 115200 baud rate. One being slightly slower, the other slightly faster, giving too great an error.
Best bet would be as @hieun has said, to get a proper USB->3V TTL adapter. You can usually get them pretty cheaply. Doesn’t have to be an actual FTDI cable (they tend to be expensive).
After another week of working to get an image flashed to the eMMC on this board, I contacted the OEM that installed this in their freeze cabinet. The field service guy I spoke with said that anytime they’ve not been able to flash the eMMC it’s just a bad board and they discard it for a new one.
I’m afraid I have to agree and have decided to discard this BBBI board. Unless there is a way to run an image with a desktop from the SD card, which I haven’t been able to do.
I’ve purchased some regular BBB’s on craigslist and eBay and should have them in hand in the next few days.
if you permanently short the sd card button, it should boot from sd card, regardless of what is in the emmc.
wiping the first meg of the emmc will also achieve the same result
Each of my attempts to erase the eMMC fail. It just won’t do it.
It currently boots from SD without the button as long as the card is present. One of the few things I’ve been able to get to work correctly.