PDA

View Full Version : HSerin problems on power up



Luckyborg
- 15th April 2009, 22:21
This is a problem I've encountered for years on several different chips and have always just kind of ignored it. I have a problem using the Hserin command on initial power up. Below is a stripped down version of my code. Basically I power up the chip and wait a little while then send a burst of data. that data is basically ignored, I send a second burst and it is processed as is every burst after. if I hit the reset button every burst is processed, but if I turn off the power and wait a few seconds before powering back up the problem comes back for the first burst of data. I've checked the overflow and framing error bits, and see no problem. There are only a few registers I can even think to look at, but nothing is popping out at me. it seems like it would have to be something obvious.



INCLUDE "DT_INTS-18.bas" ; Base Interrupt System
INCLUDE "ReEnterPBP-18.bas" ; Include if using PBP interrupts

Clear
DEFINE OSC 40 ' Set Xtal Frequency
DEFINE HSER_CLROERR 1 'will automatically clear overflow errors

stream VAR BYTE[80] 'the last stream in
view_stream var byte[104] 'outsream converted to patterns

a VAR BYTE 'loop counter variable
b VAR BYTE
x VAR BYTE 'loop counter variable
B0 VAR BYTE
B1 VAR BYTE
B2 VAR BYTE
B3 VAR BYTE
B4 VAR BYTE
B5 var byte

pattern var byte
new_stream var bit

red_LED VAR PORTC.4 'red led

CSALL CON %00000000 'Chip Select for all chips
CSOFF CON %00001111 'chip select for no chips

CSB0 VAR PORTB.0
CSB1 VAR PORTB.1
CSB2 VAR PORTB.2
CSB3 VAR PORTB.3

TRISA = %11101100
TRISB = %11110000 'inputs for upper half switches outputs for lower CS
TRISC = %11001111 '0-3 for switches, 4-5 for LEDs, 6-7 for serial data
TRISD = 0
TRISE = 0

PORTB = CSOFF
PORTE.0 = 1
PORTE.1 = 1
PORTE.2 = 0

ADCON1 = %00001111

;****************Using Darrel Taylor Interrupts****************************
;----[High Priority Interrupts]--------------------------------------------
ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler RX_INT, _GetData, PBP, no
endm
INT_CREATE ;Creates the High Priority interrupt processor
ENDASM

red_LED = 0 'turn on red LED

Pause 1000

top:

TXSTA = $20 ' Enable transmit, BRGH = 0
SPBRG = 34 ' 1200 Baud @ 0.0%
SPBRGH = 8
BAUDCON.3 = 1 ' Enable 16 bit baudrate generator
RCSTA = $90 ' Enable serial port & continuous receive

GoSub send_data

countdown:
'count from 9 to 0

For x = 9 TO 0 STEP - 1
For a = 0 TO 79
stream[a] = x + "0"
Next a
GoSub send_data
Pause 150
Next x

end_countdown:
'check buttons

@ INT_ENABLE RX_INT ; enable RX_INT interrupts

RCSTA = $80 'clear CREN
RCSTA = $90 'Enable receive



mainloop:


if new_stream = 1 then
RCSTA.4 = 0
RCSTA.4 = 1 'clear over run error
new_stream = 0
GoSub send_data
endif

GoTo mainloop

send_data:

'this sub will send bit patterns via psp (non interrupt driven) to another chip

Return


'---[USART RX - interrupt handler]-----------------------[High Priority]---
GetData:

hserin 1000,No232,[str stream\80\10]

red_LED = red_LED +1 'heartbeat
new_stream = 1

No232:
@ INT_RETURN

End

Thanks
David

mister_e
- 16th April 2009, 15:49
If there's HSERIN/HSEROUT, you should use DEFINEs, unless you just need to write the USART registers.



INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler RX_INT, _GetData, PBP, no

You want to reset flags, unless, your program will loop in the ISR forever.

I haven't look the whole thing, but those are the really first thing that jump in my face.

Luckyborg
- 16th April 2009, 15:52
Thanks, I'll give the reset flags a try latter. I can't use defines as the baud rate needs to be user configurable in the field.

mister_e
- 16th April 2009, 15:56
Yes you can do it, you define one at the top, then you change it later on the fly by writing SPBRG, RCSTA, TXSTA. Check the datasheet for the recommended sequence.

Luckyborg
- 21st April 2009, 19:21
I finally had a chance to try out your suggestions by putting the defines at the beginning of the program and trying to reset the flag, but I have the same result of garbage in on the first transmission, then clear after that. Any other ideas would be appreciated.

David

mister_e
- 21st April 2009, 19:25
It may happen if your transmitter use SEROUT/SEROUT2/DEBUG and the pin idle state is not set before sending the first data.

Post your both code, receiver and transmitter end.

Luckyborg
- 21st April 2009, 19:40
I use a VB program not a pic as the transmitter. I can leave the program running while the pic is powered down. I give the pic a few seconds stabilization time after power up before the next transmission is sent

David

mister_e
- 21st April 2009, 19:44
Ok then, modify your VB program to send few garbage character, then a Synch String (let's say OK), and in your ISR use WAIT("OK") . See if this solve your problem.

Luckyborg
- 21st April 2009, 19:49
I'm sure this would work, I just figured I would see if anyone knew why I can't get it to work as expected. It isn't critical to the application, just one of those annoyances I figured most people weren't living with :)