I'm getting a strange issue. We have a Atmega 128 controller board that 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 of 15 sensors 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 controller, the output looks fine.. it is keeping on polling and I saw the below 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 sometimes no UART data at all... And sometimes though Atmega 128 is polling fine, Atmega 8 is not at all responding.. 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...
Why UART data is getting corrupted?
Started by ●May 3, 2019
Reply by ●May 3, 20192019-05-03
Il 03/05/2019 08:58, T Obulesu ha scritto:> I'm getting a strange issue. We have a Atmega 128 controller board that 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 of 15 sensors are connected together and finally connected to the Atmega 128..Do you have a direct connection without a transceiver?> 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 controller, the output looks fine.. it is keeping on polling and I saw the below 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 sometimes no UART data at all... > > And sometimes though Atmega 128 is polling fine, Atmega 8 is not at all responding.. 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... >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 by ●May 3, 20192019-05-03
On Friday, 3 May 2019 12:55:33 UTC+5:30, pozz wrote:> Il 03/05/2019 08:58, T Obulesu ha scritto: > > I'm getting a strange issue. We have a Atmega 128 controller board that 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 of 15 sensors are connected together and finally connected to the Atmega 128.. > > Do you have a direct connection without a transceiver?Max490 is the chip that controls the transmission and soldered on both ends..> > > > 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 controller, the output looks fine.. it is keeping on polling and I saw the below 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 sometimes no UART data at all... > > > > And sometimes though Atmega 128 is polling fine, Atmega 8 is not at all responding.. 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... > > > > Problems that arise after some hours can be very difficult to debug. > Maybe this issue isn't related at all with UART activity. >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..> 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.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 as soon as scope exits..> > 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. >Clearing the interrupts properly..> 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.Apparently.... the same sensor set up is working in some places... and some other places it is not working... We have implemented this product in Shopping malls...
Reply by ●May 3, 20192019-05-03
On Fri, 3 May 2019 04:16:36 -0700 (PDT), local <obulesu.t@gmail.com> wrote:>On Friday, 3 May 2019 12:55:33 UTC+5:30, pozz wrote: >> Il 03/05/2019 08:58, T Obulesu ha scritto: >> > I'm getting a strange issue. We have a Atmega 128 controller board that 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 of 15 sensors are connected together and finally connected to the Atmega 128..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.>> Do you have a direct connection without a transceiver? >Max490 is the chip that controls the transmission and soldered on both ends..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 by ●May 4, 20192019-05-04
Le 03/05/2019 08:58, T Obulesu a écrit :> > > > > I'm getting a strange issue. We have a Atmega 128 controller board that 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 of 15 sensors 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.... > > >> And sometimes though Atmega 128 is polling fine, Atmega 8 is not at all responding.. 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... >Maybe a stack overflow!!?? -- Les politiciens sont imprévoyants, les électeurs sans mémoire.
Reply by ●May 4, 20192019-05-04
Il 03/05/2019 13:16, local ha scritto:> On Friday, 3 May 2019 12:55:33 UTC+5:30, pozz wrote: >> Il 03/05/2019 08:58, T Obulesu ha scritto: >>> I'm getting a strange issue. We have a Atmega 128 controller board that 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 of 15 sensors are connected together and finally connected to the Atmega 128.. >> >> Do you have a direct connection without a transceiver? > Max490 is the chip that controls the transmission and soldered on both ends... >> >> >>> 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 controller, the output looks fine.. it is keeping on polling and I saw the below 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 sometimes no UART data at all... >>> >>> And sometimes though Atmega 128 is polling fine, Atmega 8 is not at all responding.. 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... >>> >> >> Problems that arise after some hours can be very difficult to debug. >> Maybe this issue isn't related at all with UART activity. >> > 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..**Different?** If so, I'm not surprised the application doesn't work anymore.
Reply by ●May 7, 20192019-05-07
On Saturday, May 4, 2019 at 1:03:55 PM UTC-4, pozz wrote:> Il 03/05/2019 13:16, local ha scritto: > > On Friday, 3 May 2019 12:55:33 UTC+5:30, pozz wrote: > >> Il 03/05/2019 08:58, T Obulesu ha scritto: > >>> I'm getting a strange issue. We have a Atmega 128 controller board that 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 of 15 sensors are connected together and finally connected to the Atmega 128..[]> >>> The problem is.. when I saw the output through the UART on the Atmeg128 controller, the output looks fine.. it is keeping on polling and I saw the below 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 sometimes no UART data at all... > >>> > >>> And sometimes though Atmega 128 is polling fine, Atmega 8 is not at all responding.. it is mute.. > >>>[]> >> Problems that arise after some hours can be very difficult to debug. > >> Maybe this issue isn't related at all with UART activity. > >> > > 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.. > > **Different?** > If so, I'm not surprised the application doesn't work anymore.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
