Serial1.println does not always send data... And the console still jumps to serial by it self..

The MDBT42Q module is connected to a device via the usart pins, this device keeps sending data in a cyclic manner. Part of my project is to parse that cyclic data.
The other part is that I at an intervall has to send a string to the device to make it print extra info.
I have now added code for sending the string when the button is pushed, and at an intervall. Both events work fine, the function print a message on the console just before the string is sent on the serial port.

But, every now and then the device just stops sending on the serial port. There it nothing on the pin. I have an analyzer connected on the same pin so I know that it's silent.

This tends to happen after an upload, and then it stays in this state for X amounts of uploads and or reboots. I have still not found a way to trigger it or to fix it, its random at the moment.

I have also noticed the console sometimes jumps back to the serial port, even though it should not. This can be a problem as the espruino tries to interpret data not ment for it... The console should always be bluetooth as the serial port will always be connected to the device.

I have attached the code, please mind this is just a scratch testing thing to get to grips with the device and test what and how to do this.... :-)

1 Attachment

• code3.js

So I might have solved this one.
If I do a reset() before doing an upload to flash in the webIDE it always seam to work.

I think you are mixing two ways of running code at startup. there is the E.on('init'... which is useful with method save(). This is (older?) simpler way - you set various things and then run save() and everything is magically saved and restored on boot (if you are lucky :-).

Then there is another (IMO more deterministic and more transparent) way of never ever using save() method and just saving to flash via button in IDE that will produce .bootcde and/or .bootrst files. Those files run from the beginning so you don't need to call E.on('init'.. like when using save() but you simply run the stuff directly from top to bottom.

Depends on you which way you prefer but mixing both may produce unexpected results.

In the code you linked above the stuff in E.on may actually run as last thing at startup after all your code below it, maybe that's not what you want? see the order in https://www.espruino.com/Saving#boot-process

Thank you for that, I re read that page and I'm starting to get to grips with how the device works.
I moved everything in the E.on to just after all the functions, this seam to be a better way of doing it.