New wilba CS - button problems

[Juggle]

I’ve been working on a SeqV4 with wilba panel since this past December.  The last parts I was waiting on (my LCD’s) finally arrived this week and I was excited to get it finished this weekend.  However once I hooked up the LCD’s and connected the CS I found that something is definitely not right.

What I’m experiencing is VERY similar to what was described in this thread: 

< base_url >/topic/20597-help-needed-connecting-wilba-cs/?do=embed

However I only have the STM32F4 core and CS along with the two LCD’s wired up.  And I did connect the CS on the rear not the top.  I still suspect I may have a mistake in how the CS and Core are connected though as I keep getting mixed up front/back top/bottom trying to think the connection through.   

Quick overview:

I checked all the Resistor array’s and they all look correct:

I don’t have any LED’s mounted yet, and confirmed that U7 and U8 are 74HC595’s while 1-6 are 74HC165 and they’re all installed fully and in the correct direction.  

If I power up the Core/LCD’s without the CS connected it seems fine.  But if I power it up with the CS connected the LCD’s freak out big time and keep flipping through all kinds of different stuff.  Connected to MIOS I see a bunch of things being triggered like in the other post.  If I turn the first encoder (on the far left) it will trigger a bunch like this:

 

Quote

[237423.245] [DIN_TESTMODE] Pin   8 (SR2:D0) depressed
[237423.245] [SEQ_UI_Button_Handler] Button SR:2, Pin:0 not mapped, it has been depressed.
[237423.245] [DIN_TESTMODE] Pin   9 (SR2:D1) depressed
[237423.245] [SEQ_UI_Button_Handler] Button SR:2, Pin:1 not mapped, it has been depressed.
[237423.245] [DIN_TESTMODE] Pin  10 (SR2:D2) depressed
[237423.245] [SEQ_UI_Button_Handler] Button SR:2, Pin:2 not mapped, it has been depressed.
[237423.246] [DIN_TESTMODE] Pin  11 (SR2:D3) depressed
[237423.246] [SEQ_UI_Button_Handler] Button SR:2, Pin:3 not mapped, it has been depressed.
[237423.246] [DIN_TESTMODE] Pin  12 (SR2:D4) depressed
[237423.246] [SEQ_UI_Button_Handler] Button SR:2, Pin:4 not mapped, it has been depressed.
[237423.247] [DIN_TESTMODE] Pin  13 (SR2:D5) depressed
[237423.247] [SEQ_UI_Button_Handler] Button SR:2, Pin:5 not mapped, it has been depressed.
[237423.247] [DIN_TESTMODE] Pin  14 (SR2:D6) depressed
[237423.247] [SEQ_UI_Button_Handler] Button SR:2, Pin:6 not mapped, it has been depressed.
[237423.247] [DIN_TESTMODE] Pin  15 (SR2:D7) depressed
[237423.247] [SEQ_UI_Button_Handler] Button SR:2, Pin:7 not mapped, it has been depressed.
[237423.253] [DIN_TESTMODE] Pin  40 (SR6:D0) depressed
[237423.253] [DIN_TESTMODE] Pin  41 (SR6:D1) depressed
[237423.253] [SEQ_UI_Button_Handler] Button SR:6, Pin:1 not mapped, it has been depressed.
[237423.253] [DIN_TESTMODE] Pin  44 (SR6:D4) depressed
[237423.253] [SEQ_UI_Button_Handler] Button SR:6, Pin:4 not mapped, it has been depressed.
[237423.253] [DIN_TESTMODE] Pin  45 (SR6:D5) depressed
[237423.253] [SEQ_UI_Button_Handler] Button SR:6, Pin:5 not mapped, it has been depressed.
[237423.253] [DIN_TESTMODE] Pin  46 (SR6:D6) depressed
[237423.253] [SEQ_UI_Button_Handler] Button SR:6, Pin:6 not mapped, it has been depressed.
[237423.254] [DIN_TESTMODE] Pin  47 (SR6:D7) depressed
[237423.254] [SEQ_UI_Button_Handler] Button SR:6, Pin:7 not mapped, it has been depressed.
[237423.261] [DIN_TESTMODE] Pin  48 (SR7:D0) depressed
[237423.261] [SEQ_UI_Button_Handler] Button SR:7, Pin:0 not mapped, it has been depressed.
[237423.261] [DIN_TESTMODE] Pin  49 (SR7:D1) depressed
[237423.261] [SEQ_UI_Button_Handler] Button SR:7, Pin:1 not mapped, it has been depressed.
[237423.261] [DIN_TESTMODE] Pin  50 (SR7:D2) depressed
[237423.261] [SEQ_UI_Button_Handler] Button SR:7, Pin:2 not mapped, it has been depressed.

 

All the way up to pin 143

If I pull out the shift registers it doesn’t go crazy…but…obviously none of the buttons/encoders work either.

I’ve checked over the board several times and don’t see anything obviously wrong, no missing solder connections, no bridges, no missing parts other than the central encoder I haven’t installed yet and the LED’s.  

I kind of suspect that SI and SO are backwards as it seems that SI is connected to SI and SO to SO and saw a reference in another thread suggesting they should be connected SI to SO and SO to SI…but can’t for the life of me figure out how to mount the header to allow that.

Oh, and yes I do have the wilba config file loaded…this one:  http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Fhwcfg%2Fwilba%2FMBSEQ_HW.V4

Really appreciate any advice or help.  I figure there’s probably something obvious I’ve messed up and keep overlooking.

 

 

 

[latigid_on]

Hopefully all of your resistor networks are of the right type and soldered correctly?

[Antichambre]

Latigid push you in the right way, a SRIO bécomes crazy when an input of a 165 is not connected(floating). They have to be all connected to a level even if They are not used, it is what thé résistor network do…

[Juggle]

Thanks for the feedback guys.  But the resistor networks look correct to me:

I can’t see the markings on the ones on the other side to confirm…but…if I could see the markings they’d be backwards so not seeing them is basically confirming that they’re installed the right way around.

These are the networks I used:  https://www.mouser.com/ProductDetail/264-10K-RC

Which as far as I can tell are the same ones specified in the parts list.

I triple checked the soldering on them and there’s no missed connections and they all look like clean joints.

So as far as I can tell they’re the right networks, installed the right way, and properly soldered.  Any thoughts how to debug from here?

 

 

 

 

 

 

[goyousalukis]

Just an idea, take out one IC at a time and see at what point the LCDs stop going crazy. Maybe that will help you find the problem area?

Justin

 

[Juggle]

25 minutes ago, goyousalukis said:

Just an idea, take out one IC at a time and see at what point the LCDs stop going crazy. Maybe that will help you find the problem area?

Justin

 

I started to try that.  I didn’t trace the circuit yet to confirm which are in the circuit first - but after I had them all out I tried just putting U1 back in by itself and saw signs of the same problem.  I checked everything I could think of around U1 but nothing was jumping out at me.

[Phatline]

do you leave out R30 on core-modul -like described here: http://www.ucapps.de/mbhp_sdcard.html

 

“The resistor array R30 of the MBHP_CORE_STM32 module shouldn’t be connected when a SD Card is used, because pads are configured in Push-Pull mode at 3.3V.
SD Card transfers could work unstable with these Pull-Up resistors!”

 

-by the way i had not noticed problems by core modules with R30 in it ( i have many of them) but i dont use a SEQV4 firmware on them… but i used this Wilba pcb for other things…

 

maybe a bridge-ing of the J5A and J5B on core can solve problems (it they are softwareside activated) - again dont know how they are used in SEQV4 firmware

 

 

 

by the way the Wilba-CS is a BLM - Button-LED-MATRIX, because of the interconnection of button and LEDs - i think you should solder them in first, before investing more time in trouble shooting - this time.

 

wait half an our or so, i upload a test program for the wilba program, i have wrote, while i was developing my “trigger matrix”, so you can test button and encoder pin connection… but i am still not shure that this will function without LEDs soldered anyway… just a try… wait half an our, i check the code if its still working ( having a wilba cs lying around… have connect lcds and core to it…)

 

 

[goyousalukis]

I think it still functions ok without all the LEDs. While I was waiting for my panel to arrive, I just soldered one R/G led for step one and the BPM LED to test it, and it worked fine with just those connected.

[Phatline]

well then upload this, and check your buttons and Encoders… it dont tests the leds… but dont matter you havent soldered them anyway

(it is programmed that the Wilba PCB is first in the J8J9 chain)

project.hex

[Juggle]

Just now, Phatline said:

do you leave out R30 on core-modul -like described here: http://www.ucapps.de/mbhp_sdcard.html

 

“The resistor array R30 of the MBHP_CORE_STM32 module shouldn’t be connected when a SD Card is used, because pads are configured in Push-Pull mode at 3.3V.
SD Card transfers could work unstable with these Pull-Up resistors!”

Hmm, does that apply to the Core_STM32F4?  Looks like it’s on an older revision of the Core32.  On the F4 the array is R33 and I didn’t see any notes about leaving it out in the assembly instructions.

 

 

by the way the Wilba-CS is a BLM - Button-LED-MATRIX, because of the interconnection of button and LEDs - i think you should solder them in first, before investing more time in trouble shooting - this time.

I’ve left the LED’s out since getting them at the right height is tricky and I’m still finalizing my panel. I’m cutting my own panel with a homemade CNC I built - Due to the selection of bits I have the smallest radius ID I can do is 3mm right now (I have some smaller bits on order) so I redrew the panel with 3mm radius corners instead off right angles - and then 3D printed and vapor smoothed custom caps to match.  I’m also still debating what material I’m going to use for the final panel so I’m not quite ready to mount the LED’s yet.

And Hawkeye’s build thread for the SeqV4 with wilba panel specifically mentions testing the switches before installing LED’s.  (or encoders…but since I was waiting on my LCD’s I went ahead and installed the encoders as well - except for the central one which again is waiting on final panel decisions.

 

I originally thought it might be an SD issue as I did see a bunch of messages about the SD on the LCD’s when it was freaking out - but with the CS disconnected the core seems fine by itself.  Working through MISOstudio I can load/edit/save the config file no problem and all of the command line stuff I’ve tried seems to work as expected.  

That said…there is one are of concern I do have with my core.  I had previously used this Discovery board in a quadcopter with a custom made IMU and slightly modified TauLabs firmware - but retired it about two years ago when the TaulLabs project was forked and getting the new fork (dRonin) running on my FlyingF4 we discovered some issues with the Discovery F4 and that application that led us to decide to drop support for it.  (And while I’m thinking of it yes I did upgrade the firmware on the Discovery board - it was actually already upgraded before I started on the SEQ but I confirmed it just to be sure.)

Anyway - when I was building the quadcopter I ordered some machined headers for mounting the Discovery…but the discovery’s pins didn’t fit in them and I wound up ordering some other headers to use.  When I assembled the Core I forgot about that - found the machined headers in my parts bin and installed them - only later to realize the Discovery won’t go in.  So I dug out the old headers I had used to mount it on the quadcopter (benefit of being a packrat) but the idea of desoldering 80 machined pins seemed like a great way to kill my Core PCB.  So instead I double stacked the headers - the Discovery plugs into the headers that fit..and the pins of those headers are plugged into the machined headers on the Core (since they did fit.)  It’s a bit tall and ugly…but should be ok.  I checked continuity off the top of the Discovery and bottom of the Core after doing it and all seemed well…but I mention it just in case.

[Juggle]

5 minutes ago, Phatline said:

well then upload this, and check your buttons and Encoders… it dont tests the leds… but dont matter you havent soldered them anyway

(it is programmed that the Wilba PCB is first in the J8J9 chain)

[project.hex](< base_url >/applications/core/interface/file/attachment.php?id=13883)

Ok, this gives me some hope.  Video of the test is uploading…but every button and encoder registered some response with your test code.

I’m wondering if maybe I missed a release or something and had a mismatched config file for the release I flashed…going to try re-flashing the seq code and uploading a fresh config file.  Crossing my fingers…

 

[Juggle]

Woo Hoo!

Looks like that solved it.  I hate it when projects drag on this long due to waiting on parts

Looks like I flashed it back in mid to late November probably with “midibox_seq_v4_094”  But once I finished assembling it I grabbed the hwcfg file out of SVN.

But…I don’t see any changes in the config file between the version of the sequencer fw I just downloaded and the version I had on my drive from November…Not sure what I did with the version I’ve been working with…just overwrote it with the version from the fw package.

But it appears to be working!   

Now to go finish cooking and eating Easter dinner so I can work on adding some LED’s…and then try to figure out what’s up with my old PIC based core’s so I can get my SID and FM synths going again so I can really test this out

Thanks for the ideas and help everyone!

 

Oh and Phatline in case you want to see it here’s your test program up and going which led me to question the software side instead of hardware!

Mbseq CS test

 

 

[Phatline]

 great, i will upload the hex file to the build-wiki - 4 easy debug… EDIT: done