Skip to content

Library Crashed with UART input #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
phantom-8 opened this issue Apr 9, 2019 · 14 comments
Closed

Library Crashed with UART input #6

phantom-8 opened this issue Apr 9, 2019 · 14 comments

Comments

@phantom-8
Copy link

phantom-8 commented Apr 9, 2019

I'm using the VL53L1X library in polling mode on a stm32 F1 (blue pill). The system would hang if I use the library together with UART input. The library works fine if I'm not using UART. I've tested all 3 UARTs and they all exhibit the same problem.

To reproduce the problem, do the following to a simple test program which uses VL53L1X library:

  1. Connect the stm32 F1 UART RX1 pin to another device which can send data continuously.
  2. Add a "Serial1.begin()" statement in the setup() block of the VL53L1X test program. You don't even need to add "Serial1.read()" statement to make it crash.
  3. Run the program and it will hang in a couple of minutes.

Remove the "Serial1.begin() or stop sending data to its UART RX1 pin would solve the problem, but we can't use any of the UARTs for receiving data.

@fpistm
Copy link
Member

fpistm commented Apr 9, 2019

Hi @phantom,
which stm32 core you used?

@phantom-8
Copy link
Author

I used Roger Clark's one from the below URL.
https://github.com/rogerclarkmelbourne/Arduino_STM32

I also used his bootloader, so that I can program the STM32 via the USB port.

Are you aware of any compatibility issues with Roger Clark's version?

@fpistm
Copy link
Member

fpistm commented Apr 9, 2019

Honestly, I don't know as I do not know well this lib anyway I guess this should work as using I2C.
Maybe @cparata has some ideas.
Anyway, it is probably linked to the core used.
This lib support this core:
https://github.com/stm32duino/Arduino_Core_STM32
Could you post the sketch example you used.

@cparata
Copy link
Contributor

cparata commented Apr 10, 2019

Hi @phantom-8,
it is really strange because VL53L1X library uses only I2C. Which VL53L1X board are you using? How did you connect it to the Roger Clark's board? Did you try the Serial code without the VL53L1X code? Does it work properly? Could you share the sketch in order to see how you initialize the VL53L1X?

@phantom-8
Copy link
Author

phantom-8 commented Apr 10, 2019

I've tested the Arduino core suggested by fpistm and it works fine with UART receive, no more crashing. So, the problem only happens when using VL53L1X library with Roger Clark's Arduino core.

Hi @cparata, I'm using GY-53-L1X like the one from this link. However, I only use the I2C connection on this board.
https://www.ebay.com/itm/VL53L1X-STM32-TOF-Time-of-Flight-Flight-Distance-Measurement-Sensor-PWM-output-L/113146917828?hash=item1a5814f3c4:g:W7gAAOSwOLVbR9KC

The connection between GY-53-L1X & STM32F1 is very straight forward.
STM32 5V & GND goes to GY-53-L1X VCC & GND, PB6 to SCL, PB7 to SDA, PB4 to XSHUT, PB3 to GPIO1. BTW, I'm not using interrupts, so GPIO1 pin is not used.

Without VL53L1X code, my serial code works fine with Roger Clark's core. It seems to me the problem is due to some conflicts between the VL53L1X library interrupts handling and serial receive interrupts. Below you can find the sample sketch that will result in crashing the stm32 within a couple of minutes when running on Roger Clark's core. You'll need another device to continuously transmit data to the STM32 UART RX1 pin. Without feeding data to the UART RX1 pin, it will not crash.

If you need anything else to troubleshoot the problem, please let me know.

// This sample will crash the STM32 when you feed data to its UART RX1 pin.
// Remove the "Serial1.beging(115200);" statement or stop feeding data to its UART RX1 pin will stop it from crashing.
//
// Note: Serial is the USB and Serial1 is UART1 (pin PA9 & PA10).  The serial port number will shift depending on whether the USB port is enabled.
//

#include <Wire.h>
#include <vl53l1x_class.h>

VL53L1X s1(&Wire, PB3, PB4);

void setup() {
  Serial.begin(115200);
  Serial1.begin(115200);    // Remove this statement and the stm32 will no longer crash

  for (int i = 0; i < 10; i++) {
    Serial.println("Starting up...");
    delay(500);
  }
  Wire.begin();
  s1.InitSensor(0x52);
  s1.VL53L1X_StartRanging();
}

void loop() {
  uint8_t ready;
  uint32_t d;

  do {
    s1.VL53L1X_CheckForDataReady(&ready);
  } while (!ready);
  
  s1.GetDistance(&d);
  Serial.print("Distance: ");
  Serial.println(d);
  s1.VL53L1X_ClearInterrupt();
 }

@cparata
Copy link
Contributor

cparata commented Apr 10, 2019

Hi @phantom-8 ,
I'm glad that your code works with the STM32duino Core. The library was written for that core; it was also successfully tested with Arduino UNO core and Arduino DUE core. Unfortunately, I cannot guarantee that it works with all possible cores that you can find on the web. Anyway, if it works with the STM32duino Core with the same hardware setup, the issue that you can see with the Roger's core could be also due to UART and I2C implementations on that core. Because the issue is not applicable to STM32duino core I would close this issue.
Best Regards,
Carlo

@phantom-8
Copy link
Author

@cparata & @fpistm, thanks a lot for helping me to find a solution to the problem. The reason that I use Roger's core is because it supports stm32 programming via USB port. As I understand, the STM32duino core doesn't support the USB port on the blue pill. Is there any other core that supports the USB port and also compatible with the VL53L1X library?

@fpistm
Copy link
Member

fpistm commented Apr 10, 2019

DFU should be available in the next release of the core, see stm32duino/Arduino_Core_STM32#415

@phantom-8
Copy link
Author

@fpistm, great! Thanks for link. I'm new to all these STM32duino and wasn't aware there are quite a few different cores until you told me. Anyway, I'll try to apply the PR and see if I can get it to work.

@cparata cparata closed this as completed Apr 10, 2019
@phantom-8
Copy link
Author

phantom-8 commented Apr 24, 2019

When I add more VL53L1X sensors, namely 6, a similar serial receive problem occurred even on stm32duino core. Sometimes, the messages were delayed a few seconds on the UART receive, or it can disappear altogether. Unlike the Roger Clark's firmware, on the stm32duino, it didn't crashed, only problematic UART receive. The pull-up resistance on the I2C bus is fine, it currently at around 2KOhm.

I tend to believe the UART receive problem on stm32duino & Roger Clark's firmware may be related.

@cparata
Copy link
Contributor

cparata commented Apr 24, 2019

Hi @phantom-8 ,
did you make some estimations about the effective bitrate on serial port of your application? Are you inside the 11KBps? I'm wondering if the delay, that you are seeing, is due to the amount of data that you are sending. Anyway if you are able to continue reading the sensor values, it seems to me an issue inside the STM32duino Core more than an issue in the sensor library. So I suggest to open a dedicated issue inside the STM32duino Core library.
Best Regards,
Carlo

@fpistm
Copy link
Member

fpistm commented Apr 24, 2019

See my comment here: #7 (comment)
Moreover the RX/TX buffer size can be increased if needed: https://github.com/stm32duino/wiki/wiki/Customize-build-options-using-build_opt.h
-DSERIAL_RX_BUFFER_SIZE=256 -DSERIAL_TX_BUFFER_SIZE=256

@phantom-8
Copy link
Author

Hi @cparata, the UART port is at 115,200 baud. I'm not sending a lot of data over. Sometimes, a few messages a second and each message is less than 5 bytes. I also believe the problem is more related to the I2C & UART handling within the Arduino core.

Hi @fpistm, I'll give it a try.

@cparata
Copy link
Contributor

cparata commented Apr 24, 2019

Hi @phantom-8 ,
I noticed that you are using the I2C at 100KHz. Did you try to increase the bus frequency up to 400KHz? It should speed up the I2C transactions and maybe mitigate the issue on UART.
Best Regards,
Carlo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants