Hello,
during using freemaster recorder i noticed a problem. When the observed value is 2 bytes signed int, and it is selected for the recorder trigger with threshold lower than -8192 then it cause the board resets.
After debugging, i suppose, that problem may be on freemaster side. When i look into communication logs, i can see something like on picture below.
I guess, that in red box is size of the number. Looking on source code of the freemaster on microcontroller i think, that it is used for example for selecting comparison function.
In green box is threshold encoded in LEB128.
Going to freemaster code on the microcontroller to initialize recorder we can find the line:
As we can see, decoder as size takes number obtained from the from PC tool. constThresholdPtr is pointer to an 8-byte array that can keep decoded threshold. It is placed in freemaster_rec.c file.
Next thing is going to decoder:
As you can see we can go into FMSTR_LebDecode. Our arguments for bug example (threshold -8193 ) are: in buffer with bytes [FF BF 7F], result - pointer to array of 8 bytes, size - 2, sleb - true.
I will skip precise description how most of decoding will be take place. In do .. while loop it iterates twice (because two bytes have MSB bit set), always decrementing size.
So when we go to line 569, we have b = 7F, sleb = true, and size =0.
In 571 we have false but decrement size value, what cause underflow and size turn into (2^32)-1. In that case, while loop (576) start filling memory with 0xff.
Have you encountered this problem?
Solved! Go to Solution.
Dear Rafal,
thanks for your report. We were solving this issue for MCUXpresso SDK 2.10 back in 2021/2022 - It may happen you are using older code. I'm sorry for this.
Your analysis is correct, though. This is the fix needed in the FMSTR_LebDecode:
Thank you,
Michal
This solution helps.
Thank you very much!
Dear Rafal,
thanks for your report. We were solving this issue for MCUXpresso SDK 2.10 back in 2021/2022 - It may happen you are using older code. I'm sorry for this.
Your analysis is correct, though. This is the fix needed in the FMSTR_LebDecode:
Thank you,
Michal