[Start]1.Assembling and connecting Pokitto to PC


#1

In this video we open one of the Pokitto earlybird boxes, assemble the device and connect it to the PC as a flash drive.

  • 0:00 What is inside the Pokitto Box?
  • 9:37 The mysterious tester program already on the Pokitto
  • 10:20 Connecting to PC/Tablet

Connecting Pokitto in programming (flash drive) mode


Learning to talk to Pokitto
#2

For the screen connector, check it before connect it :wink:

he need to be clean and proper (no clue on it).

Connect it well and put the black security :wink:


#3

A note from experience (Thanks Jonne for the help!):
Triple check the black ribbon latches around the connector are pushed in all the way, mine was very slightly out and nothing was showing up correctly


#4

Cross checked and confirm. Between step 7 and 8, I suggest to verify the display is working.
One thing that is not explain, is what audio file to put in what format to test the sound.


#5

Could you confirm/explain that the filesystem name is “CRP DISABLD”?
This may seems “obvious”, but that name is “frightening”, something is disabled, why, where, what did I do wrong?
There might be other trick to discuss on the filesystem, especially if working on a MAC. There tend to be many metadata files and hidden files/folder when deleting and adding file to file system. This might or might not be/become an issue… to be tested.


#6

Explanation coming in a new video thats uploading RIGHT NOW!


#7

Ah, the infamous .DS_Store, a source of eternal loathing.


#8

CRP Disabled = write protect off. comes directly from ROM, cant be changed

remember: this chip is a serious chip intended for engineers. i am the lunatic using it for a game console


#9

@jonne Just to know it for later, how do I get these .bin files for pokitto. Is there any method of “Make project to .bin”?


White screen of what?!?
[Solved] Problems with buttons and binaries not running
#10

Thought it might be worth mentioning here that writing to CRP DISABLD on Linux is not as simple as drag & drop! Had me banging my head against the wall for some time before I tried booting into Windows instead to see if that made any difference… from https://www.nxp.com/docs/en/application-note/AN10986.pdf:

“The data written to the filesystem is organized in flash by disk block order, with the beginning of flash starting at block 4. If firmware.bin is deleted, PCs running windows will allocate any new file starting at block 4 and using increasing block numbers as more data is written. This means that in Windows, any standard program or tool can be used to write new firmware to the LPC1300. In a Windows Explorer window, a user can delete firmware.bin and drag over a new file to program the flash. Unfortunately, FAT filesystems on Mac and Linux machines tend to allocate blocks to files in a different order which results in data being written onto the ISP disk, and consequently firmware being written to flash, being reordered. This will cause the firmware update to be unsuccessful. There are two workarounds for this. The most general workaround is to overwrite the firmware.bin file in place. A more “brute-force” option that requires administrative privileges to do direct disk device writes to /dev.”


[Solved] Uploading .bin to Pokitto under Linux
#11

Am I the only person having trouble writing to Pokitto? it seems that quite often the data just doesn’t take and the Pokitto stays in CRP DISABLED mode and I have to write the bin two or three times, sometimes needing to recompile before it resets properly.


#12

I have never come across this issue.

  • has it started recently or has it been since the beginning?
  • have you tried other cables?

#13

I can’t really remember, I do more tests now than I did when I first got it, so it might have been from the beginning.
Other cable do the same thing. Could it be something to do with the compiled code? I think I remember you mentioning that there needs to be some checksum in place or the code wont boot, perhaps that’s why recompiling usually fixes it.
Or maybe it’s to do with the way windows copies files, I might not be leaving enough time for the process to finish properly, I know windows doesn’t copy files in the exact amount of time it says it does.


#14

This I have noticed at times. Try to “Save As…” on top of the firmware.bin and see if it makes a difference


#15

I was using windows and it happened to me just one time. I tough the boot button was stuck and Pokitto kept rebooting for that reason. After more test, only flashing again the firmware give me the usual welcome screen.
My feeling was that probably I rebooted too early after the new .bin was copied, resulting in corrupted file.


#16

Yes, this is possible. I am not sure if the flashing is “realtime” or if theres a small delay before its ready after the bin is copied.


#17

I have tried some different cables, I have also tried ‘safely removing’ to Eject LPC1XXX IFLASH then waiting a few seconds and it still happens randomly.
Usually re-copying the file will make it work, but sometimes I have to re-compile.


#18

I don’t actually eject the pokitto and haven’t had any issues copying from windows and the files are always copied quick enough for me to call it instant.
Instead of ejecting i just press the reset button on the pokitto, that disconnects it and boots it up. That way if I do have a corrupt file I can just reset in flash mode and save a bit of plugging and unplugging my USB cable.


#19

I really don’t know what is causing this. I do know that I am probably flashing my Pokitto a lot more that many of the current users. But yeah, my usual method is to delete firmware.bin, drag and drop the file I just compiled, wait until the fill copying dialog box has vanished then hit the reset button.


#20

Can we do this: I will send you a new Pokitto. You send me back the one you have when you get the replacement from me. Normal mail is OK.

Plan Ok?

I want to debug that individual board to see if there is something dodgy going on.