Posting here so this isn’t lost in the pre-order celebrations on Discord (congrats again, Panic team!) Anyone else have an unresponsive crank on the latest OS? It recognizes docking/undocking just fine, but rotation is a no-go. This is new for me. I’ve coddled my PD, so I’m hoping this isn’t a hardware issue. Factory resetting hasn’t helped, unfortunately.
I did catch that on Discord and filed an issue, but thanks for repeating here! It’s much easier to respond without getting lost in the noise. I haven’t heard any other reports of 1.2.1 breaking cranks. When you launch the simulator with the device plugged in do you get a line like
serial#=PDU1-Y000223 in the console? There’s a bit of code that disables the crank if the serial number isn’t set, just a side effect of some factory stuff, and I can’t imagine how this update would be keeping the serial number from being read, but it’s my only guess rn
Thanks @Dave – it looks like the serial number is set. Here’s what the console spits out upon connection:
dcache usage: dcache on/off icache usage: icache on/off version build=9858588c7e0c-1.2.1-release.117204-buildbot-20210715_154423 boot_build=9858588c7e0c-1.2.1-release.117204-buildbot SDK=1.2.1 pdxversion=10200 serial#=PDU1-Y000475 cc=9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599] settime 2021-07-29T21:28:59.790Z 4 time and date set
If I’m being 100% honest, I can’t definitively say that the crank stopped working only on this release. It’s likely been a few OS updates since I last worked on anything that needed it.
okay, let’s try running the factory button test directly on the serial port. If you’re on a Mac:
- open Terminal.app, unplug the Playdate
ls /dev/cu.usbmodem*in Terminal
- plug Playdate in, wait a second or two
ls /dev/cu.usbmodem*again–a new entry should have appeared
screen /dev/cu.usbmodemXXXX 115200where XXXX is the number corresponding to the Playdate’s dev entry. The terminal window should blank when you hit enter.
- enter “buttons” followed by control-j (screen’s key mapping is all messed up, at least on my machine, so I have to do control-j instead of enter )
You should now see a bunch of lines like
buttons:00 00 00 crank:0.000000 docked:1
scroll by although in your case it might be
crank:<failed>. If you do get a number, does it change when you turn the crank? Hit control-j again to stop the test, and then control-a control-backslash to get out of screen.
If you’re on Linux I think it’s a similar process though I’m not sure what file you’re looking for. The
lsusb command might show you where the Playdate’s dev file is. If you’re on Windows… Maybe CoolTerm will work?
Thanks for those steps, @Dave. Unfortunately it looks like I may have a hardware problem –
docked updates fine, but I get
crank:<failed> with no changes on rotation. It’s strange this happened seemingly out of nowhere, but such is the fun of pre-production devices
Given you haven’t heard of anyone else with this issue, I suspect it may be mine alone. But, just in case, is there anything else I can test/send you to confirm? If there is a chance something obscure is going on, I’d love to be helpful.
I have a possible fix if you want to give it a try. I put your device on a test cohort at memfault and added the test build to the cohort. Can you run Settings and click through to System > System Update and see if it has an update for you? The last time I did this it took some messing around with version numbers to get the update to show up, so I might have to do that again here before it’s available.
My suspicion is the i2c line on the crank sensor is gunked up. On newer Playdates you can hit the reset button hidden in the crank pocket and it does a power cycle of the entire device, but on your older dev unit it only resets the main cpu, not the various peripherals. So in this firmware build I’m attempting a software reset of the i2c line.
No updates available on my end, @Dave, but I appreciate you helping me try this out.
ah, okay… Looks like I have to bump the version number to get the system to see it as an update. Mind giving it one more try?
Hey @Dave, that update came through. Unfortunately, no change re: the crank.
gah! sorry for the delay, juggling half a dozen things here at once, as usual. I found another possible fix last week but it needs more testing. I’ll try and get this taken care of tomorrow!
okay, I pushed an update to the server for your device. Can you check for the update and give it a try? Crossing fingers won’t hurt, either…
No worries, @Dave! I have a few games I’m working on that use the crank, but I can simulate in the meantime (I have a production unit coming next year). No rush on my end. I really appreciate you trying to figure this out!
Unfortunately, no joy on the new build either
wow, okay. Then it’s definitely a hardware problem. We’ll get a new device sent out to you and a shipping label to return the broken one, if that’s not too much of a hassle. I’d love to figure out what went wrong there
No hassle at all! I really appreciate you trying to help me out. Let me know if there’s any details/testing I can send/do for you in the meantime.
@dave It looks like my device is pinned to the 1.2.2 test build you put together. While I’m waiting for the device swap, would it be possible to put me back on the regular update stream?
Okay, you’re back on default now. Sorry about that!
No worries! Thank you.
Hi @dave: I wanted to wait a bit to check in, given how busy I imagine you’ve all been with preorders. I want to make sure I don’t accidentally miss the replacement unit when it’s sent out. If that’s still the plan, should I keep an eye on my account for tracking and such?
Hi, Brian — We can send you a new unit, and if it wouldn’t be too much trouble, we’d like to get your broken unit back (we can provide you with a shipping label.) I’ll message you directly and we’ll get this sorted out!
Thanks for taking care of this, Greg! And sorry Brian for dropping the ball here. I made the mistake of replying before I’d actually done anything, then I forgot that I hadn’t already dealt with it. Thank you for your patience!