| View previous topic :: View next topic |
| Author |
Message |
JerryR
Joined: 07 Feb 2008
Posts: 167
|
| Cant figure why code goes off into the weeds |
 Posted: Tue Aug 10, 2021 8:51 am |
 |
|
Hello Group:
Attached is my simple code that was designed to send simple commands through wireless transmitter based on one of five button presses. After each transmission of five identical packets of three bytes, the RF transmitter is put to sleep and power down of the power supply is implemented.
All button presses cause proper operation as expected, except for the FAST button. After sending the five packets, the processor "goes off in the weeds, before shutting down the transmitter or power supply.
All five button routines are identical, and I just don't see why FAST is an issue. Do any of you see anything that could be causing this issue? I've moved code around, tried sending different data for the three bytes; nothing seems to fix the problem.
Thanks in advance
Here's the code:
| Code: |
//================================================================
void Check_Buttons(void)
{
int8 s;
//Check battery voltage
if(input (Lo_Bat_Alm))
Low_Bat_Cdx= FALSE;
else
Low_Bat_Cdx= TRUE;
//STOP Button
if (input (STOP))
{
output_high(Pwr_Ltch); //power latched while sending data
output_high(Radio_PWRDWN); //power up radio to send data
Delay_ms(20); //debounce noise and if still
if (input(STOP) == TRUE) //still down?
{
output_high(STOP_LED);
for(s=1; s<=5; s++)
{
printf("%c%c%c",Preamble, New_Unit_Adr,Stop_Command); //transmit STOP
Delay_ms(50);
}
}
output_low(STOP_LED);
Flash_LED(Sel_STOP_LED);
Delay_ms(50); //delay before power down
output_low(Radio_PWRDWN); //power down radio after sending data
output_low(Pwr_Ltch); //power down after sending data
}
if (input (RIGHT))
{
output_high(Pwr_Ltch); //power latched while sending data
output_high(Radio_PWRDWN); //power up radio to send data
Delay_ms(20); //debounce noise and if still
if (input(RIGHT) == TRUE) //still down?
{
for(s=1; s<=5; s++)
{
printf("%c%c%c",Preamble, New_Unit_Adr,RIGHT_Command); //transmit RIGHT
Delay_ms(50);
}
}
Delay_ms(50); //delay before power down
output_low(Radio_PWRDWN); //power down radio after sending data
output_low(Pwr_Ltch); //power down after sending data
}
//LEFT Button
if (input (LEFT))
{
output_high(Pwr_Ltch); //power latched while sending data
output_high(Radio_PWRDWN); //power up radio to send data
Delay_ms(20); //debounce noise and if still
if (input(LEFT) == TRUE) //still down?
{
for(s=1; s<=5; s++)
{
printf("%c%c%c",Preamble, New_Unit_Adr,LEFT_Command); //transmit LEFT
Delay_ms(50);
}
}
Delay_ms(50); //delay before power down
output_low(Radio_PWRDWN); //power down radio after sending data
output_low(Pwr_Ltch); //power down after sending data
}
if (input (FAST))
{
output_high(Pwr_Ltch); //power latched while sending data
output_high(Radio_PWRDWN); //power up radio to send data
Delay_ms(20); //debounce noise and if still
if (input(FAST) == TRUE) //still down?
{
for(s=1; s<=5; s++)
{
printf("%c%c%c",Preamble, New_Unit_Adr,FAST_Command); //transmit FAST
Delay_ms(50);
}
}
Delay_ms(50); //delay before power down
output_low(Radio_PWRDWN); //power down radio after sending data
output_low(Pwr_Ltch); //power down after sending data
}
//GO Button
if (input (GO))
{
output_high(Pwr_Ltch); //power latched while sending data
output_high(Radio_PWRDWN); //power up radio to send data
Delay_ms(20); //debounce noise and if still
if (input(GO) == TRUE) //still down?
{
for(s=1; s<=5; s++)
{
printf("%c%c%c",Preamble,New_Unit_Adr, Go_Command); //transmit FAST
Delay_ms(50);
}
}
Delay_ms(50); //delay before power down
output_low(Radio_PWRDWN); //power down radio after sending data
output_low(Pwr_Ltch); //power down after sending data
}
}
//================================================================
|
| Code: |
while (True)
{
Check_Buttons();
delay_ms(50);
}
}
|
| Code: |
#FUSES NoWDT //Watch Dog Timer
#FUSES XT //External Osc
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOPUT //Power up timer off for debugging
#use delay(clock=16000000)
#use i2c(Master, sda=PIN_C4, scl=PIN_C3,FORCE_HW)
#define RAND_MAX 255
//CONSTANTS
#define Dead_Time 100 //dead time before power down
#define EE_I2C_ADDR 0 //EEPROMs I2C address
#define Sel_FAST_LED 1 //FAST LED SELECT
#define Sel_STOP_LED 2 //STOP LED SELECT
#define Sel_LoBat_LED 3 //Lo Battery LED SELECT
#define Sel_Teach_LED 4 //teach LED select
#define Num_Flashes 2 //number of flases on LEDs
//modes of operation
#define STOP_Mode 0 //cart stop mode
#define GO_Mode 1 //cart in go mode
#define FAST_Mode 2 //cart in fast go mode
#define GO_Command 0x04
#define STOP_Command 0x01
#define LEFT_Command 0x02
#define RIGHT_Command 0x03
#define Fast_Command 0x05
#define Teach_Command 0x06
#define Right_Rtn_Command 0x07
#define Left_Rtn_Command 0x08
//port pin defines
#define Right PIN_D2
#define Go PIN_D3
#define Left PIN_D1
#define Stop PIN_D0
#define Fast PIN_D4
#define Lo_Bat_Alm PIN_A2 //LBO output from regulator (low of <2.0 V)
#define Fast_LED PIN_E1
#define Stop_LED PIN_E2
#define LoBat_LED PIN_E0
#define Pwr_Ltch PIN_D7
#define EEPROM_SCL PIN_C3
#define EEPROM_SDA PIN_C4
|
|
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Aug 10, 2021 9:43 am |
|
|
What's your PIC ?
What's your Vdd voltage ?
What's your power supply ?
What's your RF transmitter module ?
| JerryR wrote: |
#FUSES NoWDT //Watch Dog Timer
#FUSES XT //External Osc
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOPUT //Power up timer off for debugging
#use delay(clock=16000000)
|
XT is not for an external oscillator. It's for a 4 MHz crystal.
What is your oscillator circuit ?
| JerryR wrote: |
#FUSES NoWDT //Watch Dog Timer
#FUSES XT //External Osc
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOPUT //Power up timer off for debugging
|
Why no brownout ? If the power was drooping, the PIC might well
go into the weeds. With Brownout, it would reset.
Why noput ? If you have an external crystal and caps, PUT is
normally recommended. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9232
Location: Greensville,Ontario
|
|
| Posted: Tue Aug 10, 2021 2:52 pm |
|
|
PIN_D4 could have an internal peripheral attached to it......
though it'd really help to post the PIC model.
Normally you disable EVERY peripheral that can be 'attached' or used by an I/O pin otherwise 'interesting' things can happen...
hmm RF transmitter...... what is the current demand of it, and is your PSU good for 4-10* that value ?? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Wed Aug 11, 2021 12:41 am |
|
|
It should almost be a capital offence to ask a chip question, without saying
'what chip'.... 
As PCM points out your clock option is invalid (on some PIC's, XT can be
up to 10MHz, but never 16MHz).
As Jay says though, most likely thing is that there is something different
about D4.
Tell us a lot more.
Answer PCM's questions. |
|
|
JerryR
Joined: 07 Feb 2008
Posts: 167
|
|
| Posted: Wed Aug 11, 2021 11:31 am |
|
|
Thanks for all your interest group! I did locate the issue, however. I had enabled the rx interrupt without a routine to handle it, so the firmware went into the weeds.
Thanks again |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Wed Aug 11, 2021 11:49 am |
|
|
Very much a 'classic' failure.
However you need to look over your code again, and get legitimate clock
options sorted as well.
What you currently have is not a legal clock on any PIC.
It would only work either by dropping back to a failsafe oscillator option
if this was available and enabled, or if you were feeding in an external
oscillator signal. If you are doing this, it will result in extra power consumption
to run with 'XT' rather than 'EC'. |
|
|
JerryR
Joined: 07 Feb 2008
Posts: 167
|
|
| Posted: Wed Aug 11, 2021 12:12 pm |
|
|
| Sure, thanks. Let me know! |
|
|
dluu13
Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Thu Aug 12, 2021 2:03 am |
|
|
Yes, the automatic approach is a generally safer way to go. However just
as with the manual approach, it is vital that you actually 'know' what clock
you are intending to use. It sets things up to match what you tell it. If this
is wrong, the result will be wrong.
It can sometimes lead to issues with some particular clock setups, where
you want to do something that is not covered by this automatic route. Key
here is that if you apply fuses after the 'automatic' lines, these will override
what this does. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
