The only reason I could think of is that the variable used for flash offset is uint16 and it wraps around at 65536. The write offset needs to be a 32-bit variable. Can you check this?

That was exactly it.  Rookie mistake.  Thanks, Jaakko!

Value 0xFE is used to indicate "timeout". It's not part of the Mesh specification but an additional status code used by our mesh stack.

If you get a `evt_mesh_prov_config_status` event with status 0xFE you should simply send the last command again (e.g. call cmd_mesh_prov_model_app_bind() again)

Occasionally I see status codes of 254 when receiving an `evt_mesh_prov_config_status` event on a node trying to provision another node.  Where can I find documentation for these status codes?  It's not clear to me where this lines up with any docs from the Bluetooth SIG.

To follow-up, the summary of status codes in section 4.3.5 of the Mesh Profile specification v1.0 lists 0xFE (254) as reserved for future use.  Any idea what may be causing this to come out of a provisioning node?  It specifically happens during vendor model binding.  I also haven't found a way to reliably reproduce this issue.

To follow-up, the summary of status codes in section 4.3.5 of the Mesh Profile specification v1.0 lists 0xFE (254) as reserved for future use.  Any idea what may be causing this to come out of a provisioning node?  It specifically happens during vendor model binding.

Occasionally I see status codes of 254 when receiving an `evt_mesh_prov_config_status` event on a provisioning node.  Where can I find documentation for these status codes?  It's not clear to me where this lines up with any docs from the Bluetooth SIG.

Thank you.  The driver libraries don't obviously expose this feature.  I should be able to write my own wrapper around the init/configure functions to take advantage of these control bits, though.

Based on the reference manual, it looks the USART/LEUART support invert, 

search and try the word TXINV in the reference manual.