Octo not showing up on booting

[flatmax]

OK - I would like to trace down what is skewing the system on boot for these situations ... even though they don't seem to happen often.

It is possible that this is a supply issue where something in your system is not letting the power settle as quickly as it normally would ... that is one possibility.

Matt

[MedicationTime]

Code: Select all

sudo modprobe -r snd_soc_audioinjector_octo_soundcard
sudo modprobe -r snd_soc_cs42xx8_i2c
sudo modprobe -r snd_soc_cs42xx8
sudo modprobe snd_soc_cs42xx8
sudo modprobe snd_soc_cs42xx8_i2c
sudo modprobe snd_soc_audioinjector_octo_soundcard

Those lines worked for me. I did one reboot after that and the octo was normally recognized. I will try more reboots on the next days.

It seems like there is a timing issue for the octo kernel modules insertion and that it gets in conflict with other modules.

I don't have anything else attached to my rpi except for the regular mouse/keyboard/screen.

I'm using Noobs. Does anyone has the same issue with regular Raspbian ? If not I'll try it on Raspbian in the next days and report about it.

[kmolson50]

For what it is worth, this also is happening in headless mode (no hdmi, keyboard, or mouse plugged in. Boot into command line, ssh in)

Thanks for taking a look! Let me know if there is anything I can do.

[MedicationTime]

I just tested using Raspbian and not Noobs, it doesn't change anything.
When doing the sed command it writes "REMOVEvolumealsabt" and not "REMOVEvolumealsa" but changing that doesn't change the result.
The list of sudo modprobe commands do work and seems to fix the problem permanently : the card doesn't disappear after several reboots.

[MedicationTime]

Ok sorry, the card does disappear from time to time from aplay -L list.

Still the sudo modprobe commands fix the issue.

[jeffbl]

We are having this exact problem as well - the octohat is not recognized maybe 30% of the time on boot. The series of commands does work if it is not recognized. We're trying to make an boot-and-autorun system for an installation, so it would be great if this worked reliably.

Update: To fix it, I have a script that after a 5s delay runs the above commands to make sure the octohat is loaded. This gets run in the background by /etc/rc.local. So far so good, it comes up ok every time for 6 reboots. Of course, it would be better if it just came up every time without this hack.

[Maritut]

there is no text at all on the Now Playing screen in the remote.
I can see the album art, but even when I press it I dont see the song or album name.
I see the track timeline, but there is no indication of the exact length.

Im not sure how long this has been happening, but I think its fairly recently.

Anyone else experiencing this?

Thanks

[bhatloid]

Hi,

I just got the Octo, and followed Manual Setup instructions from here: https://github.com/Audio-Injector/Octo.

On the very first reboot, the Pi Zero W recognized the Octo. I then rebooted and connected an FM receiver to the I2C bus, and the Octo was nowhere to be found (by arecord -l). I fiddled with things for a while (unplugged wires, reseated the Octo on the Pi, etc), and after rebooting a few more times, I was able to see the Octo card again and record some audio. However, when I rebooted again, the card was not recognized again. Several more reboots and I am still unable to see the card.

In dmesg, I get the following (as previously reported by others):
[ 10.922167] audioinjector-octo soc ASoC: CODEC DAI cs42448 not registered - will retry
[ 10.922202] audioinjector-octo soc snd_soc_register_card failed (-517)
[ 12.473294] audioinjector-octo soc ASoC: CODEC DAI cs42448 not registered - will retry
[ 12.473366] audioinjector-octo soc snd_soc_register_card failed (-517)
[ 14.000923] uart-pl011 20201000.serial: no DMA platform data
[ 16.996992] Adding 102396k swap on /var/swap. Priority:-2 extents:1 across:102396k SSFS
[ 18.178928] cs42xx8 1-0048: failed to get device ID, ret = -121
[ 18.195744] cs42xx8: probe of 1-0048 failed with error -121

However, unlike others on this post, running the modprobe series described above does not make the Octo visible

Any ideas? I am sort of stuck here, at the wimsy of the bootup gods... So far I seem to get the Octo loaded 2 out of 10 times or more

[bhatloid]

So I think I figured this out. Due to bad luck, I was using BCM #5 to do something with another chip. Connecting BCM 5 to my chip with a wire without doing anything else causes the Octo to not be recognized at all by the RPi. My solution was to simply switch my GPIO from BCM 5 to BCM 4, and now the Octo is recognized while my chip is connected. Oddly, the failure to recognize the Octo persisted after disconnecting BCM 5 on reboot, but not on shutdown and power up of the RPi. Also, connecting BCM 5 after boot to my chip did not disconnect the Octo, suggesting that BCM 5 might be used during the initialization proces of Octo, but not later. So it took a while to track down.

Flatmax, can you explain why this is happening? Importantly, are there other pins that one should not use while the Octo is connected, in addition to BCM 5?

[flatmax]

I still have the feeling that these boot issues are to do with timings. My suspicion is that it is something to do with DC decoupling caps requiring a large charge time, or something similar.

The chip is reset in this bit of code :
https://github.com/raspberrypi/linux/bl ... #L274-L287

It is possible that altering the routine and timing may improve things. For some reason I decided to reset the chip twice ... which in retrospect shouldn't be necessary. One thing to try for this reason is to replace those lines with :

Code: Select all

		codec_rst_gpio = devm_gpiod_get_optional(&pdev->dev, "reset",
								GPIOD_OUT_LOW);
		if (IS_ERR(codec_rst_gpio))
			return PTR_ERR(codec_rst_gpio);
		msleep(500);
		if (codec_rst_gpio)
			gpiod_set_value(codec_rst_gpio, 1);