Hello all,
Resolved: https://e2e.ti.com/support/microcontrollers/other/f/908/p/856068/3168820#3168820
Posted some time ago RX buffer array FIFO being truncated exactly at 16 bytes or sometimes slightly > 16x8 but never full size of array buffer. After some debug time it occurs that (for/else if) loop pointer is being reset via (for char[I] size) when the RX 7/8 interrupt occurs breaking the NonBlocking loop counter char[I]. Therefore the full extent of RX buffer or input string being sent most always gets truncated for strings (>16 hexbytes) breaking up the RX data string into two commands versus one command followed by specific data.
The new challenge further increases the RX string size 32 Hexbytes which under no conditions can be truncated, must remain seamless. That is mainly due to how host command interpreter must have all argument array data present prior to passing and converting 16 bytes as strings into application variables as decimal integers. Secondly we can not have RX handler mode Blocking (while) loop holding up the entire application in the process. So the NonBlocking (for) loop must remain contiguous up to the size of char[I] set by buffer array size.
Now that the cat is out of the bag, what to do as WA to stop buffer truncation?
Note: Null termination of strings is typically an internal application method not so much for serial transmissions over wire. So the longer 32 bytes DATA string now has bang char '!' every two hex bytes since the vendors compiler gets bitchy about adding '\0' every two bytes. Secondly Rx commands begin with 'p' and end 255,255,255 without '!'. You may ask why '!', obviously converting hex values to decimal via two bytes is shorter, faster and easier to debug than sending very long string/s of ASCII decimals.