Correct. However, limit cycles only occur in fixed point processing. It's not a practical issues for floating point processing.
Let's ignore these for now. If you have overflows, you need to fix them anyway, limit cycles or not.
is there any way to predict if this errors can occur knowing the coefficients of my filter
Yes and no. Limit cycles depend A LOT on the exact implementation of the filter. Things that matter the most is the topology of the filter (Direct Form I, Transposed Form I, etc.), the bit depths of the state variables, coefficients and data, and most importantly on the exact way that rounding is implemented. Let's say you multiply two signed 8-bit numbers. The result has 15 bits so you need to throw 7 bits away to store the result in an 8-bit location again. That's typically called "rounding".
There are an astonishing number of ways to implement rounding. For a full overview see https://en.wikipedia.org/wiki/Rounding
The most common ones are
- Truncate of "floor": just discard the lower 7 bits. Choose the next smaller number. This is the "default" behavior in many programming languages.
- Nearest neighbor: round to the nearest number
- Nearest neighbor with zero bias: see Wikipedia, it's a bit complicated.
- Round towards zero: Always make sure that the magnitude of the rounded number is smaller than the actual number.
"Round towards zero" is guaranteed to eliminate limit cycles. However it also generates 6 dB more quantization noise then the "nearest neighbor" options. So it's a tradeoff.
Limit cycles are a combination of the exact implementation of the filter PLUS the filter coefficients and (to a smaller extend) the input signal as well. Filter coefficients alone are not enough to predict limit cycles, you will also need a bit-exact simulation of your implementation.