Flowcode Support Board

Hi Ben

There is still a problem sending string with ESP32 by bluetooth.
If the string is longer than 10 char then bluetooth will crash and hang until a hardware reset.

Strange that sending a byte array of 20 byte with "0" is without problems.

So I have updatet all files from flowcode and use a program with the interupt from the bluetooth (Macro bt_interrupt)
to receive command from a terminalprogram
If I send "p1" the Modul send me back 20Char of "0". this is working very fine and many times without a problem.
But when I send "p6" the Modul should give me 20 char back, but it's crash and hang.
Generell sending string is working, if the string is less than 10 char.

regards

Stefan

That's odd - the SendString code effectively calls PutBytes(temp[1], 1) once for each character - whereas SendArray just sends the entire array using PutBytes(data[n], n).
So they call the same 'backend' code - just SendString calls it (in this case) 20 times with an array of 1 character each time.
Does SendArray crash if called multiple times in rapid succession? (Try SendArray(n[1], 1) - 20 times in a loop?)

Very strange...
One 'kludgy' fix would be to cast the string data pointer to a byte pointer and then call SendArray(data_ptr, StrLength(data)
For example - in a C block:
byte *data = (byte *) FCL_STRING;
SendArray(data, FCL_LENGTH);

Martin

Scrap that - you are sending bluetooth data from within the bluetooth interrupt...
This will probably (read definitely - I'm surprised 10 chars come out) cause things to break!

The interrupt routine should only set a flag that a string has been received (probably keep the comparisons out too). The data should only be sent from the 'main' program.

Something like

If (str_recvd)
if(str == "p1") -> SendStr("Hello")

etc.

Martin

I did a test program...
Which works 'reasonably' well.. I didn't manage to get ReceiveString to work - so I just use ReceiveByte
I'd normally handle EOL (CR/LF) in the interrupt too and just signal a new command if EOL received - here however, I test if the received string has a length of >=2 (so p1 p2 etc work - but if you type p1<enter> in the delay time of the main loop then it'll not be recognized (compare str will get 'p1/r/n'..

And - it 'usually works' . The long print strings work most times - and occasionally 'stop' at a random (possibly) character.

12434098457309Hello world and some stuff - received p1
124340984573092748237
Hello world and some stuff - received p1
1Hello world and some stuff - r

- A flash of inspiration.... I think the esp32 is writing to Bluetooth in a separate thread (or process). So - in the example here - if a receive interrupt occurs whilst the string is being written then the main loop may start a new write - which terminates the current operation.

Should there be a 'blocking' option here (PrintStringWait(str) - no don't call it that or PrintStr(str, wait)

- Some more testing (and typing slowly (and I added str[2] = 0 to limit string length to 2)) - shows that PrintString works okay usually - but occasionally 'stops' early?

Martin

Hi Martin

- A flash of inspiration.... I think the esp32 is writing to Bluetooth in a separate thread (or process)

You are on the right way. Thank you.
I checked the power consumption
When the module is in normal mode, it needs 60mA
As soon as a character is received from the BT, it needs 120 mA. After about 10 seconds the consumption goes back to 60mA.
There is also a blinking LED on the module. This continues to flash even after a crash. So a part of the ESP32 still works
I tried it on different ESP32 modules and it wasn't always 12 chars, sometimes it was more or less. But a string with 6 char always worked, even in 100mSec pooling time. How can flowcode send the whole string at once?
regards

Stefan

Looking at the docs - if looks as if the 'sender' needs to wait for the Bluetooth module to be 'free' before writing data.
The Bluetooth callback function has a ESP_SPP_CONG_EVT with a cong parameter = true then the Bluetooth is 'congested' and the program should wait for an event with cong = false.

They missed a trick not having a 'cing' parameter too?

Martin

Hi Martin

I made a test with the byte array.
I have increased the array to 5000 bytes !! and I can send this twice (or more times) without any problems

Hi Stefan,

Yes - can you try lots of small SendArrays which then mimics SendString more closely...

I had a try at modding esp_cal_bt.c but not sure my version got used in compilation - I'll have a try with the 'cast' fix as mentioned above - though that is a temporary measure.. Hopefully Ben and co. can come up with a proper solution...

Martin

I did a bit more testing...

Sending a string 'multiple times' (with delay)
Works okay with as 1s delay. With a 100ms delay - results are a bit 'choppier'...

Defining an array d[28] = {'a'..'z', '\r\n'"}
Then printArray works well - reducing the delay to 1ms and some 'errors'' do occur. It would seem that PutBytes() doesn't like to be called many times in rapid succession... However, the WDT also kicks in with such a short delay...

Martin

So - I tested a 'cast' version. Printing strings seems pretty stable.. I'd say it still needs a 'delay' (long enough for the 'out' buffer to clear) - but the same can be said for SendArray....
Msrtin