mesh serial problem , robust issue ,bug?

[ycp]

hi, nordic engineers

  Now I am using the meshSDKv3.1.0 ,nrf52832 . When i test the mesh serial module , it seems not so good, is it a problem?

 reference to the documents , to test it i send buffer   like below:

1.The first byte is the length of the uart buffer (length-1) ,when receive the right number bytes ,it works good.

 2.But if send the wrong count , or the first byte value is not equal to the actual count of the buffer ,it seems Stuck .

    Send the right buffer again  ,it can not continue run ,this is deathful problem.

3.When send buffer  a bit fast , it also stuck.

do nordic have found this problem ?can you help me?

  ERROR_CHECK(nrf_mesh_serial_init(nrf_mesh_serial_app_rx_cb));

[Bjørn Kvaale]

Due to Easter holidays, response time is a bit slower on DevZone. Sorry for any inconvenience caused. Regarding your question, the mesh serial example works out of the box with the interactive python script, like mentioned in the documentation. 

For your own testing guidelines, did you consult this documentation? Could you please explain a bit more in detail how you set up the testing, which command(s) work fine & which command(s) lead to errors?

[ycp]

no,  I have used the python script to test DFUaready , now I follow this serial format doc ,

and test result is like below:

----------------if send this right format buffer, it is works as i want ,

1c 20 aa 18 03 01 01 7B 22 70 6C 75 67 5F 73 74 61 74 75 73 22 3A 22 6F 66 66 22 7D B5

----------------if send this wrong format buffer, it is not works as i want , and stucked

1c 20 aa 18 03 01 01 7B 22 70 6C 75 67 5F 73 74 61 74 75 73 22 3A 22 6F 66 66 22 7D

--THE only different is the longth of the payload , and i send the right buffer again , it can not run again .what i want to know is the mesh serial module can fault-tolerant ? if not , what should I do to implement this feature?

[Bjørn Kvaale]

Are you able to send the right buffer length two times in a row? Or is it only when you send a wrong buffer length that the serial example stops working correctly? Have you tried adding more logging information to see where the error is occuring? Maybe it's in the serial_packet_buffer_get() function inside serial.c?

[ycp]

1.able to send right buffer 2 times ,send wrong buffer stops. 2.the function char_rx_simple() in serial_bearer.c take the first byte as the buffer length ,is this the reason cause the stops ?, will it always wait the bytes not  recived yet? 3.when stops , i send more buffer ,it will print "No handler for 0x%02x\n" in serial.c in function serial_process_cmd();

[Bjørn Kvaale]

Very sorry for the delayed response. 

ycp said:

the function char_rx_simple() in serial_bearer.c take the first byte as the buffer length ,is this the reason cause the stops ?

It may be. Have you tried to add more logging to see if this is where the serial stops?

ycp said:

will it always wait the bytes not  recived yet?

 You end the reception in char_rx_simple() once the whole package is received:

    if (NULL != mp_current_rx_packet && *p_rx_index == packet_received->length + 1) /* We have received the complete packet */
    {
        end_reception(p_rx_index);
    }

Are you wondering whether there is a timeout if the whole package is not received within a timeframe?

ycp said:

3.when stops , i send more buffer ,it will print "No handler for 0x%02x\n" in serial.c in function serial_process_cmd();

 It seems that the for loop does not enter the if statement 

if (m_cmd_handlers[i].range_start <= packet_in.opcode &&
                m_cmd_handlers[i].range_end >= packet_in.opcode)

because the handled boolean does is not set to true.

[ycp]

Bjørn Kvaale said:

Are you wondering whether there is a timeout if the whole package is not received within a timeframe?

yes, it is exactly what i want .is it have a timeout? how long?can i custom the time?

[Bjørn Kvaale]

Sorry for the delayed response. No, I do not believe there is a timeout. Have you checked what the packet_in.opcode value is for the transfer that did not work (i.e. 1c 20 aa 18 03 01 01 7B 22 70 6C 75 67 5F 73 74 61 74 75 73 22 3A 22 6F 66 66 22 7D)? 

if (m_cmd_handlers[i].range_start <= packet_in.opcode &&
                m_cmd_handlers[i].range_end >= packet_in.opcode)

does not check the length of the packet, so maybe something there could also be wrong? If you print out the packet_in.opcode value & packet_in.length, do these values change or are they similar from the different received packets.