Start a new topic

bkcmd=0 Nextion reply

I've set bkcmd=0 but I still receive various errors such as 1A FF FF FF.

Doesn't bkcmd=0 completely stop any error replies from Nextion or is there a catch?


Hi Andrew,


There is a little more information needed

Which version of Nextion Editor?

 - where did you set bkcmd=0?

     and where else did you set bkcmd

 - is this still Intel Studio and Edison with noise issue or other


Default power on default is 2 - returns failures 0x02 through 0x24

Things like Iteadlib NexHardware::nexInit()

  - sends bkcmd in the nexInit() procedure

So on Nextion, set bkcmd in preinitialize of page

    can be undone in Arduino setup() nexInit() call.


But bkcmd once set to 0 ignores such important things

   like the fact the last command was calling non existent

   variables/components and/or their attributes and will

   not send a 0x1A failure status until rebooted and the

   power on default is once again 2.


Checking the value of with a get bkcmdÿÿÿ sends

   0x71 0xAA 0x00 0x00 0x00 0xFF 0xFF 0xFF

   where 0xAA is the current setting of bkcmd.


it is possible if noise is still present, that intended

   bkcmd=0ÿÿÿ sent is not received at Nextion intact.

There is nothing which you could call 'noise' on the Edison TX when my SHT sensor is working.

There is actually genuine data on the TX, normal width signals. It's like the same data is simultaneously sent to the sensor and UART.

To avoid any consequences for Nextion, during a request to the sensor I do the following:

before calling the sensor function, I send these commands to Nextion:

com_stop

code_c

Then I call the sensor function which begins to transmit uncalled for data onto the Edison TX.

After I receive data from the sensor, I send these commands to Nextion:

0 0xFF 0xFF 0xFF (to close the received bogus data in the Nextion buffer)

com_star

I imply that I shall not receive any possible error messages from Nextion in this case and will therefore exclude any effect of the illegal UART transmission on Nextion.

Is my strategy correct or am I missing something?

I don't even think I need to set bkcmd=0 in this case...


Okay - let me reiterate this back

 - no noise on Edison TX, line looks clean

 - occasional noise on Edson RX line

    - side effect Edison receives bogus 0xFFs 0xFCs

      and real data somewhere in the mix.


So I think that you are not understanding the "noise"

try this:

   iterate 100 text and number assignment commands to Nextion

   t0.txt="<long phrase>"ÿÿÿ  or n0.val=<large number>

     where <long phase> and <large number> are above average length

     and where you can verify what Edison has sent has arrived intact.

If your 100 iterations are clean without error (I presume they are)

   then this issue isn't about having Nextion stop processing its RX


Nextion's RX is Edison's TX - there isn't an issue here.

  And if there was a 2ns spike on the wire - it is Nextion receiving

  ... in which the noise is more than likely discarded in handling.

     (Nextion uses an STM32 / GD32 USART module)


com_stop = stockpile incoming bytes from Edison

code_c = disregard all unprocessed serial commands NOW

com_star = resume normal processing.


So in essence, you tell Nextion to ignore Edison

 - bkcmd=0 seems to have been discarded in the code clearing.


You still have to deal with your receiving and yes, it has noise.

   Nextion TX to Edison RX ... has some 2 ns noise.

This equates to a "big_fat_so_what".  Deal with it and be done.


Now again, like as above the TX side (Nextion) is not effected

by noise on this line.  But the RX side (Edison) really is


As stated before

  your phantom byte is occurring from falling edge

  not because there is really a byte coming in

  but because the handling procedure is not expecting a spike

  and has no precautions taken in case line was ever noisy.

  ONCE this procedure starts, it finishes even though at more

     than one spot it should have discarded the byte

  BUT NO ... it puts the fake byte into the buffer anyway


So as the 2 spikes appear to only be 2 ns wide

  then placing the filter on what is coming into the Edison

  RX line would be able to trim those away (Intel's suggestion)

  (assuming the noise is actually on the physical wire)

If the noise is originating elsewhere then filtering will have

   no effect as the noise isn't on the physical wire between

   Nextion's TX and Edison's RX.

This is really dependent on accurately interpreting the

   observations made by your Logic Analyzer and nailing

   down where the real source of the noise comes from.


However, on the software side this can also be solved.

Oversampling is the polling of the value of serial 16x per bit.

  pseudo on the other thread

At 2 ns wide noise, the odds of reading exactly when noise

spike occurs is indeed lessed.  The averaging of the other

15 samples rule the noise out.

 - Just need an interrupt and logic (pseudo in other thread).


Now shutting off bkcmd I think is in the wrong manner.

People should really be cranking it up to bkcmd=3

  and by doing so solve many timing issues.

Don't send new until result of last as been received


In this manner, there is little to zero chance of buffer issues


Patrick, if you're interested, take a look at another guy who's been receiving garbage on his Edison:

https://communities.intel.com/thread/116305

Now, you didn't correctly understand what's going on. I'll try to elaborate using your own scheme:

-There is a SHT10 sensor and Nextion display connected to Edison.

-There is nothing on Edison TX and RX.

- I send a legal command to Nextion and then I receive the "2ns multiple 0xFF" reply onto Edison's RX.

- Among them, there is a legal Nextion reply, if a reply was necessary.

     (Nextion's reply is intact and there are no 0xFFs in between, only before and after.)

- Silence on Edison TX and RX.

- I call update_sht1x

- During and after this update, Nextion receives normal, genuine data, which I didn't send (see enclosed file). After 0.2 seconds this illegal transmission ends. Then the Edison RX gets the 2ns 0xFF noise data again.

- Silence on Edison's TX and RX


Simply put, after every legal and illegal transmission to Nextion, I get the noise effect on Edison's RX.

During sensor updates, I get illegal, real data transmissions on Edison's TX.

zip

Hey Andrew


I assure you I am getting the issue here

A step by step procedure to solve it  ... remains the missing part.


When comparing apples to apples

  - ALL factors remain the same

  - someone else attempts to recreate your experiment exactly

    (or as close as is humanly possible)

  - FerryT confirmed SHT can produce false bytes on TX.

  - Others have analyzed your Logic capture

     this noise does indeed exist - so you're not crazy.

  - Others CAN have the phenomena - again, not crazy.


What happens when this 2 ns spike occurs is

     the 2 ns noise is triggers a routine

        the routine is continuing without validation of data

        the routine at the end of time (bps x10) dumps reading

           - byte on RX or byte on TX

     the 2 ns noise is NOT a byte of data

        verified by Logic capture.

     Edison side is responsible for this, code or hardware.

Commonality is libmraa, actual or merely correlation.


Now when you CHANGE the conditions of the experiment

  - you end up with more observations

  - but this CHANGE creates a new condition, NEW experiment

  - more experiments that others need to attempt to recreate

  - new observations provide data that helps narrow down cause

But your NEW experiment without notice to others and replication

    does not create a lack of understanding by the others


What do we know

    cause of such a short (2 ns) flux CAN be caused by Edison

    it can also be caused by ANY number of other sources

    Wire connected to Edison CAN become an antenna

       EM signal captured by wire CAN create

    But in reality, CAN be coming from almost anywhere.


But we also know a 2 ns duration is a 500 MHz frequency

   We know that Nextion valid baudrates range is 2400 to 115200.

    - so 500MHz is well beyond the upper end of 115200.

   therefore it is worth while to explore putting low pass filters on

    - such that the max frequency becomes less than 500MHz

   If low pass becomes such that highest allowed through is 1MHz

      then such 500MHz becomes ignored - with 2ns having no effect.

So Intel's suggested low pass may be solve for your issue.

   or not, filter should be between source and Edison,

      so if Edison SoC is source .... then software to solve.


But we also know that

  - that issue does not exist on all kernels

  - and that some do not get issue when using gpio over libmraa.

So some have solved this issue by moving away from libmraa and kernel

 - as such digging into why libmraa seems to be contributing factor ...

  a) you can see logic in that someone who no longer has libmraa can not test

  b) you can see logic in that someone who no longer has issue can not nail down source.

 - so because of these two factors, the issue persists without public solution


What avenues are available?
  - the entire source code of kernel and libraries are available

  - the tools to create new kernels exist

  - source code of most libraries (open source) exist


As Edison is an Intel Atom dual core with Pentium MCU

  - this is an Intel chip, using the Intel instruction set

Therefore a 32 bit x86 Linux on VM (Centos 5, Redhat 8.0, etc)

    can be used to produce a binary that can be copied to Edison

    and such binary will indeed run

 

The paths to seek a solution are near endless

  - most solutions may not include using libmraa

  - some solutions may not include using the default kernel

  - most users picked a path and were on their way

    for these folks libmraa is a distant memory.


What I don't have is a step by step procedure for you

   that includes using libmraa in Studio


But I certainly understand how the noise is erroneously translated into a byte

  - routine triggered from falling edge without any validity checks.

Most UART implementations would have ignored this 2 ns noise

   and tossed it out when the width didn't hold to start bit definition

   and noise would have been averaged out with oversampling.


On Intel's forum I'd ask you to find out what your actual IO pin configurations

  are set at before, during and after erroneous noise bytes

This can not be answered with how you asked libmraa to do for you

   it requires digging deeper (/sys/class/gpio and read out the subfolders and files)

Indeed if misconfigured, could be a cause of jitter - worth investigating.

   

Here on the Nextion forum, other Nextion users have little experience with Edison

   you will not have much chance for Nextion users to find your answers

On the Edison forum, there is little time remaining, and I am sure fewer wanting

   to dig in for a "horray! we finally solved it" after it's closed.


QUESTIONS

  - what was the result of using the low pass filter.

  - you stated illegal transmissions from Edison TX (can not be on, its outgoing)

    test - setup a Nextion waveform and issue addt command

             I am less convinced any data points will be added as USART will probably

             eliminate as invalid.

  - are you certain Logic is not contributing to noise factor?

Hi Patrick!

Kirill and I have registered on the new Forum you kindly invited us to at nextion.itead.cc


Login or Signup to post a comment