Planner buffer error

I have not heard this one before, but then cnc.js is much more aggressive in displaying returned (from tinyG) status and error messaging.

A common issue with tinyG and Arcs is end point errors due to lost precision in the 8 bit math environment.
Is your Gcode in inch or mm? MM runs with better precision, due to fewer mm to inch conversions.
You might also try generating your Gcode without arcs (will use short linear segments)to see if that Gcode runs.

Have you browsed the tinyG wiki at https://github.com/synthetos/tinyg/wiki ?

For possible methods to modify the buffer allocations, I’ll suggest to post at https://github.com/synthetos/tinyg/issues where the developers pop in on occasion and heavy modifiers share ideas as well.

From the serial console, sending $ct=0.01 should work.
You can read back (manually verify) by sending a $ct
See https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97#ct—chordal-tolerance

The typical default setting is $ct=0.01 mm.
Any reason why yours is set to 0.001 ? (mm, I assume)?

Google can be your friend for lots of discussion “tinyG acc specification error”

The root cause is the accumulation of math errors running in the 8bit machine accuracy of the underlying computing hardware. Because tinyG does all it’s work in MM’s, and has to do numerous inch to mm conversions when working with inch Gcode, many folks find that simply exporting your G code in G@21 (mm) notation resolves the issue.

It is not an issue with the number of significant digits of precision in parameters

Another option is to tell your G code generator to no use G2 or G3 moves (arcs). This will create much larger Gcode files as curves are represented as multiple short segments in Gcode

Google around a bit, others have tried techniques that might work for you in your tool environment.