DIY: norns shield

@tehn Do you have a link handy on getting to the dmesg log? If I setup wifi on the Pi alone and then connect the shield should I be able to ssh in at that point? Sorry for the likely basic questions, searching around for info about the dmesg log was only turning things up where the shield has already been connected to wifi.

@toneburst yes, positive I’m using the right image. I had seen some previous discussion on that and tried using an older image just to see what would happen and it wouldn’t even give me the jack fail message. I’ve re-imaged and re-downloaded, too. Used “pre-211028 shield raspberry / pi 4 / norns220306-shield-pi4-cs4270.tgz”

@alexam do you have a suggested temp for the reflow station? I based my 240°C on the reflow profile from the oscillator crystal datasheet which has a 10s max at 260°C and 30-40s at 230°C. Tried to play it safe and run just a little cooler so I had a little more time but maybe this is a case of higher temp and faster work? Might just have to pick up that iron tip and have a go with the hand iron, thanks for that suggestion.

@frankchannel assuming I can do some continuity testing to make sure all is well with the header, I’ll give that a shot this afternoon to check.

@Claire :disappointed: that would be me - there were a few things JLCPCB didn’t auto-match from the BOM and I thought I had selected the right pieces… of course obsession over it and checking 30 times would lead me to accidentally select 3.3k instead of 3.3u. Now I better go check the others and order some 3.3u capacitors… Thanks for catching that!

I dont know where in the world you are but if you are in the UK I can pop some 3.3uFs in the post for you FOC many places have minimum orders and shipping gets pricey for one or two components.

With luck thats just the only impediment to it working though a wonky crystal is never a good sign.


That’s incredibly kind of you! Unfortunately I’m in the US but I’ve already got a Digikey order I’ve been waiting to place so I just added a few caps to it. Fingers crossed that’ll do it! I checked everything else and it looks like that was the only part selection mistake I made, thank goodness. I’m going to reflow/reposition that crystal while the air is hot, too.

I was also seeing the “Jack Fail” message on a newly assembled DIY shield (191106 + Pi3B), but I think my problem was different from @buckets. The codec appeared to be recognized, since it was listed with aplay -l and visible in alsamixer. However there was one error in dmesg: bcm2835-i2s 3f203000.i2s: I2S SYNC error!.

I suspected the crystal and reflowed a few times, but the error persisted. I started checking connectivity with a multimeter and the crystal looked good.

Then I checked the codec and found a bridge between pins 4 and 5. I had already reflowed the codec and looked closely at the pins and couldn’t see any bridges. I used a dental pick to gently scrape between the pins and broke the “invisible” bridge :slight_smile: . Pin 4 is SCLK and pin 5 connects to +3.3V. A bridge between those pins sounds like a reasonable cause of the sync error I was seeing previously. Now the shield boots and all is well!

This was my first SMD soldering project and I’m happy that it all worked in the end. This thread has so much valuable information and I couldn’t have completed this project without it. Thanks!


I keep getting a JACK FAIL message on boot up. nothing else, just those 2 words. What part of my DIY Shield should i be looking at to fix, please?

Try booting up with no USB devices (or less) plugged in. I had this problem after the march system update (see this thread).

For me, the problem was solved when I just plugged in one or two USB devices.

Btw, that issue is fixed to our knowledge with the latest update (released a couple.weeks after the 220306 image)

To the OP: In general the message means the audio hardware is not functioning. Common causes include build / soldering issues on DIY hardware, and (now) flashing the wrong version of the disk image (with wrong codex support)

Has anyone tried PEC11R-4215F-N0024 (24 detent)? I think the detent would provide nice tactile feedback when moving through the menus, assuming each detent represents moving one step in the menus. Are there any potential issues with using this encoder?

They jump 4 “steps” per detent I believe. Less than ideal for navigating menus

(I think) Someone has previously hacked around this in the norns encoder code to compensate (you’d need to do a bunch of searching here for details)

1 Like

personally i would be very hesitatnt to use mechnical encoders, which exhibit bounce and chatter noise. where opticals do not. neither the norns PCB nor software stack is debouncing the inputs in a way that would be appropriate for those parts. that would explain spurious extra ticks (if there is not another explanation.)

i am stupid. the recommended encoders for the shield are indeed mechanical (but very clean w/r/t bounce noise.)

Are there optical encoders that work with norns shield? The recommended PEC11R-4015F-N0024 is mechanical.

Speaking of norns shield encoders, if I was to “upgrade” my norns to fancier knobs, how do they come off? Could I just pull them really, really hard to get them off the encoders? I’m hesitant to use force on electronics…

I swapped mine, they came off very easily.

1 Like

oh, you’re right! i was quite wrong! sorry for the misinformation.

these are bourns mechanicals with an extremely low contact bounce rating:

many manufacturers do not bother to disclose a bounce interval; when they do, 10+ms is common. something to look for when considering substitutions.

1 Like

Are these the parts in the BOM? If not, do you have a part no. for them? I need to replace one of the encoders in my Fates, and it would be good to upgrade all of them at the same time (assuming the same parts are speced for both Shield and Fates).

yes that’s from the dataasheet for PEC11R-4015F-N0024.

Ah, those are the parts I have already. Thanks for getting back to me though.

I’m going to start my build of the shield, but on the PCB, R11 and R12 are placed vertically.
Should I read it bottom to up, so R11 placed between C15 and R12 ?

Thanks !

R11 and R12 are the same orientation as C14 - perpendicular to C15. There’s a good photo here


I reworked the norns shield eagle files to use a different layout and buttons, and also added in the same headphone driver that is used on stock norns. I soldered it together tonight, and everything except the headphones works. That could easily be due to my circuit design—I used the suggested circuit from the datasheet and connected it to the i2c0 port on the pi.

I’m just wondering if it is possible that the headphone output is disabled in the norns shield image/firmware? Otherwise, I probably have some hardware debugging to do.

[Edit:] I was just looking through the code and I see:

void i2c_init(void) {
    if (platform() != PLATFORM_CM3) return;

In the file norns/matron/src/hardware/i2c.c that sets up the i2c communication for the headphones. So maybe there is a software problem here (i.e., the headphones are disabled for anything but stock norns)

Does anyone know how I could patch my software to remove that? I guess it would involve recompiling some stuff…

[Edit2: ] So, I commented out the platform check in i2c.c and recompiled norns using waf. Headphone out works too now.