Wrong trigger in UART protocol

rlugli

Thu, 08 Dec 2022 16:45:55 GMT

Playing with trigger capabilities of the UART script I found a serious problem concerning trigger steps. I wanted to trigger on a single 0xFF single byte using ScanaStudio 5.0.9Beta and UART script V1.55 with an SP209 (S/N 000254). Looking into the log window, I can see that the sequence associated to this trigger configuration is a two steps sequence: [Log](//muut.com/u/ikalogic/s1/:ikalogic:crVW:log.jpg.jpg) Such a trigger's step sequence cannot trigger only on a 0xFF byte since the FlexiTrig engine will probably stop on every byte with a positive edge after the start-bit. In case of protocol with LSB first every byte with the LSB=1 will be accepted. For example a byte 0x81 fulfills the requirement as you see in the picture below: [Bad_Trigger](//muut.com/u/ikalogic/s3/:ikalogic:OhfH:bad_trigger.jpg.jpg) Just looking at the edges in not enough to to escribe in a unque way a UART byte like 0xFF. In my opinion, an additional information should be added somehow. The Stop-bit (i.e. a bit with polarity opposite to Start-bit) must be detected after 8 bit-periods. Sampling correctly the Stop-bit is crucial for detecting the byte pattern correctly wit h a UART protocol. How is it possible to instruct the FlexiTrig engine in order to correctly trigger on the UART byte 0xFF? I could imagine that looking at the next Start-bit edge would be a possible solution but what to do if the 0xFF byte to capture is just the last byte of an "isolated" UART frame? Thanks in advance and kind regards. Roberto

rlugli

Sat, 10 Dec 2022 23:35:34 GMT

I made a change to the original UART script in order to trigger the 0xFF byte correctly. I added a final trigger step in order to trigger the next status falling edge. Unfortunately I found another erratic behaviour. Here is my first attempt with a three trigger steps sequence . Serial stream is 115200 kBauds (bit period is about 8.68e-06): [Bad_Trigger_2-0](//muut.com/u/ikalogic/s3/:ikalogic:pjrA:file_0bad_trigger_2.jpg.jpg) The last step with a Tmin constrain at about 74us should prevent the trigger on the falling edge just one bit afte the rising edge. I cannot understand why the FlexiTrig engine triggers on the first data-bit of the 0x81 byte. Is this normal or the FlexiTrig engine is not processing correctly the last step of the trigger sequence? Everything works fine when I change the third step adding both Tmin and Tmax constrains. Since the UART communication has no inter-bytes time gap it is possible to catch the start bit of the following byte. [Trigger_ok-0](//muut.com/u/ikalogic/s3/:ikalogic:7AjL:file_0trigger_ok.jpg.jpg) Can anybody help me to understand this behaviour? Thanks and regards. Roberto

rlugli

Thu, 15 Dec 2022 09:59:34 GMT

I apologize because the last picture had the log window not scrolled to the bottom. It still reports the wrong trigger steps. Here is the updated picture with the correct log window: [Trigger-ok](//muut.com/u/ikalogic/s3/:ikalogic:wkOK:triggerok.jpg.jpg) Sorry...

Ibrahim KAMAL

Mon, 19 Dec 2022 13:32:44 GMT

Dear @rlugli, Thank you for all those suggestions. We'll work on UART trigger definition accordingly and update the protocol script. Thank you,