own maple clone driving me nuts

Hi,
after reading 100 posts here I decided to post my own question…

I have layouted 3 different maple-clone-PCBs. The first two boards are up and running. But No 3 is driving me nuts and I can’t find the error.

My normal procedure after soldering is:

1) flash the bootloader generic_boot20_pa1.bin with

./stm32loader.py -p /dev/ttyUSB0 -evw generic_boot20_pa1.bin

Have you got a crystal oscillator on the board? Is the oscillator actually doing anything?

On the surface, it looks like you are getting connected, and uploading the code OK, so something odd is happening after the code loads, so perhaps the external oscillator is not working, or not working reliably, or the oscillator pins are being re-assigned… or something is shoring out when pins are allocated… Exactly what code are you loading? Does *exactly* the same code work compiled *exactly* the same way on a different board .. difficult to debug based on the limited information provided. How have you got boot0 and boot1 jumpered? Have you correctly flashed Bootloader2? Are you using the bootloader?

My recommendation is to use the free EmBitz IDE together with a ST-LINK device for SWD debugging.

The other alternative is to dedicate some GPIO pins for external tracking with a scope or logic analyzer. In that route, you could add a current measurement for your board for indirect observations.

Cheers, Ollie

ahull wrote:Have you got a crystal oscillator on the board? Is the oscillator actually doing anything?
<…>

There have been other people reporting similar issues, but no one seems to have worked out whats going on.

In another thread, someone had similar issues and recompiled the bootloader using an old version of Gcc and it appeared to fix things for them.
But, loads of people use the bootloader compiled with the gcc packaged with the Arduino IDE and don’t have any problems.

Have you tried erasing the whole processor. e.g using USB to serial adaptor and STs Flash loader program.

I think the STM32 supports locking of individual pages of flash, so there is a chance your processor has some pages locked.
Also, there there is an Options register which can be changed via the STM Flash program ( or STLink etc), and its possible that one of more of the Options bits is causing problems

Thanks for all your input.
I’m still in the dark though…

I have checked the option bits, locked pages etc… everything seems to be ok.
I don’t think recompiling the bootloader will help much. The bin-file works on my other design.

A thought about the oscillator:
I’m using an external oscillator (XO53), connected to OSC_IN with OSC_out left unwired (HI-Z, as stated in the STM specs). The signal on the OSC_IN looks ok on the scope (range from 0,3 .. 3,2V). I haven’t looked at the bootloader-code so far. Do I have to change some OSC-settings?
I figured not, because the bootloader works just fine on my other boards (with the same oscillator). And the bootloader seems to work because it flashes the LED (really fast after reset, then slower at 5Hz).

On other thing I found out is:
I have an LED on PA1. When I use the generic_boot20_pa1.bin, the LED flashes and I can flash my programs via USB (but then they don’t start).
When I use one of the other binaries (e.g. generic_boot20_pb7.bin) the USB-upload does not work (pb7 is not connected to anything). Why???

I’m running out of ideas. Maybe I’ll reroute my board. I have some vias really close to the STM’s pins that I don’t like. But I’d like to understand what’s going on first

What frequency is the clock running at ?

8.000 MHz

Umm

Have you tried uploading using USB to Serial.

Set Boot0 to 1, make sure Boot1 is not floating high (pull it low)

Attach usb to serial to USART1 TX and RX

Power cycle the board

Select STM32F103C8 and upload method as Serial

Upload a sketch

Note. If you use Serial.print() it should get sent via USART1 so you should be able to see debug messages via your USB to serial

Ok. I had to install your Arduino toolchain first.
When I flash a simple program without bootloader (with “serial”) the board works. I can flash LEDs and talk via USART. Great!
But I need the bootloader to be running. That’s still not working, as before.
I’ll try again

Just to make sure…

your “generic_boot20_pa1.bin”-bootloader expects the user-code to be at 0x8005000, right?

Bootloader 2.0 is loading sketches at 0x8002000, (0x8005000 is the Leaflab original bootloader)
See VECT_TAB_ADDR in arduino-1.6.5/hardware/Arduino_STM32/STM32F1/boards.txt.
And also in the LD script arduino-1.6.5/hardware/Arduino_STM32/STM32F1/variants/maple_mini/ld/bootloader_20.ld

well, I’m using the eclipse toolchain on a linux box.

I tried
dfu-util -a2 -d 1EAF:0003 -D build/maple.bin -R

FINALLY!!

I solved it. Of course it was really simple. But then… maybe not.

Looking at the config.h in the bootloader, I found that the BUTTON is defined for each target.
I was using TARGET_GENERIC_F103_PA1 which has PC14 defined as BUTTON.

Now my hardware uses a pullup on PC14 (=D22 on maple Rev3). This kicks the bootloader into “perpetual mode” every time it starts. No way out!

I should have thought about this directly.

My quick& dirty workaround: I defined the BUTTON elsewhere on a pin I don’t need.
It would be a lot nicer if we could have a general #define HAS_BUTTON (like HAS_MAPLE_HARDWARE).

But this is just a minor thing if looking at the big picture and the great work you guys are doing here! Thanks a lot for that!!

The button to enter perpetual bootloader is defined in the bootloader not the sketch, and you can change this or remove it completely

If you look in the bootloader repo in my github account, in config.h , all the make target variants are defined using #ifdefs

One or two of the targets dont have buttons defined, and from what I remember, if its not defined, the code presumes there is no button

Just make youself a new make target and add it to config.h and recompile for your specific board

Thanks for your help here!
That’s what I did last night. I compiled my own bootloader with a bogus-button pin.
I’ll try to compile without defining button-pins today. But for now I’m happy.

macbeth wrote:Thanks for your help here!
That’s what I did last night. I compiled my own bootloader with a bogus-button pin.
I’ll try to compile without defining button-pins today. But for now I’m happy.