Printf has just entirely failed to do anything

[esquared]

Originally Posted by Mark McLeod

Sorry, we've been racing robots all night. They're having a pushing contest now.

Probably need to attach or email your whole project to look at.
It's hard to guess what serial port resource conflict you might have. There are too many answers.

Definitely zip up the project, there are a number of people out here on "the internets" who will take a look and give you a hand. Not being able to debug over the serial port leaves you with few options. The "Red Light of Doom" is typically caused by the same things that would cause a Windows-type program to either crash, or it went into an infinite/extremely long loop somewhere. The infinite/long loop would be the first thing I'd carefully check for in your code, it's easier to do than you'd think.

If you are indeed the lone programmer for your team (poor guy ) you might want to force some code versioning on yourself. Things like CVS or SVN (check out wikipedia or google it yourself) CAN AND WILL SAVE YOUR BACON! It'll allow you to easily step back in time before you screwed something up, and will also provide an easier time of multiple people working on the project at once. This way you can try training an interested freshman without fear of him making changes you can't get rid of when your team leader asks you "is autonomous mode done yet?" It takes some work to understand, but I promise (and every other user of some code versioning system will promise) it will be worth the effort.

--Eric

[B.Johnston]

I had the same sort of occurrence myself this week as I was trying to program one of the 2005 units.

Since you haven't mentioned which controller you're using this may not work.

If you have a 2005 CPU it's likely using a 8520 pic, which needs the following environment changes in mplab:

From the Configure >> Select Device... menu choose "PIC18F8520"
as the pic type

In your project use the "FRC_library.lib" for the 8520

(mine is named FRC_library_8520.lib) -To keep my sanity I
renamed it in the same
fashion as last years revised
libraries and linkers were.

Also In your project use the "18F8520.lkr" for the 8520

NOW the last ingredient for success in restoring printf's (in my case anyway)

Load the FRC_MASTER_V12.BIN and reload your first compiled code
(before all of your changes)

If you're using a pre 2006 CPU it's probably not been loaded with a FRC_MASTER_V12.BIN but an older version.

I'm just guessing (since it's now gone) but ours was probably using the V11 master code as distributed in April 2005.

Once the master code was updated my printf's worked fine (no more IFI> terminal freeze ups)

[JBotAlan]

OK, the code that is causing me problems is posted:

http://jbotalan.frih.net/07_code.zip

No printfs work anywhere.

I'm re-writing from the default user code. It will make for cleaner code. I would be interested in finding out why the heck this broke.

I'm going to try CVS.

JBot

[esquared]

Originally Posted by JBotAlan

OK, the code that is causing me problems is posted:

http://jbotalan.frih.net/07_code.zip

No printfs work anywhere.

I'm re-writing from the default user code. It will make for cleaner code. I would be interested in finding out why the heck this broke.

I'm going to try CVS.

JBot

Could you add the following to timer_handler.c in the InitializeTimer() function?

PIE1bits.TMR1IE = 0;

Since you don't have an interrupt handler for that timer, but you start it, it is wise to make sure it's set to not create an interrupt. It might start out that way by default, but this is much safer. An interrupt that is generated but not handled can do very bizarre things.

If i understand your original post correctly, it stopped working when you moved the function calls into your abstraction files?

I noticed you did not call "Initialize_Camera()" in your abstraction file (or anywhere in your project). Try adding that to user_routines.c in the User_Initialization() function.

Let me know if any of these work.
-Eric

[JBotAlan]

I'll be sure to let you know if these work. I won't be able to check until we get back (on the 4th I think). It's nice to know someone cares enough to pull down someone else's code to look at it. I wouldn't have been as generous before FIRST...

Thanks,
JBot

EDIT: I was under the impression that Camera_Handler() in camera.c was supposed to be calling Initialize_Camera(), and it is as far as I know. I can call it manually, but depending on the flags set in camera.c, it does get called if camera comms aren't working. Correct me if I'm wrong...

[B.Johnston]

Matt,

Sorry for leaving you confused.

The last step for success (in my eliminating the IFI> prompt freeze up while adding in printf's for my chosen variables) WAS the loading of the MASTER_V12.BIN from the 2006 default code.

You are absolutely correct when you mention that there is no explicit documentation of whether it's appropriate to try this.

But where is your sense of adventure.

The fact that IFI was doing FRC controller processor upgrades from ver 8520PICS to 8722PICS,

and Kevin Watson was releasing all kinds of code with instructions on how to load user programs written as enhancements for the 2006 base code onto 2005 processors.

Surely, if it were fatal to the processor somebody would have noticed by now that loading the MASTER_V12.BIN shouldnt be done on a 2005 controller.

Anyway it works, my 2005 controller is happily running MASTER_V12.BIN and both the FRC Default code and OUR 1114-1503-1680 Common base code that were teaching our programmers with.

Perhaps I should have actually read the IFI site for instructions on how to confirm which Master code we were running before I scrapped it, but I did save the bin file for posterity using device reader.

The only guessing going on was if it was v 10 or v11 not whether or not I fixed the freeze up at the IFI> stage.

Bruce

PS Jacob, I looked at your environment (8722PIC, lib & lkr) and you don't have the same printf freeze issue I had.

[JBotAlan]

Originally Posted by 1680Bruce

But where is your sense of adventure.
...
Surely, if it were fatal to the processor somebody would have noticed by now that loading the MASTER_V12.BIN shouldnt be done on a 2005 controller.

Hmm. I'm glad someone else did this experimentation. It would be an interesting experience, to say the least, describing to our team leader exactly why the most expensive component of the robot has become a paperweight.

Originally Posted by 1680Bruce

PS Jacob, I looked at your environment (8722PIC, lib & lkr) and you don't have the same printf freeze issue I had.

Thanks for trying. I really appreciate your help.

JBot

[Matt Krass]

Originally Posted by 1680Bruce

Anyway it works, my 2005 controller is happily running MASTER_V12.BIN and both the FRC Default code and OUR 1114-1503-1680 Common base code that were teaching our programmers with.

Originally Posted by JBotAlan

Hmm. I'm glad someone else did this experimentation. It would be an interesting experience, to say the least, describing to our team leader exactly why the most expensive component of the robot has become a paperweight.

Thanks for trying. I really appreciate your help.

JBot

Yeah I was definitely not up to that adventure Killing the RC my first year on 358 would have left a bad first impression

Thanks for the information, I've tucked it in with my 'useful things' section of the brain.

[esquared]

Originally Posted by JBotAlan

...
EDIT: I was under the impression that Camera_Handler() in camera.c was supposed to be calling Initialize_Camera(), and it is as far as I know. I can call it manually, but depending on the flags set in camera.c, it does get called if camera comms aren't working. Correct me if I'm wrong...

I missed that as well in camera.c so good call.

Aside from your efforts to start from the default code, I can send you a basic environment that has a working camera without too much of our robot-specific code in it just so you can verify its not the source you're building from.

Another possibility-what version of the IFI loader are you using? If you use the old version with code sizes> 32k (or whatever the max was for 2005's RC), you can get wicked crazy problems. That might explain why things stopped working as you added more functions/files.

-Eric

[Mark McLeod]

Good news & bad news...

I dropped your code as-is into one of our controllers and a printf I added to user_routines.c worked fine.
Master code v12
IFI_Loader v 1.1
I ran without the camera as a first test then connected the camera.

Which printf in what routine in particular were you having trouble with?

P.S. In the version you posted none of the camera code is ever called from anywhere, so there won't be any "uncalled for" printf's from any of that code.
I added a call to CAL_Update(); in Process_Data_From_Master_uP and uncommented the #include "camera_abstraction.h"
and I'm seeing the printf's from the camera code.

[JBotAlan]

I'm using IFI Loader 1.1.0. I see no printfs anywhere, at all when I put this code into my rc. I've verified it's not my terminal program, serial port, or the rc itself as I loaded old code and it showed all the printfs fine. I can't test anything until somewhere around the 4th because I can't get into the shop until then. I had added printfs directly into main() because nothing else was working, and even that wasn't working. I suppose I should update the master code because I am pretty sure nobody bothered to do so last year--I think we're running v11 still.

Thanks again
JBot

EDIT: Is that what the new master code was released for--a fix in printf? I knew there was new code out there but I don't remember ever updating. I even have the binary on my machine right now, I just need to upload it.

[Mark McLeod]

Originally Posted by JBotAlan

EDIT: Is that what the new master code was released for--a fix in printf? I knew there was new code out there but I don't remember ever updating. I even have the binary on my machine right now, I just need to upload it.

No such luck.
The master code revisions usually are just to match changes in the field control software. v11 was released to fix a random twitch in the pwm outputs for Victors, but nothing that affects the behavior of our User code. The Master version won't affect your printf.
I dumped v11 into my test controller just to eliminate that as a potential cause, and your code still works fine.

Your code is small enough to fit and run on the older PIC-based controllers, so the IFI_Loader version isn't a likely issue. But if you get a Vex kit as a present you'll be able to test your code at home!

I'd start with a close look at the simple solutions.

When you get back to the robot after the holidays double check that you're downloading the .hex file you think you are. I notice you're putting the .hex file in a different directory than the source code (C:\old_'07_Code), so check the date on the file IFI_Loader is pointing to and verify it's new.

Double check your C18 version (2.4). I'm sure you have the current version, but verify there aren't older versions or the Vex version conflicting.

What's the history of the PC you're using? Has it been used for several years? Has MPLAB/C18/etc. been reinstalled around the time your troubles began?

[JBotAlan]

Originally Posted by Mark McLeod

No such luck.
The master code revisions usually are just to match changes in the field control software. v11 did fixed a random twitch in the pwm outputs for Victors, but nothing that affects the behavior of our User code. The Master version won't affect your printf.
I dumped v11 into my test controller just to eliminate that as a potential cause, and your code still works fine.

Ugh. Here we go.

Originally Posted by Mark McLeod

Your code is small enough to fit and run on the older PIC-based controllers, so the IFI_Loader version isn't a likely issue. But if you get a Vex kit as a present you'll be able to test your code at home!

Not likely, but it would be nice. I think I'm going to ask the team leader if I can bring home the old controller, OI, some power source, and all the necessary testing hardware so I can get something done.

Originally Posted by Mark McLeod

I'd start with a close look at the simple solutions.

When you get back to the robot after the holidays double check that you're downloading the .hex file you think you are. I notice you're putting the .hex file in a different directory than the source code (C:\old_'07_Code), so check the date on the file IFI_Loader is pointing to and verify it's new.

<scratches head> I looked at the project options again after you mentioned this, but I see the output directory is c:\old_'07_code, right where the source is. I verified that MPLAB is opening the right files. I have deleted the .hex file, recompiled, and yes, it shows up right where I expected it would, and I verified it was this .hex I downloaded.

Originally Posted by Mark McLeod

Double check your C18 version (2.4). I'm sure you have the current version, but verify there aren't older versions or the Vex version conflicting.
What's the history of the PC you're using? Has it been used for several years? Has MPLAB/C18/etc. been reinstalled around the time your troubles began?

I installed this from the '06 disc in the KOP which only had 2.4 on it. I only bought this PC in July or August of this year, so it doesn't have an old version conflict. Also, I have never done Vex ever, so that's not a possibility. I never reinstalled MPLAB, but I'm thinking that's my next step.

It might work right now. I have no idea. I'll have to test it when we get back.

JBot

[Mark McLeod]

Originally Posted by JBotAlan

<scratches head> I looked at the project options again after you mentioned this, but I see the output directory is c:\old_'07_code, right where the source is.

I understand how you setup your project now. I unzipped your files to a folder on my computer that wasn't c:\old_'07_code. Removing the hardcoded paths for Output directory, Intermediates Directory, and Linker-Script Path let them default to whatever the current directory happens to be.

The MPLAB version won't matter much either. It's just an editing/organizing tool.

Don't sweat it until you're in a position to test again. It'll only drive you nuts. Right now what you've got looks good to me. I'll post the working hex file I compiled and you can use it to eliminate your PC/MPLAB/C18 as any kind of a suspect.

Here's the hex file and the camera initialization output printfs I'm seeing. (ignore the "MLM" that's my test printf from user_routines.c)

[JBotAlan]

Alright, thanks. Got the file, will try it when we get back.

Some of the characters in the output are interesting, but I won't worry about it right now.

Thanks

You deserve a candy bar...

Here you go:
http://www.nadf.com/images/3musketeers_c.gif

hehe...I'm going nuts already. Think of what the season is going to do...

JBot