68HC11 Bootstrap mode

In 1999, I received a Super T-Comp; a 68HC11 based microcontroller board that is similar to the Handyboard.

While working with it I released the sacred smoke. I blew out 3 chips.

I repaired the damage, but I couldn't get it to work right again. So it sat in my toybox waiting for me to try again.

In 2010, I am taking a class in embedded systems; so it is time to try again.

Inspecting the board again, I found a bad chip that I missed; a NAND gate driving the external RAM. I will fix that this week.

Regardless I should be able to talk to T-Comp in Bootstrap mode. PCBug11 is the original tool for talking to 68HC11. It doesn't run on modern (fast) computers.

So I tried TeraTerm terminal software. Finally did established communication this morning.

68HC11 has 4 modes:

Single Chip: no external RAM

Expanded: external RAM

Bootstrap: single chip, using bootstrap loader in ROM

Test: Uh? don't know

Bootstrap Mode

Hold ModA and ModB low

Toggle Reset

Release ModA and ModB

within a second

send a byte over SCI (serial port) at 1200 Baud, No parity, 8 bits, 1 stop bit.

It is now ready to accept a 256 byte program. 68HC11 will echo bytes. Once it recieves 256 bytes, the program counter resets to $0000 and starts to run the loaded program. In theory.

Hacking the PSP

Everyone has hacked the PSP to put non-Sony firmware on.

You can still run your games, AND install homebrew stuff.

This was the original goal when I bought my PSP. I got distracted by actually playing games.

I finally got around to doing it.

I have the GOW edition PSP slim, it had Sony firmware V3.94 installed.

I sort of followed the instructions that I found here

http://forums.pspslimhacks.com/tutorials/5-guide-psp-custom-firmware-reference-guide-minor-update.html

Things you need:

Pandora Battery - modified battery to allow access to the PSP bootstrap mode,

I borrowed one

Sony memory stick - 1Gb stick works fine

PSP Grader v0.008 - installs firmware, I got it here

http://pspslimhacks.com/psp-grader-v008/

modified PSP firmware - overwrites the Sony firmware, I got it here

http://www.psp-hacks.com/file/1568

Connect the PSP to your PC; start USB mode.

Copy the Sony memory stick to PC

Format the Sony memory stick

Start PSP Grader

Locate the eboot.pbp in the PSP_500_FW.zip

Download file to stick

Disconnect and power off the PSP

Remove battery

Insert memory stick (if you haven't)

Hold down the L button

Insert the Pandora Battery (often PSP auto-starts) and start PSP

Back up NAND

Restart PSP

Install 5.00 M33 (or similar)

Done.

I have spent all my time playing a Magic the Gathering Homebrew (Wagic) in stead of programming anything.

Trouble producing the HEX file, redux

I busted out the system after a few week (okay, a month) of letting it collect dust.

I tried writing and compiling a simple modification to the last code...

and no luck?

I thought I fixed this!?

After much digging around (and some unpleasant grumbling) I found out that the Hi Tech PIC compiler was installed in "evaluation mode" and that license expired.

I reinstalled and things worked okay. But I am sure it reinstalled in "evaluation mode" again.

Ug

Trouble producing the HEX file

I wanted to compile and load a .hex file onto the PIC.

Powered up MPLAB IDE, modified the example source code:

     blink LED 1 instead of LED 0.

I finally got the compiler to work (I was having many issues, including the Virtual Store).

So, let's compile and load the .hex file... 

    Build Succeded!

but a message box pops up saying it couldn't load the .hex file.

Odd, but I can just do it manually.

wait, there is no .hex file!

I poured through the compiler options.  There was an option called FAKELOCAL...

Gee, that is suspicous, let's look there.

Sure enough, if I go to the HI-TECH Linker in Project->Build Options of the MPLAB IDE, there is a checkbox for Produce MPLAB debugging info.  Uncheck that and the FAKELOCAL goes away.

Viola, on the next compile, a .hex file appears!

Loading firmware on the Surveyor

I had some success on the Surveyor this week.

I uploaded my own firmware.  

The firmware that comes with the camera board is impressive. It has "commandline" interpreter, PicoC script interpreter, Blob detection, and Edge detection built in.  But I needed to get blob centroids and a way to turn off the automatic color balance (which kept changing the colors of my green target to a pink target).  

I downloaded the latest firmware; this includes:

   source code

   srv1.ldr.115K 

         (firmware configured for 115Kbps UART communication)

   srv1.ldr.250K 

         (firmware configured for 232Kbps UART comm 

          using Matchport radio)

I figured that I should try to load the working, precompiled 115K firmware onto the board, before trying my own.  

The user's forum described the process for loading the new firmware; seemed simple enough.

However, I can't seem to get it to load right.    So now I erased perfectly good firmware off of my board, and couldn't get anything back on. D'oh!

Eventually, I found 2 pieces of information:

1) The Windows firmware loader that comes with Blackfin compiler, ldr.exe, only works with network connections.  Oh. That was annoying, cuz it looked like ldr.exe was connecting properly. To connect using serial comm in Windows, you need ldrviewer.exe. 

 

2) The new firmware is larger than 48K, this requires a two-stage process to put part in the L1 cache (very fast, but only 48K) and rest in SDRAM (slower, but bigger.)  So I have to download an old copy of the firmware that is 42K.  You load this into the L1 cache first.  Then you can use Xmodem to load the new big firmware into the L1 & SDRAM. 

There was a really good post to lay this out step by step.

http://www.surveyor.com/cgi-bin/yabb2/YaBB.pl?num=1205225367/28#28

Relief, now I felt good about compiling my own code and loading it up.

Make went okay, then I followed the process for loading the code.

I cycle power and, ... burp. A strange character shows up instead of the version number, then everything locks up.

I retried several times to no avail.  I asked for help on the forum and all that I got was "it works for me" ug.  

As it happens, I have been dreaming about this project all week with truly tortured sleep. So when I say the answer came to me in a dream, I think I earned it.   As I have said before, everyone assumes that you purchased the Matchport radio.  The radio uses 232Kbps serial communication.  I just assumed that the firmware would default to 115K.  So I go hunting around the source code and, tada:

   baud = 232000;

   \\ baud = 115200;

Duh! Everything HAD compiled and loaded right, but the camera was just talking too fast for hyperterm  to understand.

Okay, I can now load my custom firmware code, whoop!

PICKit 1 Flash Starter Kit

Okay, so a few years back I bought the PICKit 1 Flash Starter Kit for 8-bit PIC programming.

Usb interface.  Programs 8 and 14-pin PICs with flash.  Now of course the 32-bit version is even cheaper, but it is still a neat board.  www.microchip.com

I had used it to build an antenna tuner.  I used Sony stereo remote to drive a motor back and forth; this would turn the VHF ring on my rabbit ears. It didn't work well, but it was fun to try.

I need to get back to basics so I will be trying some simple circuits:

Sonar

LEDs

Optical encoders

H-bridge

Servos

POV clock

anything else to justify my $50 purchase so many years back.

Surveyor SRV1 Camera

At work, we purchased 2 SRV1 Blackfin Surveyor camera boards for $200 each.

http://www.surveyor.com

Basically small cameras attached to a powerful processing board. The Blackfin board is designed as a robot controller with built in image processing. In addition to PWM drivers, I think the default firmware does edge detection, blob tracking and centroid.

The documentation is sparse. The setup assumes that you bought the wireless radio, and robot body. But the users forum is great. Friendly folks of different experience levels. And the Administrator/Company owner asnwers tech support at night, same day!

No quibbles there!

Actually, it is supposed to work right out of the box: there is a java console to talk to the camera and transfer images (very slowly).

Well, mine didn't.

I needed to setup a serial connection for initial communication. I didn't have a 3.3V power supply (SRV1 is 3.3V processor).

What I had was

Sparkfun RS232 shifter (RS 232 to TTL, you supply the voltage)

Sparkfun FDTI Usb-RS232 with 3.3V output.

First thought was connect the FDTI Usb-RS232 to RS232 shifter to SRV1, and use 3.3V from FDTI to power the RS232 shifter and SRV1.

Okay, that didn't work. I figured I had screwed up the TX-RX pins somewhere amongst the multiple chips.

Second thought was connect the RS232 shifter to SRV1 (plain jane serial connection) and use the 3.3V from FDTI to power the RS232 shifter and SRV1.

That didn't work either. There are 3 LEDs on the SRV1:

LED 1 (yellow) RX

LED 2 (yellow) TX

LED 3 (red) Power

Boot sequence should be all three, then just 2 and 3.

Only power came on. Quick check showed that the supply voltage dropped to 2.9V

The FTDI Usb-RS232 3.3V couldn't supply enough current.

Well, I thought that I read you could pick off the unregulated battery supply to power it.

I had a 5V powered breadboard, so I tried that.

Oh, wow, all 3 LEDs, then just 2 and 3!

I connected using SRV1 java console, and I got an image! wait, that isn't right?

The image was mostly covered in black/green/pink rows.

I assumed that there was a connection problem in my circuit, so I chewed on that for a while. Finally I signed up for the Users Forum and asked for help.

First question: Are you using 3.3V?

Ug, so I borrowed a variable power supply and dialed in 3.3V. A perfect picture appeared!

Apparently, the blackfin won't boot with less than 3.0V AND the camera gets noisy (green rows) at more than 4.0V.

So now I can begin trying to get the camera system to do real work!