Building a Proffieboard V1/V2 test rig.
This thread is for any questions or experiences regarding assembly, use, results etc…
First off, I believe these pages should list 12 M3 nuts, not 6, yes?
https://fredrik.hubbe.net/lightsaber/v4/pogo_pin_adapter.html
https://fredrik.hubbe.net/lightsaber/v5/pogo_pin_adapter.html
You are correct.
I will update tonight.
Pages updated.
Cool, thanks.
Any chance there’s a kicad somewhere for a the 1.5 adapter board?
That V4 page doesn’t provide a link like the other 2 do, although I guess the 40 pin would have to be the same.
I should have one somewhere…
Not needed, as the pinout is the same (duh on me) so instead, save your effort for once I start running tests and have questions 
I might be helpful to make the step-by-step instructions a bit more robust once I understand.
Ok lol. Question on step 1!
1. Make sure you have jumpers all down the middle of the tester.
3. Plug in ST-Link V2, and hook up to the test rig.
4. In one window, start up OpenOCD
6. Start up arduino and enable test script in lightsaber.ino
tests.cpp files. Is the one found at common/tests.cpp what I’m after?7. Hook up a multimeter to test board and set it to beep on a short. Verify that this works!
each pair in J2, J3 & J4 should have jumpers,
You may also want jumpers on all the pairs in “D1 select” and “LED1-PXL”, and a single jumper between “3.3v & P” in the 3-pin jumper in the corner.
Doesn’t matter. I just keep mine plugged in all the time.
Make sure to check the pintout of the st-link though. Some don’t match the breakout board, and then you can’t just use a flat cable.
It needs a board-specific config file if that’s what you mean.
Try checking this thread for how to invoke OpenOCD: Running a debugger
tests.cpp are unit tests, and not what you want for this.
What you want is scripts/proffieboard_test_script.h, which is enabled by including it in ProffieOS.ino. It does blinks the leds, plays sounds and asks you to press the buttons to make sure that things are working.
Touch the two leads together and make sure it actually beeps.
The instructions below specify how to actually use it. I learned the hard way to always measure GND ↔ batt+ for shorts before plugging in a battery.
thank you. ok making progress,
Now, there’s no /var/log/kern.log to tail.
Also, steps only say to launch openocd. I’m guessing I need GDB going too?
Is there a positive response when buttons pressed? just getting 3 beeps, high, low, high (fail?). Except buttons work fine,
I might be jumping ahead too much, or just not understanding.
Appreciate any pointers.
Might need to run that as root, or the log might be called something else.
The purpose of this log is to see that the board connects and /dev/ttyACM* gets detected.
No need for GDB when testing. All you need is to make sure that OpenOCD can talk to the board.
It should say “press button one”, “press button two”, etc.
Beeps might be an indication that the blade ID isn’t reading right. Although I don’t see a “high low high” beep sequence in the script:
Maybe you meant low high low?
The blade ID should read as ~2.5 volts if you have both the PU and PD jumpers in place, but you might also need to set the blade ID class to the external pullup class in the config file.
Part of manual testing is learning how the board should behave when you run it through these steps. The hard part is not to forget any of the steps.
The idea is that to test the buttons, look at the LEDs to make sure the patten looks right, look at the serial monitor to make sure that you’re not getting any odd errors and check the OpenOCD window to make sure that the debug pin works. Manual testing isn’t quite as good as automated testing, but all the pins should at least get some level of testing.
I would love to see how the test bed ends up looking since I still have that spare board and have thought about this myself.
At the moment, it looks more or less like this:
https://fredrik.hubbe.net/lightsaber/v5/test_rig.html
I think it’s this:
Right, missed that part.
I think maybe you need to remove the buttons from your config file, either that or there is an actual short between the buttons…
Step 4 says " It should say LOW BATTERY repeatedly, no beeps"
I do not have this. Is that Teensysaber leftover?
Or did that evolve in the code to become the part where it prints in serial monitor “Waiting for battery power” and runs dots?
The way it’s worded implies “as audible speaker output”, which it doesn’t do for me, hence the question.
While I’m at it,
5. Switch to battery power
6. Press BOOT
7. Press Power button.
I get no prompt for Press BOOT. It goes right to power button prompt.
It should also probably have in the prep section something like:
Put a music track named cantina.wav on the root level of the SD card.
Hmm, might be because of a fix I made a long time ago where I made it not say “low battery” if the battery power was near zero.
It should say just “press button” (because there is no talkie word for “boot” available).
It’s in the script:
Although there seems to be a bug here:
PULLUP should be PULLDOWN
I will add that.
OK that’s what I thought, but the bug was causing it to skip the waiting for it.
I changed to PULLDOWN, and made a “boot” talkie. All working well, thanks!
Remaining to-figure-out:
tail command can’t find that log file on MacOS (10.14 anyway)Once all is done, I’ll make a Wiki and a tutorial video.
I’m not sure if you need the tail thing. It’s just supposed to show that the board is working and stuff, but those instructions are for linux, I’m not sure if a log like that exist on mac.
The neopixels will do nothing, but the little LEDs should light up one at a time in order.
See other post.
And hopefully a pull request with fixes and working config file.
I think I remember now.
The tail window is supposed to show that USB is working.
You can use the serial monitor to test that instead.
Anything that uses the USB port can be used.