View previous topic :: View next topic |
Author |
Message |
njepsen
Joined: 13 Aug 2007 Posts: 469
|
Posted: Mon Jul 15, 2013 8:55 am Post subject: serial data crashes processor |
|
|
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 |
|
|
Evert :-)
Joined: 18 Feb 2005 Posts: 2156
|
Posted: Mon Jul 15, 2013 10:47 am Post subject: Re: serial data crashes processor |
|
|
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 |
|
|
laborratte
Joined: 27 Jul 2005 Posts: 299 Location: Berlin
|
Posted: Mon Jul 15, 2013 11:17 am Post subject: |
|
|
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 |
|
|
njepsen
Joined: 13 Aug 2007 Posts: 469
|
Posted: Mon Jul 15, 2013 11:26 am Post subject: |
|
|
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 |
|
|
toto
|
Posted: Mon Jul 15, 2013 11:26 am Post subject: |
|
|
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
Joined: 09 Apr 2004 Posts: 5914 Location: Holland
|
Posted: Mon Jul 15, 2013 11:45 am Post subject: |
|
|
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 |
|
|
njepsen
Joined: 13 Aug 2007 Posts: 469
|
Posted: Mon Jul 15, 2013 11:57 am Post subject: |
|
|
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 |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5914 Location: Holland
|
Posted: Mon Jul 15, 2013 12:11 pm Post subject: |
|
|
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 |
|
|
njepsen
Joined: 13 Aug 2007 Posts: 469
|
Posted: Tue Jul 16, 2013 2:07 am Post subject: Fixed( ? ) |
|
|
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 |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5914 Location: Holland
|
Posted: Tue Jul 16, 2013 9:20 am Post subject: |
|
|
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 |
|
|
njepsen
Joined: 13 Aug 2007 Posts: 469
|
Posted: Tue Jul 16, 2013 9:34 am Post subject: |
|
|
Where is the errata you mention Mark? - in the help files or in the Atmel data sheets? _________________ Neil |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5914 Location: Holland
|
Posted: Tue Jul 16, 2013 9:44 am Post subject: |
|
|
the data sheet. it is the first place you need to look when having a hardware problem. _________________ Mark |
|
Back to top |
|
|
njepsen
Joined: 13 Aug 2007 Posts: 469
|
Posted: Tue Jul 16, 2013 9:45 am Post subject: |
|
|
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 |
|
|
Plons
Joined: 24 May 2005 Posts: 435 Location: Hilversum - The Netherlands
|
Posted: Tue Jul 16, 2013 12:25 pm Post subject: |
|
|
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 |
|
|
Plons
Joined: 24 May 2005 Posts: 435 Location: Hilversum - The Netherlands
|
|
Back to top |
|
|
|
|
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
|
|