Why UART data is getting corrupted?

I'm getting a strange issue. We have a Atmega 128 controller board that kee ps on polling 15 Atmega8 based ultrasonic sensors. They are connected in RS 422 model where all Tx pins of 15 sensors are connected together and in-tu rn connected to the Rx of the Atmega 128 controller and all Rx pins of 15 s ensors are connected together and finally connected to the Atmega 128..

Am making sure that the communication protocol is implemented correctly.. I mean.. no data collision among the sensors.. enabling and disabling Tx/Rx links property while exchanging the messages....

The problem is.. when I saw the output through the UART on the Atmeg128 con troller, the output looks fine.. it is keeping on polling and I saw the bel ow polling message...

01P 02P ......15P

Meaning 01 sensor.. what is the status..., 02 sensor what's the status ..? etc.. and sensors are also properly responding..

But when I checked on the next day, either none of them are working or few of them got frozen.

When I checked the same UART data,.. I found some scrap message or sometime s no UART data at all...

And sometimes though Atmega 128 is polling fine, Atmega 8 is not at all res ponding.. it is mute..

No loose contacts ...

Why so?

There's watchdog timer running in all Atmega8 and atmega128 also..

What are the typical causes for this strange issue?

Power supply is a 12V dc , meanwhile brand...

Reply to
T Obulesu
Loading thread data ...

Il 03/05/2019 08:58, T Obulesu ha scritto:

Do you have a direct connection without a transceiver?

Problems that arise after some hours can be very difficult to debug. Maybe this issue isn't related at all with UART activity.

Do you have hw/sw timers? Are you sure they are implemented correctly? It sometimes occurs that the wrap-around of variables or registers triggers certain bad behaviour.

Interrupts are also important to check. Problems related to interrupt could occur very rarely, maybe your long time before the problem occurs depends on a problem in interrupts.

Looking at the UART, other typical problems are related to lack of pull-up/down when all the transmitters on the line are in high impedance.

Reply to
pozz

keeps on polling 15 Atmega8 based ultrasonic sensors. They are connected i n RS 422 model where all Tx pins of 15 sensors are connected together and i n-turn connected to the Rx of the Atmega 128 controller and all Rx pins of

15 sensors are connected together and finally connected to the Atmega 128..

Max490 is the chip that controls the transmission and soldered on both ends ..

.. I mean.. no data collision among the sensors.. enabling and disabling Tx /Rx links property while exchanging the messages....

controller, the output looks fine.. it is keeping on polling and I saw the below polling message...

..? etc.. and sensors are also properly responding..

few of them got frozen.

times no UART data at all...

responding.. it is mute..

Yeah... May not be... I read the flash memory after this issue and compared it with the original flash code (.HEX file).. BOth of them are completely different..

Watchdog timer is running... It correctly restarts the code if code gets hanged.. All are local variables and static variables too... those will b destroed a s soon as scope exits..

Clearing the interrupts properly..

Apparently.... the same sensor set up is working in some places... and som e other places it is not working... We have implemented this product in Sho pping malls...

Reply to
local

What exactly are you trying to do ? That description sounds like standard 4-wire RS-485 system, in which the master (Atmega 128) keeps the transmitter always active and always listen on the other pair, while the slaves (Atmega) always listen on the master Tx pair, but the slave transmitter is activated only when it responds to the poll and the response is transferred to the master Rx.

If you are really using MAX-490 this will cause a problems. The MAX-490 is a RS-422 only chip with no Output Enable (OE) pin, thus, all slave transmitters are always active. When there is no problem as long as no slave wants to respond, since each slave are driving the bus into idle ("1") state. However, as soon as one slave wants to respond and the response contains the "0" state, only this transmitter tries to pull down the bus, while 14 other chips tries to keep it in "1" state. This is a short circuit condition and since the MAX-490 chips have over temperature protection, it will cut out some of the chips sooner or later.

There are (at least) two workarounds.

1.) Use two diodes in each slave Tx pair, so that only the "0" state is actively driven, while the "1" state is handled by the "fail-safe" termination. 2.) Use a proper 4-wire RS-485 transceiver on each slave, such as MAX-489 or MAX-491.The slave will activate the DE (Driver Enable) pin as long as that particular slave is sending the response. Please note that the DE can be dropped only after the last stop bit of the last character has been actually sent out, not when the last bit is loaded into the UART shift register. I do not know about the Atmega 8 UART, but at least the 14550 UART family is hard to use for RS-485, since it generates an interrupt only when the last character is loaded into the shift register _not_ when the last stop bit has actually been transmitted.

In both cases, the master can use the MAX-490 RS-422 only chip.

Reply to
upsidedown

Maybe a stack overflow!!??

Reply to
ZOT

**Different?** If so, I'm not surprised the application doesn't work anymore.
Reply to
pozz

at keeps on polling 15 Atmega8 based ultrasonic sensors. They are connected in RS 422 model where all Tx pins of 15 sensors are connected together and in-turn connected to the Rx of the Atmega 128 controller and all Rx pins o f 15 sensors are connected together and finally connected to the Atmega 128 .. []

28 controller, the output looks fine.. it is keeping on polling and I saw t he below polling message...

s ...? etc.. and sensors are also properly responding..

r few of them got frozen.

metimes no UART data at all...

ll responding.. it is mute..

[]

nal flash code (.HEX file)..

I saw that comment and was shocked too. And they already deployed it to customers.

So bad Flash hardware? or is the app corrupting the flash?

Time to do real engineering work rather than slapping pieces/parts together . Ed

Reply to
Ed Prochak

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.