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

Baby blankets

We have a tradition:

whenever someone is about to have a baby,

my wife makes a baby blanket.

She has made 10 or so for various friends.

Well my brother and sister-in-law are about to having a bouncing baby "?" of their own. My wife thought that I should make it myself. Since I have not sewn anything in about 20 years, I was reluctant.

After 3 hours, a lot of coaching, and little help, I proudly present, my first baby blanket:

My brother and SIL have decorated the nursery with a safari theme; therefore, we chose a cotton print to match. We went with a soft yellow flannel backing.

Now I just have to pack and mail it before the kid goes off to college. (Procrastination runs in my family)

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!

Vista Virtual Store

Okay,

I just found something out: Windows Vista is stubborn about letting you save files in 

     C:\Program Files\...

Instead, it recreates the data files and directory structure in 

     C:\users\[USER]\app_data\local\virtual store\Program Files\...

Yes, Vista recreates a copy of all the files that you use from Program Files and hides it in some backwoods directory.

Vista then merges the program files in C:\Program Files\... and the data files in C:\...\Virtual Store\Program Files\... when you run an application.

According to the file browser in the application, the data files should be in C:\Program Files\...

Vista goes through great effort to conceal the fact that the data and program are in separate locations.

That's fine and dandy, but I couldn't find the .hex file that I just compiled (and neither could the loader)

Partial solution:

I ran the application with Run as Administrator and Win XP SP2 Compatibility Mode, and it appears to be working correctly now.

Well, that is 3 nights of my life I won't get back.

Bad PIC, bad!

I have spent several nights trying to bring the PICKit Starter Kit back to life.  

First, there are two install disks:

   PICKit 1 Flash Starter Kit - 

            This includes the .hex loader and example projects

   MPLAB IDE - 

            This includes an IDE and the PIC C Lite compiler

I only knew about the MPLAB IDE disk. Thus things weren't working right when I tried to program a chip.  Finally found the other disk (buried in my closet) and reinstalled everything.

I installed one of my PIC12F675 (8-pin with 3 ADCs) chips in the Stater kit.  Loaded a precompiled .hex onto the board.  Ooh, look pretty lights. I was happy for the night.

The next day, I picked up where I left off.  I tried to compile and load one of the example programs.  The loader said that the write was successful,  and even read out the contents to verify correct saving.  

But nothing happened. Ug. I tried over and over. But no luck!?

Wife told me to try again in the morning and play Mario Kart Wii instead. Fine.

This morning, I pulled out the other two PICs that I have, another PIC12F675 and PIC16F630 (14-pin, same family).  I tried the load/verify with them.

TaDa! LEDs start blinking away. They both worked.  I tried the misbehaving PIC again, still nothing.  I guess I killed it that first night.  Oh well.

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!

Fixing my Archos

Well, I was jamming at work, and my Archos slipped off the desk and "crash" hit the floor.

It got to the end of the song, and a message box appears saying

File corrupted

Then I got the dreaded error 

Recovery Code 2, System is damaged. 

Would you like to recover it? 

No, 

repair, 

Format Disk

No and repair didn't do anything. I was afraid of   Format Disk.

After a quick internet hunt, I found out this was a common problem. D'oh! With a common fix!!!

Apparently, the harddrive becomes disconnected by just a little bit.  All you have to do is open it up and push in the harddrive cable.

I tried it, it worked!

Here is my journey:

Backside of the Archos: battery is on the left, harddrive is on the right.

To remove the harddrive, you need to remove 6 tiny screws.

4 on the end by the LEDs

To get the other 2, remove the battery 

The harddrive outer case will come off with a little bit of encouragement.

You can peel back the harddrive to see the flex cable.

Here is where I had a problem.  There are 2 floating nut plates (holding the 4 screws by the LEDs).  One got wedged out of place.  I had to remove the screws holding the motherboard to the case AND separate the LCD from the case.  Royal pain in the tookis! Be careful.

Push the connectors back in.  Note, they looked like they were still connect to me.  If I hadn't read that was the fix, I wouldn't have tried it.

Hope it works for you.