Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

serial data crashes processor

 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    www.mcselec.com Forum Index -> BASCOM-AVR Archive
View previous topic :: View next topic  
Author Message
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 469

newzealand.gif
PostPosted: Mon Jul 15, 2013 8:55 am    Post subject: serial data crashes processor Reply with quote

For some time I have had 'troubles' with a serial port that gets 4000-5000 bytes of data from a noise meter. Data rate is slow, and from time to time the processor resets. Today i wrote some test code, as shown below. Whenever the push button is pressed momentarily, the noise meter gets a few setup bytes, and then sends 4008 characters to the uP. The noise meter has RTS/CTS which are hooked up via a MAX202 RS232 transceiver. If I look at the data with a PC using HT, it behaves and looks exactly as one would expect. No roque char, no pauses or anything untoward. Turning brownout off has no effect. All testing has been done with WD off
Code:

'*******************************************************************************
$PROG &HFF , &HD7 , &HD8 , &HFC                             ' with brownout.

'*******************************************************************************
 $regfile = "m1284pdef.dat"

 $crystal = 9830400

 '*****************************************************************************


 $framesize = 500                                           ' Located at top of 16k of SRAM
 $hwstack = 500                                             '
 $swstack = 500                                             '
 Disable Jtag

'-------------------------------------------------------------------------------
'Open a software UART TRANSMIT channel for debug dB9
 Open "comc.3:9600,8,n,1" For Output As #1                  '
 Open "comc.2:9600,8,n,1" For Input As #5

'--------------------------------------------------
'Open Hardware uart on pins 14 & 15 for NOR140
'com 1
' CTS is an input ( on the uart)
' RTS is an output ( on the uart)
 $baud = 9600
 Open "com1:" For Binary As #3                              'Nor140
 Config Serialin = Buffered , Size = 250 , Cts = Pind.4 , Rts = Pinc.5 , Threshold_full = 50 , Threshold_empty = 50
 'Threshold_full is bufspace at which data flow stops, controlled by RTS.
 'Threshold-empty is no of bytes from the top of the buffer size at which flow is enabled again.
 'probably they should both be about the same number

 Config Serialout = Buffered , Size = 250
 enable interrupts



Dim Rxbyte As Byte                                          'byte received from modem or sound meter
Dim N As Integer
dim charcount as integer
dim inarr(10) as byte                                       '10 byte inwards array


Pa4led Alias Porta.4
Config Pa4led = Output

Pc4led Alias Portc.4
Config Pc4led = Output

Pd7led Alias Portd.7
Config Pd7led = Output


Testpb Alias Pinb.3
Config Testpb = Input                                       'test push button
Portb.3 = 1                                                 'Pullup On


'------------------------------------------------

Print #1 , ">> Cpu Startup - MCUSR = " ; Mcusr
Select Case Mcusr
    Case Is = 16
     Print #1 , ">> JTAG RESET"

    Case Is = 8
     Print #1 , ">> Watchdog reset"

    Case Is = 4
     Print #1 , ">> Brownout reset"

    Case Is = 2
     Print #1 , ">> External reset"

    Case Is = 1
     Print #1 , ">> Power on reset"

    Case Is = 0
     Print #1 , ">> power-on reset flag"

 End Select
Mcusr = 0                                                   'set all flags to 0


 Config Watchdog = 8192                                     ' 8secs does work with the 1284P
' Start Watchdog
 stop watchdog


print #1 , "start of my loop"
'******************************************************************
do
print #1 , "wait " ;
wait 5
 stop watchdog
                       If Testpb = 0 Then                   'start the data flow
                             charcount = 0
                             Print #3 , "xc1;"              'select transfer F data
                             Print #3 , "xw0;"              'select A weighting
                             print #1 , "data coming"
                             print #3 , "ub0,500;it;"       'initiate 500 blocks x 8bytes bytes of data terminated by "Nor140"
                       end if
                             waitms 100                     'wait for  first few bytes
                             while ischarwaiting(#3) <> 0

                                     if pinc.5 = 1 then     'monitor RTS
                                         set pc4led
                                     else
                                         reset pc4led
                                     end if


                                    rxbyte = inkey(#3) ;
                                    print #1 , chr(rxbyte);
                                   ' waitus 5000
                                    incr charcount

                                   for n = 1 to 5
                                         inarr(n) = inarr(n + 1)       'shuffle the array
                                    next
                                    inarr(6) = rxbyte
                                   
                                  ' look for end of the data
                                   dim instring as string * 6 at inarr(1) overlay
                                   if instring = "Nor140" then
                                       print #1 , " got eos"
                                       exit while
                                   end if

                             wend


                             print #1 , "charcount= " ; charcount

   loop



'******************************************************************************
 


Most of the time, pushing the button gets the correct response.
Quote:

data coming
.
.
etc.

E 52.1
E 40.5
E 51.8
E 39.7
Nor140 got eos
charcount= 4008

However every now and again, the processor resets thus:
Quote:

data coming
.
.
etc.
.
.

E 42.4
E 48.3
E 40.0
E 40.4
E 39.3
E 39.3
E 39.6
E 39.1
E 39.2
up - MCUSR = 0
>> power-on reset flag
start of my loop
wait


I have spent several ( read many!) hours trying to find out why. The led on PA4 never flashes unless I put a delay in the receive loop, which slows it down enough for the serial buffer to fill. The crashes do not seem to be related to this, and if I look at bufspace, the buffer cycles between 45 bytes and 200 bytes, which is correct given the setting of 250 buffer size, and limits 50 from the bottom and 50 from the top.
In spite of what MCUSR says, it is not a power supply problem. The board is running from a 12v 50AHr battery, with a 7805 regulator, and several 1000 uF around the board. With no serial data the board will run for weeks at a time without a reset. Its almost like the processor stumbles or chokes on the incoming RS232 data. If I take out the array end of string stuff, it makes no difference.

(BASCOM-AVR version : 2.0.7.6 )

_________________
Neil
Back to top
View user's profile
Evert :-)

Bascom Expert



Joined: 18 Feb 2005
Posts: 2156

netherlands.gif
PostPosted: Mon Jul 15, 2013 10:47 am    Post subject: Re: serial data crashes processor Reply with quote

njepsen wrote:
The board is running from a 12v 50AHr battery, with a 7805 regulator, and several 1000 uF around the board.

1000uF is nice to get rid of the low frequencies, but you also need parallel to the 1000uf, 100n and 10n to suppress the high frequencies.

_________________
www.evertdekker.com Bascom code vault
Back to top
View user's profile Visit poster's website
laborratte

Bascom Expert



Joined: 27 Jul 2005
Posts: 299
Location: Berlin

germany.gif
PostPosted: Mon Jul 15, 2013 11:17 am    Post subject: Reply with quote

You can not check MCUSR directly for reason of reset, it is cleared by BASCOM on startup. Read R0 instead (at the very beginning of your program). See Help topic "CONFIG WATCHDOG" for details.
Back to top
View user's profile
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 469

newzealand.gif
PostPosted: Mon Jul 15, 2013 11:26 am    Post subject: Reply with quote

Thanks guys - Laborratte. I wll check that out. Evert - there are several 0.1 and 0.01 also at each device supply pin, and no earth loops. I'm convinced its not a psu prob.
_________________
Neil
Back to top
View user's profile
toto







PostPosted: Mon Jul 15, 2013 11:26 am    Post subject: Reply with quote

Hello
Try to compile with version 2.0.7.2
I have identical problems but with RS485 communications. With version 2.0.7.6 my program not work correctly, "Timing rules perhaps"
Mark have make few changes for RS485

I change to version 2.0.7.2 and it's better now. The noise reset the cpu rarely
I need to solve this problem to. My program work on a noisy environment and some times the noise reset the Atmega2560
On A and B of RS485 device i have allready a double 12V supresor, but not solve

Best regards
toto
Back to top
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5921
Location: Holland

blank.gif
PostPosted: Mon Jul 15, 2013 11:45 am    Post subject: Reply with quote

the (ceramic) 100 nF caps must be close as possible to the input and output pin of the regulator. Further, a low ESR cap (Q factor) is better because it can supply current quicker. Just adding big capacitors does not mean much.

toto: the rs485 is totally different. besides it would show the problem immediately.

_________________
Mark
Back to top
View user's profile Visit poster's website
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 469

newzealand.gif
PostPosted: Mon Jul 15, 2013 11:57 am    Post subject: Reply with quote

I'm certain its not supply noise and I have quite a few 0.1 ceramics and monolithics on the board, but I'll add some more tomorrow directly to the regulator IO pins and also to the uP and RS232 transceiver. I am desperate to find this problem.
_________________
Neil
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5921
Location: Holland

blank.gif
PostPosted: Mon Jul 15, 2013 12:11 pm    Post subject: Reply with quote

a regulator (especial the old ones) can produce a lot of harmonic frequencies. that is why you need to add the 100 nF close the pins. you find the same info in the data sheet. most recommend a tantalum cap at the output pin too.
i do not understand the WD in your code. it does not seem to be used. the WD is turned off by default. if you remark all WD code does the problem still occur?

i have seen topics about tx/rx reset problems where the problem seem to be solved with a small cap from tx or rx to ground. it was a specific chip problem.

_________________
Mark
Back to top
View user's profile Visit poster's website
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 469

newzealand.gif
PostPosted: Tue Jul 16, 2013 2:07 am    Post subject: Fixed( ? ) Reply with quote

Mark - thankyou for your comments. ( the watchdog code was where I had been trying it on and off. All test results with WD off).
I tried several 0.1 monolithics, with very SHORT leads directly across the IO of the regulator, the supply pins of the uP and the supply pins of the RS232 transceiver, without success. Then put an 0.1 directly on the uP reset pin ( even though there was already a 0.1 cap on the reset line). No improvement - the board would do a reset about every 2-5 minutes, and R0 was set to 0. ( thanks Laborratte for that.)

Then i put a 1000pf on the rx pin of the uart and so far the board has been running continuously, receiving continuous data for 2 hours without a reset. I am guessing this is the solution. 1000pf is probably a bit brutal but seems to work.

I have had a look at the rx data with a bitscope computer analyser/scope and the waveform is pretty clean, is almost a perfect sq wave & runs between 0v and +5, and has about 10mv of hi freq hash on the hi & lo logic levels. This is a bit hard to analyse because there is some inherent hash in the bitscope display itself, (with the leads shorted to ground).

All in all, I think a good result.

_________________
Neil
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5921
Location: Holland

blank.gif
PostPosted: Tue Jul 16, 2013 9:20 am    Post subject: Reply with quote

i think this same problem was discussed before on this forum. 100 pF would do.
There is some fault in the chip but when you read the errata it is not the only one. this one is easy to fix however. i will add a note to the help.(in case it was not there yet)

_________________
Mark
Back to top
View user's profile Visit poster's website
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 469

newzealand.gif
PostPosted: Tue Jul 16, 2013 9:34 am    Post subject: Reply with quote

Where is the errata you mention Mark? - in the help files or in the Atmel data sheets?
_________________
Neil
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5921
Location: Holland

blank.gif
PostPosted: Tue Jul 16, 2013 9:44 am    Post subject: Reply with quote

the data sheet. it is the first place you need to look when having a hardware problem.
_________________
Mark
Back to top
View user's profile Visit poster's website
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 469

newzealand.gif
PostPosted: Tue Jul 16, 2013 9:45 am    Post subject: Reply with quote

I just found this, which pretty much describes my symptoms.
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=91002&start=0

There is also further information here:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=107115&start=0

In summary it appears that the Atmega1284P ( which I am using) has a problem: noisy data on the RX0 pin of the uart causes the chip to reset or jump to random places in the code. The previous writers say it only happens with the 40pin DIP at 18 MHz or above, but I have experienced the problem at 9.8304Mhz.
More testing required.

Further info:
http://www.ot-hobbies.com/resource/ard-1284.htm


Quote:

http://www.ot-hobbies.com/resource/ard-1284.htm
6. RX0 and Sketch Uploading Problems - History

In the past, many [but not all] people had problems uploading sketches to ATmega1284P bootloader chips in DIP40 package. By default, this process uses hardware UART0, ie the RX0,TX0 pins.

It was common to have communications failures during sketch uploading, and several people referenced an avrfreaks forum thread on how to fix this. This fix involved using an RC low-pass between the FTDI USB-to-RS232 chip and the RX0 pin, with typical values of 1K-10K and 100pF.

Although this solved the comms-sync problem, several people investigated further, and came to the conclusion that the problem was actually related to the fact that the XTAL1 (oscillator input) pin is adjacent to RX0 on the DIP40 version of these chips, and the XTAL1 input was being affected by cross-talk. After some brilliant simulations by Pito, plus further investigations, it was generally decided that the "proper" fix was to change the bootloader Low-Fuse setting from low-power oscillator to full-swing oscillator, thus minimizing the effects of said cross-talk.

_________________
Neil


Last edited by njepsen on Wed Jul 17, 2013 2:23 am; edited 1 time in total
Back to top
View user's profile
Plons

Bascom Member



Joined: 24 May 2005
Posts: 435
Location: Hilversum - The Netherlands

netherlands.gif
PostPosted: Tue Jul 16, 2013 12:25 pm    Post subject: Reply with quote

Thanks Neil, for your extensive research. Was a tough one to find !

The good old ATmega32 doesn't suffer from this problem, while Xtal1 is adjacent to RxD as well. The on-going reduction of power consumption comes at a price.

Nard

_________________
Bascom AVR ver 2.0.8.6
Dragon-lair: http://www.aplomb.nl/TechStuff/Dragon/Dragon.html
"leef met vlag en wimpel, maar hou het simpel"
Back to top
View user's profile
Plons

Bascom Member



Joined: 24 May 2005
Posts: 435
Location: Hilversum - The Netherlands

netherlands.gif
PostPosted: Tue Jul 16, 2013 10:47 pm    Post subject: Reply with quote

I posted your findings on http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1083215#1083215 for reference
_________________
Bascom AVR ver 2.0.8.6
Dragon-lair: http://www.aplomb.nl/TechStuff/Dragon/Dragon.html
"leef met vlag en wimpel, maar hou het simpel"
Back to top
View user's profile
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    www.mcselec.com Forum Index -> BASCOM-AVR Archive All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum