I tried loading the game disk and when I deleted and tried to replace the firmware.bin file, a new firmware.bin file is created (262kb). No matter what .bin file I place in the flash directory, it overwrites it with this firmware.bin file. The result is a blank white screen on boot and I’m not able to get anything to run.
Any help or suggestions?
So I think I figured it out. Maybe Macs don’t like Pokitto. I was able to do within a Windows VM and all works now.
the mac finder creates extra hidden files in folders
since pokitto folder is its binary this bricks the system temporary
heres the fix:
create a pokitto.command file and paste this in
#!/bin/sh
echo "drag .bin file and press enter"
read BIN
cp $BIN /Volumes/CRP\ DISABLD/firmware.bin
diskutil unmount /Volumes/CRP\ DISABLD
now just double click that and drag your file in the terminal
I received my Pokitto yesterday and saw the same behavior when writing files under Linux. This post discusses the issue and suggests a workaround of – overwrite firmware.bin rather than deleting firmware.bin and writing a new file. I haven’t tried it yet.
in my command file i am also overwriting the file but the main point is to unmount the device to make sure its finished any actions on the device.
also on mac it will complain about randomly unplugging devices
hope this works, if on linux you can write a very similar script
Just got mine. Overwriting directly left the Pokitto semi-bricked. I could get it back to CRP\x20DISABLD mode, and eventually wrote a game on Windows. But Windows didn’t seem to want to recognize the disk for a while. All working now.
The bootloader is in the rom. Even if you write complete garbage on the flash, you can’t “brick it” in the traditional sense of the word
That’s why I said “semi-bricked”. Since I still got the CRP\x20DISABLD device (reliably on Linux; Windows failed to recognize the disk a couple of times), I was pretty sure I hadn’t created a serious problem.
When you refer to the “bootloader in ROM”, are you referring to the mbed disk driver/loader, or to the USART loader used by the lpc2isp and Flash Magic programs? Does that latter protocol have a name? And finally, isn’t the mbed loader also in FLASH instead of ROM?
FWIW, in 5+ years of helping people deal with devices they “bricked” trying to install deviationTx, I think we’ve seen one actually bricked device (after connecting a 5V source to the µcu); two that overwrote the dfu bootloader (stored in flash, similar to the way I think the mbed loader works) which we thought was impossible but seems to happen if you power cycle at just the wrong instant, and a regular stream of people who managed to flash the wrong firmware, use the wrong flash tool, or power off at the wrong time. Most of these were fixed by pulling the battery, waiting 15 minutes, then rebooting into the dfu bootloader.
I am referring to the USB bootloader in the ROM as described in the user manual, page 430
UM10732.pdf (3.2 MB)
Thanks! Looks like a simple “dd” ought to solve the issues for Linux users, but that didn’t work.
i got this working on a raspberry pi
dd bs=1024 conv=nocreat,notrunc if=~/Desktop/yourfile.bin of=/media/pi/CRP\ DISABLD/firmware.bin
umount /media/pi/CRP\ DISABLD/
@mwm can you test if this code works on regular linux?
i currently dont have a distro setup
#!/bin/sh
echo "copy .bin location and press enter"
read BIN
dd bs=1024 conv=nocreat,notrunc if=$BIN of =/media/CRP\ DISABLD/firmware.bin
umount /media/CRP\ DISABLD
That works. Looks like notrunc,nocreat is the trick. Thanks.
I’d recommend three changes:
These two mean you write full pages, as partial writes might cause it to read the old data to fill out the page. Since there are 4K (mostly) and 32K sectors, those sizes might make more since for bs, depending on how the flashing actually gets done.
So conv=nocreat,notrunc,sync,fsync
well i had to seek this in the depths of the mbed forums, soo i am not sure if thats going to work
also consider the wear of the flash might not be best to clear everything everytime, would like a second opinion from a linux expert on that
I tested it on my desktop, so i works for that at least. I also verified that it fails if you leave off either nocreat or notrunc.
The fsync is just a timing change (also not available on OSX), as the unmount will do it for you. Adding it to the dd just makes it more likely to work if something breaks between the dd finishing and the unmount finishing.
Adding sync pads the last block out with nulls. Since the file wasn’t truncated, not doing that means those bytes have to come from the old file, so the file system will read the file system (not dd) block in order to have them to write back, and the idea is to save that read.
Changing the block size - well, that one’s hard to predict, because the block size on the media (determined by the file system layout presented by the chip, buffer strategy, file system syncs, and flash sector size.
Checking the manual, it appears that the USB ISP code doesn’t use the “erase page” facility, so writing is always going to be full sectors (4K up to ~100K, then 32K for things beyond that). The file system presented by the ROM bootlader has a 1K cluster size. So yeah, 265 bytes was a bad choice. The question is whether you want 1K or 4K writes. If each dd buffer is physically written to flash individually, then writing 4K will mean reading the buffer in 4 times, copying the 1K buffer into the right place in it, erasing the flash and then writing out the rest of the sector. Of course, using a 4K buffer in dd may not help, because that could well turn into writes for each individual 1K cluster.
The VFAT file system, the UMS device driver it talks to, and the MSC implementation on the NXP chip all get a chance to buffer things and change the size of what’s physically written to flash. First question should be whether the MSC implementation does any buffering, as if it’s sufficiently smart, then what the others do won’t really matter much. Second question is whether the VFAT file system and UMS driver will pass a 4K write through to the device, as if it won’t, then 1K and 4K will behave pretty much the same way, just that 1K makes 4x the system calls so is a little bit slower (at least without conv=sync),
yea im not sure how necessary these are wen the current instruction seems to be working.
upload speed was ok for what i have tested. also not sure how compliant this is over the rest of linux
you can write the linux tutorial if you want
My Pokitto was working just fine till I gave it to my kid to play with, and when I got it back it had the white screen of death. My suspicion is that kid accidentally pressed the flash and reset buttons on the back. Those should probably be less prominent (I’m going to remove the rubber nubs if I get this working again)
But: I have a Mac. Does this mean I need to go through some elaborate song and dance to reflash it? Doesn’t the mbed site work?
What does drag your file in the terminal mean?
hey hey hey, do not be alarmed!!
Its the white screen of very temporary death. I have a 2 yr old tester here at home and he hasn’t been able to kill any of the Pokittos laying aboit the house - and its not for lack of effort!
I’ll be back in a moment to help you, after I put my tester to bed.
No its not hard at all. And its an essential part of learning how to use Pokitto. That “white screen” is not the screen of death - it is Pokitto in the “programmable mode” and it is normal behaviour.
In a moment I will provide links on what to do next (I don’t want to tap it all out on the phone!)