I know that if you hold down the lower back button when turning the Pokitto on it also boots into CRP DISABLD mode, so I’d guess there’s a short circuit somewhere that’s causing the board to act as if that button is being held down.
(A bit like how I had that incident where a bit of solder connecting two MCU pins was causing one of my buttons to reset the Pokitto.)
I’d assume it’s more likely to be a hardware issue than a software issue since if it were a software issue then uploading new programs would probably fix it.
I can think of one case where software could possibly cause issues like that, but I don’t know if it would apply to the Pokitto.
On the Arduboy there’s an issue where certain games can accidentally overwrite the bootloader on certain Arduboys.
The bootloader is supposed to be protected from being overwritten by some bootloader protection pins, but if they aren’t set properly (as one or two batches weren’t) then the bootloader can be overwritten under the right circumstances.
So if the Pokitto has a similar set up then it’s possible that the bootloader could have been partly overwritten, causing the Pokitto to only boot into CRP DISABLD mode, but only if that’s how the Pokitto works. I wouldn’t like to assume either way, so I’ll wait for someone who knows more to say whether it’s possible or not.
Either way it’s probably not something you could have avoided.
I actually just cleaned them with the sleeve of my shirt, they looked clean anyway. So i dont think thats the cause. (removed the rubber buttons just in case)
If i do a safe eject from windows, it only gets disconnected. Pokitto itself stays in crp_disable mode.
Even if i delete the firmware.bin thats currently in the memory. (tried multiple .Bin files too)
@Jonne could you tell me which pins on the chip take care of the reset signal ? I would like to check if there is something with the solder at that point.
I placed the animtest.bin from the Pokitto gamelist on the device, and it started working again.
So to check i placed the .Bin i was working on back and reset, still works…
I dont know how this happend but maybe i was to fast with pulling out the usb or something like that.
Sounds like the issue I had a while ago. If the file does not write correctly then it will not boot and stays in CRP_DISABLED mode.
My solution was the following (if you’re using Windows) -
Copy the following into notepad, save it as _copy.bat
@echo off
:::
::: .--------------------------.
::: |o o|
::: | .----------------------. |
::: | | | |
::: | | | |
::: __| | __ __ /_ ,_/_/_ __ | |__
::: (o_ | /_//_//\ / / / /_/ | _o)
::: | | / | |
::: | | | |
::: | | | |
::: | '----------------------' |
::: | _ .-. |
::: | _| |_ .-. ( A ) |
::: | [_ o _] ( B ) '-' |
::: | |_| '-' |
::: | ___ |
::: | (___) |
::: |o o|
::: | .----------------------. |
::: |o| |o|
::: '-' '-'
for /f "delims=: tokens=*" %%A in ('findstr /b ::: "%~f0"') do @echo(%%A
IF [%1] EQU [] Goto:NoDrop
set VAR=Destination
for /f "skip=1" %%L in ('wmic logicaldisk where volumename^="CRP DISABLD" Get Caption') do @call :SetVar %%L
echo Copying %~nx1 to %Destination%^/firmware.bin
del %Destination%\firmware.bin
copy "%~1" %Destination%\firmware.bin
goto :Finished
:SetVar
set Label=%1
if NOT [%Label%]==[] set %VAR%=%Label%
goto :EOF
:Finished
pause
cls
exit
:NoDrop
echo Drag and Drop your .bin file onto _copy.bat to send it to Pokitto.
pause
cls
exit
Then to copy the software to your pokitto, just drag and drop its file onto the _copy.bat file.
What _copy.bat does, if search your computer for a device called “CRP DISABLD”, it will then delete “firmware.bin” and copy your new file in its place.
Once it’s done, just hit any key to close the window. At this point you are safe to reset the Pokitto and your file will boot. It has worked 100% of the time for me.