September 8

I finally have the JTAGTab code executing from start to finish. I fixed the runtime errors, most of which were caused by a mix-up with the endpoints for sendMultiple. I didn’t notice that two of the addresses had been changed, so I was trying to send information the wrong direction. This was quick and easy to fix, and now it is running entirely.

We had the meeting with Tektronix and learned to use the new oscilloscopes. Very helpful.

Now I am working on verifying that the instructions are reaching the CPLD. I know as fact that the SVF file is parsing correctly, and I would guess that if there were flaws in the rest of the code it would have shown up with the first 20 thousand instructions. So it is probably an error in the communication between the PC-side and the board-side of everything. I found a few places where I left out sendSessionCommand calls. I’ll fix those as soon as possible but I would be surprised if that accounted for many of our problems.

Chris asked me to verify the device ID. I got the SVF file to do so, but now I don’t really know where to go with it. The code that Michael Spray wrote doesn’t verify this, so I have nothing to go on. His other idea was to print out the data received by getMultiple and compare it to find the device ID. I will start on this once I add in the sendSessionCommands I overlooked before.

RIGHT NOW:

I am confident that the correct information is being entered into the sendMultiple commands.  What I don’t know is whether there is some kind of initialization that has to be called to set up the cpld for communication.  I think that the problems right now are not PC-side.  The changes that need to be made probably involve calling certain parameters to the scanRegister, sendSessionCommand, and runRTUNTEST functions (these are the only three that directly communicate with the board).  Since I haven’t worked on the board-side code, I don’t know what to make of these problems.

Chris: I’m sorry that my code is poorly commented.  Most of it closely matches the structure of Michael SPray’s code, so you can look to that for comments, but some of the hacks and fixes are unique to mine.  When I return I will comment it better.  Thanks.

September 7

First off I continued fixing the runtime errors with the JTAGTab.c file.  Nothing too extremely big for a while- just mixed up addresses and pointers.  Then I came across a problem where the values in the sm_hts and sm_hts_lengths structures seemed to change for no reason, and were screwing stuff up.  I decided that it was a waste for the sm_hts to be a pointer to pointers to characters, and for the sm_hts_lengths to be a pointer to integers.  I just hardcoded the sm_hts as an array of 24 character pointers and the sm_hts_lengths as an array of 24 integers (no pointers = sweet).  This made it easier to solve the runtime errors.

I came across a very helpful document titled “Using Serial Vector Format Files to Program XC9500/XL/XV Devices In-
System”, which was most informative.  See http://www.xilinx.com/bvdocs/appnotes/xapp067.pdf .  I was correct in my assumption that these SVF files don’t use all the commands we are preparing for- and for the commands we do need, they use only a small fraction of the variations in format.  So a lot of the code won’t be used for this situation, but if we need it in the future in is already configured.

Now it seems that now my problems aren’t with the PC-side code, but rather with meshing with the board-side.  I have verified that I am sending the correct information to the sendMultiple command yet still the usb_interrupt functions fail on occasion.  Hopefully it is just a matter of initializing something, but I will have to talk to Jace because he dealt with those functions already.

September 5

I went through by hand and verified that the SVFParser file is outputting exactly what I want it to.  It was, and I checked through every variation of input that we are using in the toplevel.svf file I was given.  This particular file doesn’t have any piomap->namedir, piomap->data, or runtest->sck commands, but other than those options everything worked precisely as intended.  Now I just need to figure out how to use sendMultiple to put this information on the DSP.

I spent my lunch hour fixing a mistake that my retarded former landlord made.  He mailed the security deposit refund check to the address that we moved away from, which is a major problem because none of us live there to receive it.  So I had to go convince them that I didn’t have the check and get a second one.  It really sucked.

I tracked down the problem with JTAGTab.c to a command in the constructPackets function.  It accesses NULL memory, but instead of having error protection it just fails the program.  So I need to read through Michael Spray’s code and figure out whether that is the correct interpretation of what is happening.  Also, I am about 90% sure that he has an error in the frequency command.  He changes a value in the jtagTab structure to the value stored in the 1st index of the command list, but I think that address will be NULL in all cases.  I will investigate this as well.

September 4

Came in this morning and worked on the jtagTab some more.  Got a progress bar working, so that it shows the progress of the instructions on a 0-20 scale for the 19056 instructions.  But there is a significant slowdown as the progress goes on… probably because each iteration of the for loop starts at the head and NEXTs to the proper node.  That is retarded.  Why not just NEXT one at a time?

Went to Tektronix.  That was cool, except the tour was oriented more towards industrial engineers and a lot of it was over my head.   Got back around 6:30.

Came back tonight to work on jtagTab.  Fixed that stupid problem with the time- now don’t traverse the entire list every iteration.   Tried to fix the runtime error on moveState(), but my solution didn’t appear to work.  I’ll try more again tomorrow morning.

September 3

Labor Day – no work scheduled.

Came in as soon as I got back from Portland.  Worked on the JTAGTab.c file, and made significant progress.  Had to be more intelligent about freeing up dynamic memory.  Nothing especially tricky, but solved the problem.  Now the code runs through all of the 19096 lines of instructions, but there is a runtime error in the code after the big for loop, when the state is set to RESET.  It seems that the error occurs in sendMultiple, which is weird.  More later.

August 31

Highlights:

-201 boards got here.  Connections are all good.  Figured out a little bit about what can be fixed, what needs a jumper.  It works well and now students don’t need a protoboard (which is good because we don’t give them one).

-JTAGTab file processes 105 commands correctly before failing.  I think it has to do with how I am allocating and copying memory to the piece variable.  I didn’t have much of an opportunity to test it because Chris and Jace made a lot of progress and needed the board most of the afternoon.

-USB datalogger holds 260 thousand samples.  Now the limitation isn’t the datalogge memory, but the size of the Excel spreadsheet.

-Found an old version of linux for the repaired computer.  Tom tried to install it for me, but something went wrong and I think he is going to look for a RedHat version before next week.

-Practiced slideshow for tektronix.

August 30

Paintball.

And another test of the ENGR 201 civil engineering project.  This time a slow burning torch in Don’s backyard.  The data wasn’t nearly as interesting, especially because the torch went out about 10 minutes in.  But the data made sense and was observable, which was the important part.

I noticed that the datalogger was holding a lot more than 5000 samples, the number listed in the old lab manuals as the maximum number.  I will have to run the datalogger at its highest frequency until it fails to find the new maximum sample size.

August 29

This morning I spent some time working out runtime errors for the JTAGTab file.  I worked out the first few problems, but right before lunch I got stuck on one.  It seems that the chopFront(…) function doesn’t want to write over the curInstName string, when it is accessed in the JTAGTab.c file.  I do not understand this because up to this point it has done the same thing roughly 20 thousand times in the SVFParser.c file, and I don’t see what is different about this function call.  I will try another approach to get around the problem.

During my lunch hour, Tom and I found network cards at the OSUsed store.  We got two in case one doesn’t work.  I’m going to put one into the old Windows95 machine that I brought from home and got working again.  This is the next step in our goal to get Linux running on it.

After lunch I tested out the ENGR 201 lab involving burnthrough time on  sheet rock.  I set everything up and burned it with a thermistor between two sheets and another on the backside.  The data was very good.  It shows a solid increase in temperature, a difference in heat transfer between the two thermistors, and a time delay between the two.  Also, it seems that the middle sensor remained functional much longer than we were expecting, though it burned out in the end.  I set up another apparatus to test tomorrow.

August 28

I made a lot of progress today.  I converted all of the important sections of JTAGTab.cpp and JTAGTab.h into C, which included about 1000 of the 2000+ lines from Michael Spray’s version.  The rest was devoted to the visual section of the program, which we are not using, so I cut it out.  After everything was converted into C I began compiling it and fixing the compile-time errors.  Most were just simple mistakes like dereferencing something incorrectly or misspellings.

The biggest problem was with an incomplete structure definition.  The USB_comm structure that was an element of the JTAGTab structure was at first declared incorrectly, such that it looked like an incomplete definition for the entire structure.  This cause an error every time that JTAGTab structures were dereferenced.  I fixed that, but then a problem arose because Jace had defined the USB_comm structure in the .c file rather than the header.  Again, my structure had an incomplete definition.  I asked him about it and apparently there would be problems if I tried to declare another one of those structures.  So instead I passed the one he defined into my initialization function, and then pointed the USB_comm* element of the JTAGTab at it.  This fixed the compiling error.

With all of the compiling errors fixed, I now just need to start running the code and work out runtime errors.  I will start that either later tonight or tomorrow morning.

August 27

Lots of progress on the JTAGTab files. Most of it is pretty easy, because the functions convert from C++ to C and it is only the syntax and variable names that must be changed. I’m through the runStateMachine function. Only the “do” statements at the end of the list of options call other functions. So I have moved on to the scanRegister function, which calls constructPackets early on in the execution. So now I am nearly finished with constructPackets… and I figure that this will be a function that is called repeatedly in other places in the code as well.

All in all, progress is good. I have had no major problems. It is just a pain to go through so many lines of code and learn what is going on with it.