new uart driver and acessing flash boots the system

[ESP_Angus]

Good news first, I tried with the new definition and it doesn't crash anymore.

Great news, thanks. We'll get this fixed in the esp-idf master branch soon.

Bad news is, got a new not reproducable problem.
After holding down a key for some time, pressed a different key, but this newly pressed key arrived with delay of some clicks.
To make it easier to follow, pressed "a" for some time, and got a lot of "a"
Next pressed "bcdef" and got "aabcd"
Same happend 2 more times, but now its gone

if i run from a terminal prog 1000 times like this
example strings..

Code: Select all
comport1.writeln("Testing the RingBuffer, and HW Fifo\r\n");


the things are perhabs 880 times done and response.

I'm not sure these are the same issue, although they sound similar.

Rudi, I'm reading that if you send a lot of serial data then you are not seeing all of the data appear when reading back? Are complete lines missing, or random chunks of data? If you lower the baud rate then do you lose less data? It's possible that the UART FIFO is overflowing and dropping bytes.

JumJum, it's hard to know exactly what this bug is - is it possible the last two "aa"s are arriving late, or are they duplicate "a"s that should never have arrived at all?

I'll mention these issues to the driver development team, hopefully they can try some tests sending large blocks of data.

[rudi ;-)]

if i run from a terminal prog 1000 times like this
example strings..

Code: Select all
comport1.writeln("Testing the RingBuffer, and HW Fifo\r\n");


the things are perhabs 880 times done and response.

I'm not sure these are the same issue, although they sound similar.

Rudi, I'm reading that if you send a lot of serial data then you are not seeing all of the data appear when reading back? Are complete lines missing, or random chunks of data? If you lower the baud rate then do you lose less data? It's possible that the UART FIFO is overflowing and dropping bytes.

JumJum, it's hard to know exactly what this bug is - is it possible the last two "aa"s are arriving late, or are they duplicate "a"s that should never have arrived at all?

I'll mention these issues to the driver development team, hopefully they can try some tests sending large blocks of data.

hi Angus
txs

first answere:
yes - there are missing data when reading back.
there are complete lines missing too Angus.
i feel like , the (ring) buffer is full and then if i send again a lot of data, then the hw fifo ovf comes.
i do this with 115200 baud, have test with 57600, 9600 but with 57600 and slower there are more data missings..

what i did:

BASE:

- 115200 baud
- sending only one CHAR without \r\n with each send command

send 'request' command is example:

comport1.send('A');
or
comport1.send('B');
or
comport1.send('C');
or
comport1.send('Z');



one period for check the regsiter is example:

comport1.send('A'); // Read Value form Register
// optional
// delay(user_ms);

comport1.send('B'); // Write bit to the Register
// optional
// delay(user_ms);

comport1.send('A'); // Read Value from Register
// optional
// delay(user_ms);

comport1.send('C'); // Clear bit from the Register
// optional
// delay(user_ms);




example "check Power"

comport1.send('Z');

read the CAN_CLK_EN and CAN_RST Register
response then CAN POWER : disabled example

example

comport1.send('A'); // Read Value from Register
comport1.send('B'); // Write bit to the Register
comport1.send('A'); // Read Value from Register
comport1.send('C'); // Clear bit from the Register



part1:
------------------
- without Delay
- example 100x


response:

0: RegVal = 0
1: RegVal = 1
...
...
143: RegVal = 1
--------------------
144: RegVal = 0

01.png (21.59 KiB) Viewed 6733 times

usually here must come the last IDX Counter with 199
100 x 2 ( reads ) start with 0 = 199

198: RegVal = 0
199: RegVal = 1
--------------------

here are missing the response data
(lines with \r\n at end) from 145..197

and now the strange:
if i send now manually a command

example "check Power"

comport1.send('Z');

then the "buffer" is move the missing data line for line
and if all missing data now response,
then comes the data for the new command ( "check Power" ) ,

the pulse of new command is like a "clock"
to shift out the missing data line for line

after all missing data are response,
then comes the new command response

but here the same, the missing data from pulse the
first missing:

for each pulse with new command was response the missing
data from first,
but has not response the new new command ..

comes with new pulse with a command...


more testings then was, to send much much more
data 1000x times

now the hw fifo err comes with ovf

i try to reset this hw fifo..

then comes the ringbuffer err

i work on this to understand this better


------------------------------------------


i change this now like this:

i put a delay between each comport1.send
the delay was done with 1ms

result now:

- no hw fifo err comes
- no ringbuffer err comes

100x
the response is ok and like it must

900x ( 900 x 2 reads = 1800 - 1 = IDX 1799
the response is ok and like it must


0: RegVal = 0
1: RegVal = 1
...
...
1798: RegVal = 0
1799: RegVal = 1
--------------------

02.png (24.05 KiB) Viewed 6733 times

1000x ( 1000 x 2 reads = 2000 -1 = IDX 1999
the response is not ok, and like this:

0: RegVal = 0
1: RegVal = 1
...
...
1898: RegVal = 0
1899: RegVal = 1
---------

( see last picture left side "1000 x " )


there are missing 11x char '-' from the line
and the \r\n at end

then is missing the data

1900: RegVal = 0
1901: RegVal = 1
--------------------
...
...
1998: RegVal = 0
1999: RegVal = 1
--------------------


pulsing with an other command is not helping to response
the missing datas..

( see last picture in the mid "check Power" )


FYI:
the processing ( counter IDX ) for the missing datas
is done on the ESP because if i send a manually command
like

comport1.send('A'); // Read ...


the idx is response with the next "right idx"

2000: RegVal = 0

( see the last picture right "Read a single command" )

and so on

hope this helps
and yes, i reset allways for each procedure the esp,
so all is start from same begin and empty buffers and so on.


best wishes
and thanks for help!

rudi

03.png (35.51 KiB) Viewed 6733 times

[jumjum123]

Some more information from my side,
I've

Code: Select all

 added spi_flash_erase_sector(0x100000 >> 12); 

after writing input character back to console.
This was done to come close to my first testing, where this missing chars came up.

Next created a string with 70 char.
Copied this string to putty, and everything was written back, that worked fine
Then pushed button "a" for some time, and charater "a" appeared 64 times.
Next typed b,c,d,e,f,g,h and got a,a,a,a,b,c, (commatas have been added for better reading, they have not been typed)
Typing any other characters brought missing chars d,e,f,g,h, they are not lost, they are still somewhere.

After testing this many times, this seems to happen after around 50 chars.
Once again, sending 50 chars and more as one string worked fine.
For me this looks like sending chars with a "magic speed" causes this behaviour.

[jumjum123]

I've added uart_flush(uart_num) after uart_write_bytes(.....
Tested this for some time now, error did not come up anymore

Would there be anything wrong with this solution ?

Code: Select all

void uart_flash_task(void *pvParameters)
{   int uart_num = (int)pvParameters;
    uart_event_t event;
    int len;
    uint8_t dtmp[1000];
    for(;;) {
        //Waiting for UART event.
        if(xQueueReceive(uart0_queue, (void * )&event, (portTickType)0)) {
            switch(event.type) {
                memset(dtmp, 0, sizeof(dtmp));
                //Event of UART receving data
                case UART_DATA:
                    len = uart_read_bytes(uart_num, dtmp, event.size, 10);
                    uart_write_bytes(uart_num, (const char*)dtmp, len);
		    uart_flush(uart_num);
                    break;
                default:
                    break;
            }
       }
    } 
}