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.