Re: Dangerous.....Code problem?!?
 

Ive never heard of anyones controller doing something all by itself after running for a while - Im talking about running for hours, so I really doubt the PICs watchdog timer is doing something on its own.

One possiblity, if you have an error in your code that causes an infinite loop, or that takes too long to run, the OI link program will disable your outputs (thinking your code is lost in the woods) and that might cause a reset of the OI.

This is starting to sound like CS101 syndrome (my SW is ok, the mainframe is broken! )

most likely there is something in your code that is causing the drive motors to lurch.

Re: Dangerous.....Code problem?!?
 

Could you tell me where I could find the 18F8520's data sheet? (sorry I am on a rookie team and don't know where too much stuff is.)

Re: Dangerous.....Code problem?!?
 

Datasheet: http://www.microchip.com/download/li...x20/39609b.pdf

It assumes you're already familiar with assembler programming, though, so it might be kinda difficult to understand.

Re: Dangerous.....Code problem?!?
 

Ummm... so can you change it in the code so that way it wont reset. Or, will that affect the bot preformance?

Re: Dangerous.....Code problem?!?
 

Our bot did a stack overflow reset the other day when we were testing new autonomous code. This seems like what caused your problem.

Re: Dangerous.....Code problem?!?
 

This may be related, so I'm posting it here. Using the FRC-INTERRUPTS code posted by Kevin, our drive motors (PWM 13 & 15) went crazy (jerking back & forth) whenever we tried to enable a timer interrupt. The interrupt handler only increments a unsigned long.

Today, I'm going to start with a fresh copy of his code and only modify the timer initialization code to pin down the exact problem. If the problem persists, I will post the mods for discussion.

BTW, our two Grayhill 61K128 encoders work fine at ~200 RPM using interrupts (INT1/INT2). But disabling them, doesn't solve the problem.

What I'd like is a timer with a resolution of 0.1 ms or better. My thinking is to have a timer interrupt update a counter every millisecond, then reload the timer register will a value that will roll over again in 1ms. The timer register could be read to calculate the fractional part of the timestamp when needed.

FYI: For safety, we either put our robot on blocks or unplug the PWM cables from the drive motors when powering up the robot in close quarters.

Re: Dangerous.....Code problem?!?
 

one thing that can make a bot go totally berzerk is if you output 255 on a pwm - 255 is the start of serial data flag, so you must limit your pwm variables so they can never be 255

what happens is the output string restarts when it sees the 255, so the variables you intended to be digital outputs will end up on pwm outputs, and the pwm variables will not be going to the right pwm pins

in other words, the bot goes completely berzerk!

Re: Dangerous.....Code problem?!?
 

Another possible explaination is as you noted in a previous post
" The robot had been running for hours"

Your battery may have lost enough "Juice" to start behaving erratic.
Watch the voltage levels....

Phil

Re: Dangerous.....Code problem?!?
 

When the stack overflowed did the robot go into a reset state or did it restart? We tested it on the EDUbot by calling a recursive function and we got a blinking red program state.

Re: Dangerous.....Code problem?!?
 

There are two different .lib files from IFI: FRC_Alltimers.lib and FRC_Library.lib. If you use the Generate_Pwms() function you need to use FRC_Library.lib. The Generate_Pwms() function uses timer0 so it is unavailable. If you don't need the extra 4 PWMs then you can use FRC_Alltimers.lib and have access to timer0.