STM32F103C8T6 ARM STM32 Minimum System Development Board

September 5, 2020

libmaple -- try the i2c example

MCP4726 DAC

I just happen to have a couple of these devices on breakout boards.

They offer this device as an i2c demo. I do what they say, as follows: 

cd examples
cp i2c-mcp4725-dac.cpp ../main.cpp
cd ..
make clean
make
It builds lickety split without errors or warnings. I made some mods. First of all, it is set up to wait for a button press from some board button. We don't have that on a blue pill, so I comment that out.

Also I am getting tired of redefining the BOARD_LED_PIN, so I edited the file wirish/boards/maple_mini/include/board/board.h and changed the value from 33 to 14

For whatever reason this example just would not run, or didn't seem to. So I grabbed my working blink demo and begin adding code bit by bit, and ultimately it just worked! Who knows what the issue was. I should go back to the original demo perhaps and sort things out.

What I did do is to connect up a serial console to Serial1 and change all the USBserial calls to Serial1 calls. Between that change and getting the LED pin set properly things just worked.

It is important to note that the Serial1 pins are A9 and A10 for the blue pill used as a maple-mini, NOT pins B6 and B7 as I was expecting.

Try the original example again

Before I packed away the DAC chip and started something else, I decided to try the original example again. I copied it and made the following changes:
  1. Commented out the button push wait (we ain't got no button).
  2. Changed all USBSerial calls to Serial1 calls.
  3. Added a call to Serial1.begin(115200); at the start of setup.
Still screwed up. I never see any serial output, and there is no waveform on the scope. It is as though it never makes it to main(), but how can that be, it is still all the same initialization code (or is it, C++ has ways of injecting these constructor methods, and maybe one of those is the root of our problems).

Very mysterious. Worrisome even. It should work and I would like to understand what is wrong, because I expect it to bite me in the future with other projects.

I comment out virtually everything, leaving only the setup() function with a call to Serial1.begin(115200) followed by a greeting message. This works.

Now it is a tedious process of trial and error, uncommenting first one section, then another. The smart way would be a binary search, but we aren't that smart.

The entire setup() routine works, with serial messages and a write to and read from the DAC. I go for broke and now it work -- I get all the messages and the sawtooth wave. This makes no sense at all.

So - what gives

I keep the hardware powered up and repeat the process with the original example. And now it works! This starts to sound like some kind of hardware initialization issue. Up to this, I was suspecting some odd compiler bug and was hoping to have one executable that worked, one that failed, disassemble them both and compare the generated instructions.

And now I try something even more minimal. I copy the example, comment out only the two lines that deal with waiting for the button -- and it works! I have a sawtooth on the scope. This is all insane and unpredictable.

I'll leave the chip powered down while I eat dinner and see what happens after that. And after that, it fired right up as soon as I applied power.

Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org