STM32F103 | STM32F103C8 Examples | Learning library

Ok so it wasn't a software issue, there was a problem with logic level converter (3.3v to 1.8v)

If you re-debug, your MCU is reset, but your sensor is not. Therefore, the sensor is in a state which your MCU does not expect, and the communication doesnt work. Probably, the sensor is pulling down SDA and waiting for more clock cycles to finish its transmission.

In case you don't know how I2C communication works: Both SCL and SDA lines are pulled up to Vcc. SCL should only be pulled down by the master, but all devices on the bus can pull down SDA. If multiple devices "disagree" on the status of the bus, one device might pull down SDA, while the master stops toggling SCL. This kills the bus.

You should either power cycle your system or clear the I2C bus by sending 9 clock cycles. In 9 clock cycles, any pending transmission of your sensor should be finished and you can resume your communication.

Since version 0.11.0 OpenOCD doesn't create the DAP(Debug Access Point) isn't automatically created. Change the line for:

Your MX_GPIO_Init probably initializes PA11/PA12 pins in alternate function mode for use with USB controller. Thus pulling PA12 low with WritePin will have no effect.

To force active zero on D+ first configure PA12 as regular GPIO output before (or at the beginning of) MX_GPIO_Init, and use HAL_GPIO_WritePin as written in your code. Than restore PA12 function as USB's alternate function.

Actually, my problem was far more simple than I thought. In my infinite wisdom, I decided to try this on a breadboard I'd previously been using for CANbus testing, without disconnecting the CAN circuit.

(ref)

This was never going to work, as the CANbus pins I'd been trying to use (and left plugged in) share functionality with the USB port. The VCP immediately showed up and worked after I unplugged the breadboard wires I'd connected to PA11 and PA12. I feel dumb, but relieved, right now.

Only thing I can think of while seeing this code is that the value of power is huge:

The code you provide doesn't seem to be implemented well. It basically does 2 things each time you initiate a write operation:

1. Erase the page (this is the part that takes time)
2. Start form the given pointer, write until it hits a zero.

This is a very ineffective way of using the flash.

Probably the simplest and the most well-known way is to use the method described in ST's AN2594, although it has some limitations.

Still, at some point a page erase will be necessary regardless the method you use and there is no way to avoid some delay, unless your uC supports dual flash banks (STM32F103 don't have this feature). You need to plan the timing of flash writes and display refresh accordingly. If you need periodic writes to the flash, there is probably some high level error in your design.

I hope that you know that open-drain outputs require pull-up (internal or external)

Use CMSIS definitions, not magic numbers and operations.

requires the entire CMSIS

And what is the problem? CMSIS does not add any overhead to your code, only handy definitions and inline functions, which do not change the size of the code if not used.

Also, HAL has very handy macros useful even if you do not use HAL library itself (it also will not increase the code size even by a single byte)

I will not check your magic offsets and numbers.

1. First error: after enabling the peripheral clock you need to wait. It is described in the Reference Manual. You do not wait and your first MODER operation has no effect. HAL macros read back the register to make sure that the operation has completed.

Example from STM32L4:

I got mixed up with the channels of the PWM and the DMA peripheral, for anyone interested, here is a main loop that works for me: