WIP console with PIC32MX & MCP2200

Discuss anything not related to the current Uzebox design like successors and other open source gaming hardware
HardlyUnique
Posts: 65
Joined: Tue Dec 08, 2009 7:44 pm

WIP console with PIC32MX & MCP2200

Post by HardlyUnique »

Hello everyone!

Here's the story: AGES ago, I set out to make a homebrew game console like the Uzebox. I picked out some parts and started playing, but real-life quickly got in the way.

Before too long, the STM32F4[DISCOVERY] came out and my little console was totally obsolete before it even existed! :cry:

Well, I recently decided I wanted a bit of a challenge after being away from any electronics-hobbying for a while. I already had all the parts, so I figured, "Screw it! I'm going to start making this thing anyway!"

So, I did. And here it is. :D

Image


Image

3.JPG
3.JPG (88.82 KiB) Viewed 13544 times

Image



Image



These were my goals for the console & criteria to help me choose the right MCU:
  • At least one free, 16-bit data port with DMA (for 15-bit color video)
  • All programming capability is built-in. You build it, you can program it.
  • To facilitate the above, chip needs built-in USB capability. USB functionality can't require a specific clock speed. (Built-in Ethernet is also a plus) EDIT: Oops! Chosen chip doesn't have that! See below.
  • At least two 16-bit timers that can trigger interrupts. At least 3 timers total.
  • Predictable, well-documented CPU with most instructions being single-cycle (or thereabouts) and especially single-cycle (or thereabouts) multiply. (I'm giving dirty looks at you, Propeller!)
  • Chips need to be sample-able.
  • It's gotta be powerful! :twisted:
The PIC32MX695F512L fits nearly all of these criteria nicely. It is also no slouch with 512k flash, 128k RAM and 80Mhz rating! It is only lacking in totally-native USB programmability. Enter the MCP2200.

I chose the MCP2200 to allow hobbyists like myself to talk to the Pic32 with no other hardware, like a $50 ICSP programmer or JTAG probe. This could really be a "project" in and of itself but I consider the goal of including programmability in the design to be a very important one. Other than including this chip, I'm shamelessly stealing the Uzebox's simple design philosophy :twisted: .

The MCP2200 is a very inexpensive USB to UART chip with a fairly easy-to-use API interface. The idea is to use the MCP2200 to bit-bang JTAG, then use the JTAG port to load a more-permanent USB bootloader into flash. Of course, if you already have a JTAG probe or choose to buy one, you can presumably just use that.

This USB->JTAG project is where about 100% of the progress has been, so far.


I've made a little program that can use the MCP2200 to talk to the pic32.

This is how it works and what is working so far:
  • The program uses the MCP2200 to bit-bang a JTAG interface.
  • It uses that JTAG interface to ID the PIC and put it into Serial Execution Mode.
  • SEx mode (lol) allows the program to feed the PIC's CPU instructions and make it execute them.
  • The program feeds the CPU code which copies each instruction of the programming executive loader to RAM.
  • The PE loader runs on the PIC CPU.
  • The program parses a hex file from Microchip containing the Programming Executive and sends the code to the PE loader.
  • The PE loader takes the PE code and copies it to RAM.
  • The Programming Executive is executed on the PIC CPU. The PE allows for much faster and simpler programming over the JTAG interface.
  • The program sends a command to ask the PE for it's version number. The PE responds appropriately.
... and that's all for right now :)


I don't think I can tell you how rewarding it felt to see that unassuming version number come across the first time. Or, how many times I've run this program in the background just to see those same glorious results :D. I think you can tell how excited I was throughout the process by the program's output:


Image

Screen2.png
Screen2.png (81.02 KiB) Viewed 13525 times

TODO:
  • Get tool chain up and running and making .hex's.
  • Add arbitrary .hex programming functionality to program, via PE command set.
  • Make MCU say, "Hello World!" over UART :).
Future TODO:
  • Install flash bootloader that allows for programming over UART or USB. (Hopefully not as hard as it sounds; I think Microchip provides one)
  • Get system clocked up to speed.
Who-Knows-if-it-will-get-done?:
Add video, sound, port Uzebox kernel, etc...

Would be very cool:
Integrate support for this JTAG hardware into some other open source JTAG software.




Notes and Gotchas for fellow builders:
  • Just by attempting this build you join a super-elite club and I really hope you do :). It would be super-awesome if someone besides me ends up building this!
  • The adapter boards can easily be found on ebay. Look up "tqfp" for the PIC board and you can't miss em. I have good experiences with an eBay store called thaishopetc. Get a few boards and chips; it took me two tries ;). IME, you shouldn't get chips on eBay.
  • Make sure you avoid the 0.4mm chips and boards. 0.5mm is plenty small enough to please the sickest masochist, LOL.
  • Don't get the same double-sided board as I did from eBay: the holes aren't big enough to allow headers to pass through :*(.
  • With this many pins, low insertion headers on the PIC breakout are absolutely crucial. I won't lie to you; it won't be fun (or cheap) finding them. You'll probably have to get something bigger and cut it down. Samtec low insertion headers can usually be identified by a two in the part number like so:
    SSW-XXX-2x-X-X. If you just want to be lazy and buy the perfect female headers from Samtec, you can use part number SSW-113-21-F-D. You'll need 4 of them, and the matching male headers, of course.
  • At this point in the design, the MCP2200 MUST be configured properly before trying to communicate with the PIC. You can do this with Microchip's provided utility. I believe failure to do so may result in one or both chips being fried. I made it really easy for you though; the only important setting is IO CONFIG, which NEEDS TO BE 00000001.
  • For the same reason, USBSSPND MUST NOT be enabled.
  • Leave all the check boxes in the MCP2200 configurator unchecked, for now. I have noticed that if I enable Tx/Rx LED's, GP5(TCK) is no longer controllable via the API. This is odd because GP5,6 & 7 all work as expected individually if set through the control utility, and Tx/Rx LED's (GP6 & 7) also behave as expected when enabled as such. I just noticed the same thing with USBCFG and GP4(TDO). p.s. Tx/Rx only applies to the UART anyway; nothing this program does will light them up.
  • Schematic is untested but the only real difference I know of is that my MCP2200 gets its 3.3v separately, from an ADP122. That's just the way my hardware evolved; only the large 3.3v LDO regulator should be needed to power both chips.
  • The code is meant to be easily configurable but the program has little in the way of error-checking right now. It seems to make the assumption that it was made alongside one single piece of hardware and the bugs in each were fixed in tandem. What could have given it that idea? ;)
  • If something looks wrong, it probably is, so let me know! I've got no damn clue what I'm doing here! :P
Okay, that was lots of text! If anything else needs to be said, I'll say it later.

Please check out the schematic, check out the code, leave comments and if you're feeling intrepid, build the hardware and run the program! :D


TLDR: I made a thing that hooks up to a pc and blinks!!!!! Oh, how it bliiinks! xD
Attachments
JTAG-you're-it - Aug 02 2012.zip
Schematic, settings, app & source
(245.38 KiB) Downloaded 562 times
Last edited by HardlyUnique on Sat Aug 18, 2012 6:36 am, edited 1 time in total.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: WIP console with PIC32MX & MCP2200

Post by uze6666 »

Great work, I sure can relate on the effort required to make it work so far! :) I'm curious to see what it can push graphically...waiting for the first demo... ;)

-Uze
HardlyUnique
Posts: 65
Joined: Tue Dec 08, 2009 7:44 pm

Re: WIP console with PIC32MX & MCP2200

Post by HardlyUnique »

uze6666 wrote:Great work, I sure can relate on the effort required to make it work so far! :)
Thanks! :)
I'm curious to see what it can push graphically...waiting for the first demo... ;)
You and me both! :D There's just a wee bit of work to be done first between here and there, as you well know! ;)


Oh, that reminds me! I haven't talked about what I'm using for a video processor yet! I'm going to bit-bang PCIe 2.0 and connect a geForce 8400 or maybe a GTS 440 (Fermi). It's going to be way faster than the Uzebox, for sure! 8-)


...
:P


Here's a little progress update:
I implemented some more PE commands, but they don't all seem to work properly, particularly the most important ones like PROGRAM and ROW_PROGRAM :*(. These things are really straightforward too, so I'm not sure where I'm going wrong. WORD_PROGRAM and READ both work. CHIP_ERASE returns a success acknowledgement but doesn't actually blank the chip.

...aaaaaaand you guys know what's great? I'm 99% sure that writing this message helped me suss it out. I'm pretty sure the problem was me mixing up the PE binaries. I was using the one for PIC32MX1/2XX. Doh!

Oh well, I have somewhere to be but expect developments soon! :D
HardlyUnique
Posts: 65
Joined: Tue Dec 08, 2009 7:44 pm

Re: WIP console with PIC32MX & MCP2200

Post by HardlyUnique »

I'm too excited to know what to say, so I'm testing the theory that a picture is worth a thousand words:

P1010018.JPG
P1010018.JPG (126.53 KiB) Viewed 13422 times
P1010019.JPG
P1010019.JPG (130.93 KiB) Viewed 13421 times
HardlyUnique
Posts: 65
Joined: Tue Dec 08, 2009 7:44 pm

Re: WIP console with PIC32MX & MCP2200

Post by HardlyUnique »

Hmmmmm :(

I wonder if no comments means there isn't much interest or that it wasn't very obvious what I was showing you in those last pictures.

I was trying to demonstrate that I had managed to get code compiled and transferred to the PIC32 that would flash an LED. That's why the MCP2200 was disconnected - to show you that the magic was being done by the PIC.

Anyways, I've made another milestone achievement and I won't be enigmatic about it: UART communications! Yup, I can already make this little chip say, "Hello, World!" with the best of them! In FACT, printf works too!! (but there's more overhead for printf)

LOL, I never thought I'd be excited about something as "primitive" as printf - embedded programming sure puts some perspective on things!!

Here, look (I would've embedded the video but that doesn't seem to work with youtu.be style addresses):
http://youtu.be/NesYv4fPphc

and please comment! :)
User avatar
DaveyPocket
Posts: 378
Joined: Sun Sep 14, 2008 8:33 pm
Contact:

Re: WIP console with PIC32MX & MCP2200

Post by DaveyPocket »

Very good progress! The forum has been quiet lately, many people are quite busy.

Anyway, you mentioned before about having this this bit-bang data to a GeForce 8400 graphics card? I'd like to see how that turns out. Those cards a very powerful relative to what we're doing :lol:
User avatar
paul
Posts: 457
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Re: WIP console with PIC32MX & MCP2200

Post by paul »

I wouldn't let a lack of comments discourage you. Usually these types of threads hum along with the original poster replying to themselves as people lurk and enjoy the progress updates.

If you do manage to follow through on everything planned, then I'm sure you'll get a lot more overt interest. But so many of these projects are never completed, and after a while you grow cynical as to whether you should bother showing too much interest until it's obvious there's a finisher working on it. But I'm enjoying reading along for now, so thanks for posting :)
HardlyUnique
Posts: 65
Joined: Tue Dec 08, 2009 7:44 pm

Re: WIP console with PIC32MX & MCP2200

Post by HardlyUnique »

Thanks for the encouragement, guys! I guess I can't complain about a lack of comments; I've done my fair share of lurking / being absent around here :D.
paul wrote:... and after a while you grow cynical as to whether you should bother showing too much interest until it's obvious there's a finisher working on it. But I'm enjoying reading along for now, so thanks for posting :)
That's a good point and to be fair, I never promised to finish anything. :P In fact, I only set out to get the chip soldered and talking to the PC and I wasn't expecting it to happen this fast.

However, I'm totally hooked! So, I don't see myself getting tired of the project anytime soon, either.


Here's a small update:
I now understand and can set the config words, the trickiest part of them being their descending order in memory ( :evil: ). I can run the chip at full speed off the internal oscillator (80 mhz) and can control the baud-rate generator. Off of the internal oscillator, I can get the UART up to 115kbaud, about 14.4KBps, without transmission errors.

I will probably attach a 14.31818 Mhz crystal soon and see if that lets me push the baud any higher. I can run the system at 76.36 Mhz off of that, as well as generate the clock signal for an AD723. Not that I've decided for sure on a video chip, yet.

This system is probably fast enough to handle color-generation directly, a la the RBOX32, however, the system would have to overcome a technical incompatibility: whenever its designer tries to understand NTSC color-modulation, his head explodes into a bloody, brainy mess.


I've started work on getting a bootloader working. Really, that just means I'm making the one that Microchip provides work outside of their devkits.

So far, I can configure my projects properly so that the bootloader is all in boot flash and another project is in main flash. I have the "bootloader" working so that, when sent the right input over the UART from the pc (for now, just a "g" character as in "go"), the loader jumps to the main app. Right now, the main app needs to be flashed in advance. Obviously, getting the bootloader to do the flashing is the next step.

It will be another major milestone when it's working too; it presently takes at least 13 minutes to bit-bang into place the PE followed by even the simplest programs - :shock: . That needs to get down to seconds if I'm going to make any progress actually programming the thing!


So, here's my latest TODO list:
  • Get UART bootloader working
  • Add 14.31818 Mhz crystal and see if the UART can go any faster
  • Possibly, get USB (on chip) and the USB bootloader working
Once I have things set up so I don't have to wait forever and a day for the chip to program, I've decided on something else to do with this little system: a little sidetrack before I get all kernel-driven-gaming-console with it.

Before I even started this project, I found myself lamenting that it would likely never be the system it was "meant to be." I.e. it was more likely to be used as a developers' toy and hobby than as an actual gaming system. After all, how can there be many surprises in a game you have to make and test yourself?

Well, I don't yet have display, or sound, or even input and output outside of a terminal, aside from one LED, but what I DO have is input and output inside of a terminal, just like a really, really old computer... You see where I'm going with this?...

TL;DR: After I get a bootloader programming the chip quickly, I'm going to either port Frotz or implement my own Z-machine and give the Zork series a checking out. Being a graphics-baby of the 80's, I never got into text adventures; it should be fun! :D
HardlyUnique
Posts: 65
Joined: Tue Dec 08, 2009 7:44 pm

Re: WIP console with PIC32MX & MCP2200

Post by HardlyUnique »

UART bootloader is working! :D

I can now use Microchip's PC bootloader application to connect to the device, erase-program-verify and run the program! Most of the time is taken up by the erase, which lasts about 3 seconds, and the actual flashing of a ~5k hello world app takes about half a second. 8-)

I'm finding it's a little inconvenient for the UART to be used for both the bootloader and for input/output - you have to keep disconnecting and reconnecting and closing and opening the same programs. So, next on my agenda will be to get the USB bootloader working. After that, I just need to take Microchip's PC program source and turn it into a command-line app that will perform a reset-erase-flash-verify-run all in one go.

Then, I can add that program to a post-build command and go from clicking "Build" to running my code in a few measly seconds, with no extra interaction! 8-)
HardlyUnique
Posts: 65
Joined: Tue Dec 08, 2009 7:44 pm

Re: WIP console with PIC32MX & MCP2200

Post by HardlyUnique »

More progress and hitting the first big hurdle:

So, I have a lot of things working that weren't working before but let me get to the bad news first. Remember when I said,
HardlyUnique wrote:chip needs built-in USB capability. USB functionality can't require a specific clock speed. (Built-in Ethernet is also a plus)
?

Well, yeah, I screwed up. :oops: It turns out that while you can select the PIC's internal oscillator as a source for the USB PLL, it is only good enough for wake up; the internal oscillator isn't accurate enough for any actual USB operation. :cry: While it's my mistake, I partly blame Microchip's habit of only giving you the barest of info in the datasheet and referring you to about 40 different pdf's, many of which refer you back to the datasheet! :x

Ok, so, here's the givens that I (am pretty sure I) need to work with:
  • I want to create the optimum environment for fast, fun development. That means it shouldn't take more than a few seconds to change a program and see the results running on the device.
  • Also, it needs to be extremely easy to get input/output to and from the device as it's running, for development purposes. I.e., A PuTTY session should be able to stay open throughout development.
  • Given the above, a USB bootloader is imperative.
  • For USB operation, the system clock input must be either 4, 8, 12, 16, 20, 24, 40 or 48 Mhz.
  • For optimal video quality, the system clock should be some multiple of the video encoder clock.
  • Most NTSC encoders require either a 14.31818 or 27 Mhz clock.
  • This PIC MCU only has one high-speed clock input.
Sooooo, with all of the above it kind of seems like I'm boned, and I might well be! As I see it, my best and only hope lies in coming up with some way to switch the clock input dynamically. I really am a bit out of my league here, I don't even know if that's possible! I know one thing that's nice about these chips is that you can change their clock settings dynamically.

I also DO know that Digikey sells these little 4-pin oscillator packages that say their output pins can be tri-stated and that they can drive the 50pF load that the datasheet specs on every GPIO pin, including OSC1, and they work off of 3.3v. Seems good to me! So I made a schematic of how they might work in-circuit:
oscillators.png
oscillators.png (61.52 KiB) Viewed 13162 times
My thinking is that normal operation would look something like this:

(0. On reset, GPIOs should be tri-stated; oscillator1 should be enabled and oscillator2 disabled.)
1. System boots and bootloader uses oscillator1 for USB operation.
2. Bootloader loads and launches game.
3. Game switches clock to run off of internal oscillator.
4. Game disables oscillator1.
5. Game enables oscillator2.
6. Game switches from internal oscillator to oscillator2, enables the video encoder and goes on it's merry way :D

Do you guys think this will work? I have 0 experience using one of these 4-pin oscillator modules and haven't even been able to find much info on using them; surprising considering how many Digikey sells. I looked through lots of datasheets but they don't have much in the way of a typical application; they just show that you should have a bypass cap and not exceed the output's load capacitance. Hopefully, that's all I need to know!!

The most damning thing about this, even if it works, is that USB and video functionality won't be available at the same time. I doubt anybody will be bothered by that. However, for the same reasons, the built-in ethernet MAC and video can't be used at the same time either. That's a little bit worse but not really a big deal, though. I don't see this system having a lot of multiplayer potential. Besides, you can still make a PC tunnel application using the UART if you're really determined. Come to think of it, that's really the way to go anyways!


Well, that's the big hurdle out of the way. Let me talk about what is working well, now. :)

I added a 20Mhz crystal and have the USB bootloader working. I also integrated Microchip's PC-firmware-application source into my own command-line app that will erase and program the device, then launch the application, all in one go. I set this up as a post-build command for all my projects, and as a pre-build command, I have a little app that just resets the device (back to the bootloader).

This makes development REALLY nice, because you just press the "Build" button and that's ALL you have to do - your code is running seconds later! All without shelling out the $$ for a proprietary devkit! :ugeek: :mrgreen: 8-)

Here's a picture of the output in MPLABX: (kinda boring, I know. There's a video of the process in action at the end of this post.)
mplab screen.png
mplab screen.png (31.79 KiB) Viewed 13150 times

Also, I got really tired of just having a bright, blinking LED as my only output. Every time I would write the code to make it blink I would go, "Oh, yeah," and be disappointed. That's because for some strange reason, I expected it to "glow" - to come on and off slowly and gracefully - but of course it never does, the hardware only supports on or off!

Well, I finally got so tired of the unimaginative blinking that I said to myself, "Hey, wait a minute, this is my hardware design. I can make this LED blink any way I damn-well please! :mrgreen:

So, I made this little thing. Apologies for the crude schematic but it should be enough that you get the idea:
Glow_Schematic.png
Glow_Schematic.png (41.77 KiB) Viewed 13156 times
There's a 4-bit DAC for the LEDs and you can change between green and blue. I might add red or more colors in the future. :geek:


In other news, I've started porting Frotz. I can now make it compile without errors. Woohoo, lol. But, it doesn't do anything, yet, aside from telling you were it breaks.

I need to figure out how to add the story file to my .hex, then, I need to write my own implementations of fopen, fread and fseek. Fun stuff. :roll:
After that, there's probably more that will need to be done too. Without the data file, Frotz takes up a surprising-third of the available 512k flash.
With this, it takes a rather-disappointing 17 seconds to flash Frotz and no data file. Which leads me to my next project: Improving the bootloader.

My theory is that when you make a small change to a very large program, each and every page of flash shouldn't be changing. At the very least, you can align data files at the end of flash and guarantee that they won't change. So, I need to upgrade the bootloader and transfer application so that they will compare the CRC of each page in flash and only erase and flash the pages that have changed. I'm hoping this will bring me back into the target zone of a few seconds of overhead during each development cycle. That's very important to me!

Here's my updated TODO list, not necessarily in order:
  • Upgrade bootloader
  • Finish porting Frotz
  • See if I can't get this clock situation sorted out!
TL;DR: Check out this latest video of my system. It glows now! The glowing compels you to comment :twisted: ....
http://youtu.be/3axiOW8zu9M
Post Reply