Sending commands over BLE instead of USB/USART using Nordic Semicondcutors nRF52832DK

Well, I think you're spot on with using jshPushIOCharEvent. Did you try removing that call and seeing if you can still hardfault the chip while sending lots of data if Espruino isn't processing it? It could be that it's some buffer overrun when you're calling Nordic's library?

Also, when the chip hardfaults you can often still access the call stack - it might help to see where it's going wrong.

Could it just be some issue with transmitting at the same time as receiving? You could try using your existing Serial implementation and Transmitting on Serial while receiving via BLE, and vice versa - it might help to narrow it down.

The other issue might be that Espruino is filling up the output buffer and blocking? When you send data without an echo(0), Espruino echoes the data back to you, plus a few extra bits (the > at the beginning of the line for instance).

There's actually not much info about the internals at the moment. I'm doing a talk at Fullstack in October where I'll dive into that a bit more, and I hope to put that all online.

Basically though, Espruino communicates with the world via two Queues:

• ioBuffer (jshPushIOEvent/jshPopIOEvent) - Events (watch events or serial data) gets pushed onto this from an interrupt, and pulled off in the event loop. If you have too many of these, events just get dropped.
  
• txBuffer (jshTransmit/jshGetCharToTransmit) - characters transmitted from the Espruino event loop, and then sent on interrupt. If too many chars are sent, jshTransmit will block (as it knows than an IRQ will slowly empty the queue).
  
  
  

The only important thing is just to make sure that you don't access wrong side of the queues from an IRQ (and don't let one IRQ interrupt another IRQ in the middle of accessing the queues). I doubt it'd hard-fault, but you'd lose characters all over the place.