Printf has just entirely failed to do anything

[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

[Kevin Sevcik]

JBotAlan,

I think your problem is both obvious and simple to fix, luckily. Rearranging the Camera_Handler function etc, had nothing to do with it. Had you left the original code intact, you still would have broken the program by moving Camera_Handler() (or CAL_Update() in your program) from user_routines.c to Process_Data_From_Local_IO(). Move Camera_Handler() back where it belongs and everything will work wonderfully again.

Here's my reasoning. Process_Data_From_Local_IO(), as you know, runs stupidly fast, as it runs every loop in the user PIC. As opposed to every 26.2ms for Process_Data_From_Master_uP(). Camera_Handler() is a very complicated little function, and does tons of fun stuff like disabling serial interrupts briefly and using the inherent timing of the slow loop to get the timing of its initialization correct. Basically, with Camera_Handler() in your Process_Data_From_Local_IO(), things are happening waaay too fast and piling up and generally causing the horrible broken execution and code error lights that you're seeing.

To put it even more briefly, in the camera_readme.txt, Kevin Watson says you should call Camera_Handler() from Process_Data_From_Master_uP(). You really ought to listen to him unless you've initmately acquainted yourself with the operation of said function.

[JBotAlan]

Oh.

Maybe I should've read that readme.

I figured that it shouldn't be in the slow loop because by default that doesn't even execute during auton, where we need the camera the most. I will definitely read through that function and the camera readme and see if moving the function call back to process_data_from_up helps. That would make sense if it was disabling and re-enabling serial interrupts very quickly...

I never would've caught that.

Thanks
JBot

EDIT: Just glancing through camera.c, I don't happen to see where serial interrupts are disabled/enabled, but I haven't looked at all of the function calls either. I do notice a loop_count variable; that alone warrants moving it back into the slow loop. Like I said, I need it to execute in auton. I may well modify this function so that it can safely execute in the fast loop. I don't know; I don't have time today to deal with this but thanks for the help.