does MPU6050_DMP module work on Puck?

I'd like to be a bit more specific about the general type of upload vs. the various kinds of uploads in Espruino context.

The general type of upload is to move bytes from a source environment storage to a destination environment storage. On both source and destination sides, a simple read and write tooling is in place that just reads the bytes and puts them on the line or gets them from the line and just writes them - without any serious transformation - like a file transfer. If the 'file transfer' has some smartness, it knows about the data type and may do some formal conversion, such as a character set conversion, endian conversion, etc.

Any conversion though is the begin of heating the water and because it is gradually, it will boil the frog - what ever that 'boiling the frog' means and manifests itself in... for example with: New Interpreter Interruption / Stack Overflow / Out Of Memory / Fifo Full / ... because of: see next paragraph.

In Espruino, neither side's tooling - source-reading-sending nor destination-receiving-storing - is simple.

On source side it is parsing code in nested, recursive manner to find all - not Espruino firmware built-in, involved modules and upload them to and store them either as source code or function in the Modules cache or flash EEPROM before uploading the actual root / level 0 code / IDE editor pane code - the code that is stored in the projects folder. The parsing is recursive because not only the 'project' / level-0 / project code can contain require(), but also modules can contain it.

On destination side the code goes thru the interpreter which does some parsing and processing as well - depending wether it is project and module code, and when latter wether to store it as straight source code or as function. If that processing gets too heavy, the upload process may fail. While all code code arriving on the Espruino interpreter side, some is 'just' definition code, like a function(){ ...} which is 'just' rudimentarily processed before being stored, other is heavily processed and may even get the application aprocess started, such as variable declarations, value assignments, and function calls in level-0 / directly executed code.

When having heavy active code in the upload and lots of code to upload, timers that are early on created by setTimeout() or setInterval() - and console.log() - may already be firing even before all code upload has completed. Too early firing may collide with upload communication content and timing, like application output to console interferes with upload because for both the same console connection and REPL is used, and timing wise, cpu resource is divided between performing upload task and and executing application code.