Raspberry Pi 1 nonfunctional

[probonopd]

Raspberry Pi 1 seems to be nonfunctional since at least 2022-04-05:
The last message is minidexed: Serial MIDI interface enabled, thereafter it seems frozen.

On 2022-02-28 it was definitely working:
#12 (comment)

Raspberry Pi Zero continues to work, also in the latest builds.
What gives?

[dcoredump]

Can you try to make a diff between both commits?

[probonopd]

Unfortunately I didn't keep all the old builds. So will have to rebuild and bisect all commits until we know which one caused this.

Maybe someone reading this has some free time and can do this somewhat tedious task?

[luisfcorreia]

I "might" give it a go, I'll try to get on of the old ones and try with a DAC I have, that doesn't use GPIO pins

(in the meantime, does anyone have the proper pinout for I2S in Raspberry Pi one?

[probonopd]

I "might" give it a go

That'd be super useful. You can use the headphone output with pwm for this purpose.

does anyone have the proper pinout for I2S in Raspberry Pi one?

We had started to brainstorm a pinout that works for all RPi models including 1 but never concluded the brainstorming:

#38 (comment)

So if you'd like to propose one, that would be cool. Now that more than just 3 people are building MiniDexed rigs we should come up with the default pinout sooner rather than later.

[luisfcorreia]

oh well, I2S connections are done outside standard GPIO, and only available for the SECOND rpi1 release

as seen here:

https://blog.sengotta.net/connecting-a-pcm5102a-breakout-board-to-a-raspberry-pi/

[probonopd]

Luckily almost no one has the first RPi 1 release.

[luisfcorreia]

I think I still have some, let me check :P

[luisfcorreia]

yup, have at least two of them (I'm a collector)

[probonopd]

Wow. You must have been a very early bird on the RPi train then 👍

[luisfcorreia]

yeah, I've met one of the developers (Rob Bishop) in a conference here in Portugal

[luisfcorreia]

back in 2012
(not my blog)
https://abertoatedemadrugada.com/2012/11/camara-para-o-raspberry-pi-aparece-pela.html

[luisfcorreia]

Getting back to debugging, I've just connected my Raspi 1 to an HDMI display
(using PWM as selected output, no LCD or Encoder, full debugging)

Doesn't make a sound but it's also NOT locked up

[probonopd]

Doesn't make a sound but it's also NOT locked up

How do you know?

[luisfcorreia]

with full debug, if you have a midi keyboard connected, pressing keys show them on screen
and it keeps scrolling without issue

[probonopd]

Interesting, it didn't seem to do that for me... are you sure you have configured pwm output on yours? (For the headphone jack). In case your HDMI screen has speakers, try that as well please.

[luisfcorreia]

PWM is selected, HDMI screen does not have speakers

[probonopd]

Looks like it is git bisect time then ;-)
My educated guess would be that d86a453 was still working.

[luisfcorreia]

yes, bisecting to that produces sound indeed (on PWM)

[probonopd]

To ease your pain, I am working on netbooting the MiniDexed firmware :-)
https://github.com/probonopd/CircleNetboot (not quite there yet...)

[luisfcorreia]

networking is neat for syslog debugging

but if you want me to bisect to another point, I'l test it
Will be around here for another hour or so

[probonopd]

"Bisect" means:

You use it by first telling it a "bad" commit that is known to contain the bug, and a "good" commit that is known to be before the bug was introduced. Then git bisect picks a commit between those two endpoints and asks you whether the selected commit is "good" or "bad".

https://git-scm.com/docs/git-bisect

[probonopd]

We now know that d86a453 was still good. My guess would be that f98f5db is bad. So the question is, which one in between was the first bad one.

[luisfcorreia]

To ease your pain, I am working on netbooting the MiniDexed firmware :-) https://github.com/probonopd/CircleNetboot (not quite there yet...)

that only works once, next boot is done using uploaded kernel file

[probonopd]

Correct. But you can replug power and then upload another one. Saves dealing with the SD card.

[luisfcorreia]

ok, gotcha

(now I'll need a reset button)

[luisfcorreia]

yeah, THANKS

this works so much better!!!

also this? a VERY nice touch!
tftp -m binary IP -c put kernel.img

[luisfcorreia]

I "know" I'm doing things wrong.
Yesterday I did the full bisect/compile/test run from the "known good" commit and current head but at the end, it continue to work all the way.

However, I think that bisecting to an earlyer build would require "submodule clean and recompile" and I might been doing this wrong

so, after an hour of tests, I didn't come to any conclusion

[probonopd]

Are you saying that d86a453 and f98f5db are both working for you?

[luisfcorreia]

no, not really

you see, sometimes when I "git bisect bad" and it goes to another commit, it gives out compile errors.

my solution for now is to "git submodule update --init --recursive" but even that fails sometime

so, unless I'm being VERY dumb, I don't get it why going back in time makes compiles to fail...

[probonopd]

You must make sure that the git submodules get up/downgraded to match what the respective version of MiniDexed needs.

https://github.com/HaxeFoundation/haxe/wiki/Finding-breaking-commits-with-git-bisect

[luisfcorreia]

help is apprece

git submodule update
fatal: remote error: upload-pack: not our ref 86dba9826c21295e72a8a38b17e1f2c001579310
fatal: Fetched in submodule path 'Synth_Dexed', but it did not contain 86dba9826c21295e72a8a38b17e1f2c001579310. Direct fetching of that commit failed.
fatal:

ated

[luisfcorreia]

restarting the process :)

[luisfcorreia]

well, you know what?

it now works with teh most recent commit, can you test with yours?

[luisfcorreia]

yup, it works in RPI1 (PWM) using TFTP booted kernel file
addbd45

[probonopd]

HDMI too?

[luisfcorreia]

maybe, let me test (it's a pain to setup)

[luisfcorreia]

yes, HDMI also produces sound

whatever it was, it was fixed...

did we have a Synth_Dexed update in the meantime?

[probonopd]

I am puzzled. Can it be that only our self-compiled ones work but the downloaded compiled ones don't?

[probonopd]

And does it make a difference wheher you load it via Ethernet or SD card?

[luisfcorreia]

dunno, will test that later

[probonopd]

Starting to consider that I might have fried 2 RPI 1s...

[diyelectromusic]

I am puzzled. Can it be that only our self-compiled ones work but the downloaded compiled ones don't?

I've not really followed the versions and thrust of this conversation in detail, so apologies if this is irrelevant, but it if is any help, release MiniDexed_2022-04-16 is working fine on my Raspberry Pi Model B V1 using built-in PWM, LCD 1602 display and a rotary encoder. I've had to move the encoder to GPIO pins 9-11 of course; I've moved LCD RS to GPIO 4 and am not using the LCD RW link (it is just set to GND)...

But from booting off SD card, I'm selecting voices, have working USB MIDI (I've not tried serial MIDI), and the encoder, display and sound all seem fine for me?

If it is useful and you want me to test a specific downloaded version/build just let me know and I can give it a go...

[probonopd]

Thanks for your help testing this.

Raspberry Pi Model B V2 using built-in PWM/HDMI, LCD 1602 display and a rotary encoder also working well. Cannot reproduce anymore. Perhaps I had a bad SD card? Tested using the build from Apr 23 2022.

[john-davies]

Can I ask what the conclusion was to this problem? I have a Pi 1 and the build from Apr 30, 2022, 20:52:10 that I downloaded exhibits the same problem as the first message in this issue:

The last message is minidexed: Serial MIDI interface enabled, thereafter it seems frozen.

I don't have an LCD or Encoder connected and I'm using PWM audio for a quick performance test on my Pi 1. I'm using an M-Audio Keystation Mini 32 and I have MIDIDumpEnabled=1 which I assume should show any MIDI messages on the HDMI display but I don't see any.

Is it worth me trying my own build rather than using the downloaded one?

[luisfcorreia]

Have you tried a recent build?

I helped testing this and did not come to any conclusion, all home built versions worked fine.

Then I tested a new build, about when MicroDexed was updated and apparently (to me at least) it seemed to be the root cause.

But I might be totally wrong and the problem may persist, haven't retested for a while

[john-davies]

The latest version from 9th May does the same thing.

Sorry if this is a stupid question but the "Building locally" page of the wiki refers only to the Pi 4. Is there an equivalent for the Pi 1? Alternatively is there a way of running the build.yml workflow on my local machine ( Googling indicates that there isn't )

[luisfcorreia]

I just "export RPI=1" and run "./build.sh" on my Linux desktop

[john-davies]

OK, thanks. I did the following, starting from a clean install:

git clone https://github.com/probonopd/MiniDexed.git
cd MiniDexed
git submodule update --init --recursive
wget https://developer.arm.com/-/media/Files/downloads/gnu-a/10.3-2021.07/binrel/gcc-arm-10.3-2021.07-x86_64-arm-none-eabi.tar.xz
tar xvf gcc-arm-*-*.tar.xz
export PATH=$(readlink -f ./gcc-*/bin/):$PATH
export RPI=1
./build.sh

I then copied src/kernel.img over the build downloaded from the Releases page but the result is the same as before. The Compile time: ... line was updated correctly so I'm reasonably sure that I'm running the new build.

[luisfcorreia]

yup, it does look like, you've compiled it correctly

I can't test it today, will try to do it tomorrow

[probonopd]

Just some ideas since when I had tested this the last time I came to the conclusion that it was not a software issue but I wasn't able to reproduce the issue anymore.

• Try a more powerful (at least 2A) power supply
• Try a different SD card