[SOLVED] Wire.begin crashes bootloader

My board is a Blue Pill with the STM32duino USB bootloader, 2×16 LCD and an I2C device. My code loads and runs fine until I uncomment the “wire.begin” statement. Every time I do that, it crashes the USB bootloader and I have to reload the bootloader with STLink. Ideas?

Joe

Which core?!
Which upload method?
What about posting a sample breaking sketch?

“Blue Pill” board STM32F103C8 with STM32duino USB bootloader.

Simple blinky program with encoder interrupts and I2C device (Si5351). Bootloader blows up as soon as “wire.begin” is allowed to execute.

Code:

#include <LiquidCrystal.h>
#include <Wire.h>
const int rs = PB10, en = PB9, d4 = PB8, d5 = PB0, d6 = PA6, d7 = PA5;
LiquidCrystal lcd(rs, en, d4, d5, d6, d7);
volatile int state ;
void setup() {

//Wire.begin(); // Initialize I2C-communication as master

//SetFrequency (10140000); // Set TX-Frequency [10,14 MHz] //SetParkMode ();
//TX_ON();
// initialize digital pin LED_BUILTIN as an output.
pinMode(PC13, OUTPUT); //LED
pinMode(PB1, INPUT); //Encoder pin that causes interrupt
pinMode(PB11, INPUT); //Encoder pin to be sampled

attachInterrupt(PB1, encoder, FALLING); //interrupt on falling edge

lcd.begin(16, 2);
lcd.clear();
}

void loop() {
digitalWrite(PC13, !digitalRead(PC13));
delay(100);
lcd.setCursor(0, 0);
lcd.print(state);
}

void encoder() {
bool b;
b = digitalRead (PB11);
if (b == 0)
{
--state ;
}
else
{
++state;
}
}

Note: Si5351 routines are in a seperate code module not shown for brevity.

Which core?
Which upload method?
How do you tell the bootloader gets broken?
Which symptoms?

If by ‘core’ you mean the board manager, it’s this:
https://github.com/stm32duino/BoardMana … index.json

Not sure what you mean by Upload Method. It’s Arduino IDE w/STM32duino USB bootloader in the application board.

As soon as the code uploads and starts execution, the USB bootloader gets blown away and is no longer is visible in Windows Device Manager. I then have to connect STLink and reload the bootloader. This doesn’t happen if the ‘wire’begin’ statement is commented out.

Ok, so you are using the official STM core but it’s not compatible with the bootloader..
If you want to use the DFU bootloader you have to use Roger’s core at: https://github.com/rogerclarkmelbourne/Arduino_STM32

Mòre info in the wiki and welcome posts.

Cheers, E.

I’m using Roger’s Bootloader from the link in this page:

https://github.com/rogerclarkmelbourne/ … ill-Boards

It’s a “Blue Pill” board very commonly known in the community and multi-sourced from China on EBay and other sites.

Not sure what part you’re not familiar with.

OK, I think I see what you’re saying. I thought I was using Roger’s work all the way down the line, but apparently I Need a different core in my IDE?

Yes you do..

Of course, if you want to use Roger’s bootloader..

If instead you want to stick with STM’s core then you don’t need Roger’s bootloader: it uses st-link or the standard usart bootloader..

AFAIK I installed the cores and the bootloader from Roger’s instructions, certainly the bootloader which came from the article I referenced. Please provide a reference to,the compatible cores and support files I should be using.

[edogaldo – Tue Aug 28, 2018 8:11 pm] –
Yes you do..

I touch on the cores here: http://stm32duino.com/viewtopic.php?f=2&t=3111

It can be a bit confusing. Hopefully you were pointed to that link in response to your New User post.

Ray

I just found this thread which might point to the actual problem

https://github.com/rogerclarkmelbourne/ … 2/pull/545

Now I’m thinking that when “wire.begin” executes in the “setup” at startup, it’s a duplicate call that locks up the I2C code in a blocking fashion that makes it appear the bootloader is the culprit. Since reloading the bootloader also wipes the program, it appears like that’s what fixed it.

Tomorrow I’ll check for duplicate “wire.begin” calls and see if that eliminates the problem. Possibly Roger’s revised library will fix it too.

I modified the file “STM32F1/cores/maple/libmaple/i2c.c” per the posting in the referenced thread. The problem still exists, but has changed. The code still locks up when “wire.begin” is compiled in, but now I can recover without reflashing the bootloader. To do this, I have to press reset before I can reload the sketch with “wire.begin” commented out, then it runs again.

FWIW, there are no devices or pullups on the I2C pins. I’ll put a couple on tonight and see if that changes the behavor.

Joe,

If you are using a bootloader, a Blue Pill, and Roger’s core (The old LibMaple stuff) then the WiKi for you is:

https://github.com/rogerclarkmelbourne/ … STM32/wiki and the bootloader must match the specific core – it is linked here:
https://github.com/rogerclarkmelbourne/ … Bootloader
Uploading is explained in this section of the WiKi: https://github.com/rogerclarkmelbourne/ … /Uploading

Note that there is not an XML file to insert into the Arduino IDE for this core. You must download the ZIP or clone the git repository. If you previously used another core with an XML install, they all of that needs to be removed and that includes going into the Arduino IDE and using the Board Manager.

My suspicions are that you have a configuration issue with the IDE. If you have another PC, you may want to complete an install and try your code.

Ray

OK, I figured out the proximate cause of the problem. When I enable internal pullups on the I2C lines, the problem disappears. Though this is a workable resolution, it seems to point to a weakness in how the I2C port is handled.

Edit 5 minutes later:
Though the problem of crashing on ‘wire.begin’ is solved, the system still crashes on execution of other I2C functions. This might go away when there’s something on the bus….we’ll see.

I2C has fairly specific requirements for the pull-up resistors. The internal pull-ups are far too high to be of any use. Typically, you need 1-2 milliamps for reliable operation. For a 3.3 volt processor, this is 1.5K to 3.3K. Even with those values, you need to keep the wires as short as practical. In the Arduino (5V) world, 2.7K to 5.1K is recommended.

I would try to set the IRQ prio value a bit higher (less prio) let’s say to 5 instead 0, here: https://github.com/rogerclarkmelbourne/ … #L127-L128.

Problem has been resolved, With something on the bus and proper pullups, it works .

Still though, I think this points to a fragility in the library that could hang the system if a peripheral gets disconnected or broken in some other way. In something like a remote monitoring device, this could be very bad because you’d lose contact with the whole system.