[SOLVED] tone() not working on F072-Discovery

Here is my latest feature to add STM32F072 Discovery into one of the variants. Everything seems to work just fine, except for tone(). I have followed all steps in the wiki, what else should I look (or I have missed?)

I have tried with TIM15 and TIM14 for TIMER_TONE with no luck!

Link to my work is here: https://github.com/ekawahyu/Arduino_Cor … ry-variant

Ok. I will have a look.

I added Makefiles and OpenOCD with debugging support on Eclipse, cause there is nothing I can do to find where it goes wrong with only Arduino IDE.

The Makefile and OpenOCD features can be found in here: https://github.com/ekawahyu/Arduino_Cor … nd-openocd

So far, what I can tell, the code seems to get stuck once the timer interrupt is enabled:
/* Enable the TIM Update interrupt */
__HAL_TIM_ENABLE_IT(htim, TIM_IT_UPDATE);

Your variant seems ok. nice job.
After checking the STM32F072 specification:
http://www.st.com/content/ccc/resource/ … 090510.pdf

TIM14
This timer is based on a 16-bit auto-reload upcounter and a 16-bit prescaler.
TIM14 features one single channel for input capture/output compare, PWM or one-pulse
mode output.
Its counter can be frozen in debug mode.
TIM15, TIM16 and TIM17
These timers are based on a 16-bit auto-reload upcounter and a 16-bit prescaler.

So, I think there is an issue with the core management of the timer.
Probably value set is not correct then the counter is very small then probably IT is raised a lot…
I will try to reproduce on an other boards. Not reproduce on my F7. I will try on minday with your variant on the discovery F072.
Have you tried with TIM2 or TIM3.

Which sketch you used? ToneMelody?

Confirmed that TIM3 works for tone(), but I don’t have the oscilloscope to test frequency correctness. The temporary fix is available in here:

https://github.com/ekawahyu/Arduino_Cor … /tone-tim3

ToneMelody is the sketch I am testing with.

By now, I merged everything back into branch develop, but it does not include the TIM3 temporary fix. I do hope to use TIM14 or TIM15 to generate the tone before merging into branch develop. Thank you.

You could wire the tone output pin to another pin and use pulseIn() to measure.

Ok I will do some tests on monday.
Could you submit an issue on the Arduino_Core_STM32 to track this issue and add the link to this post. please?

[Rick Kimball – Sat Sep 23, 2017 5:09 pm] –
You could wire the tone output pin to another pin configure to do a pulseIn() to measure.

Will do it soon, thanks for pointing that out. I have never used pulseIn() before

[fpiSTM – Sat Sep 23, 2017 7:27 pm] –
Ok I will do some tests on monday.
Could you submit an issue on the Arduino_Core_STM32 to track this issue and add the link to this post. please?

Done!

So it is confirmed that the tone() frequency is correct with TIM3. I used pulseIn() to measure the time per Rick suggestion. Looking forward to the fix for TIM14 and TIM15.

Thanks ekawahyu

One question about your repo, why adding some CMSIS header file?
https://github.com/ekawahyu/Arduino_Cor … 3d342b8730
They are already available in the CMSIS 4.5.0 arduino package?
This is for the opeOCD and Makefile need?

Yes, it is for the Makefile and debugging purposes. It is not in the main branch anyway, but I tend to keep it later in case I need to do debugging with ST-Link through OpenOCD. I just don’t know a better way of keeping Makefile and CMSIS of the main branch later on.

I would actually propose to keep the Makefile in the main branch if you guys ok with adding it. I can modify it to look for 4.5.0 header files in the Arduino package. Just let me know what would be the best on the roadmap and I can do PR that way. Thank you.

Issue has been identified.
Some irq handler name was wrong (TIM1 for ex) and some are missing.
Patch will be done soon.

About adding the Makefile, why not but it seems very specific to one target.
For CMSIS header it should be fine to use one from the CMSIS package to avoid having twice the same file.

Cool! Looking forward to the fix!

The Makefile needs some work to build all device drivers as libraries, build it once, keep it somewhere, and rebuild it only when there is version update. Unfortunately, I don’t have all of those boards to test the Makefile builds, but I can try to make it generic before doing PR.

The only confusing thing right now is where to build the USB libraries for HID and CDC supports. Should it be put as part of the device driver or individually in each variant? What is the status of HID and CDC support? I am trying to build CDC ACM stack from STM32CubeMX, but it does not seem generic enough.

[ekawahyu – Sun Sep 24, 2017 3:30 pm] –
Yes, it is for the Makefile and debugging purposes. It is not in the main branch anyway, but I tend to keep it later in case I need to do debugging with ST-Link through OpenOCD. I just don’t know a better way of keeping Makefile and CMSIS of the main branch later on.

You can debug the arduino .elf files without doing your own make. Just go to the build output directory (/tmp/arduino_build_xxx for linux) start up gdb and debug away.

I’m opposed to putting this type of thing into the arduino core. I don’t think this stuff is in the spirit of Arduino. Arduino uses the builder application and goes out of its way to avoid make and makefiles.

If you want to do your own thing while retaining the ability to customize your copy you might look at this:
http://stm32duino.com/viewtopic.php?t=1741

[Rick Kimball – Mon Sep 25, 2017 3:13 pm] –

[ekawahyu – Sun Sep 24, 2017 3:30 pm] –
Yes, it is for the Makefile and debugging purposes. It is not in the main branch anyway, but I tend to keep it later in case I need to do debugging with ST-Link through OpenOCD. I just don’t know a better way of keeping Makefile and CMSIS of the main branch later on.

You can debug the arduino .elf files without doing your own make. Just go to the build output directory (/tmp/arduino_build_xxx for linux) start up gdb and debug away.

Ok, will look into it. I know that Arduino has its build somewhere in /tmp, but I didn’t have the time to find out how it works with all those random generated _xxx thing. I has to be documented somewhere because looking for the .elf itself is already troublesome and it keeps changing location.

Just flip the checkbox in preferences to view the compile output directory. It will show you where the .elf is going.

And how to take the path and fire up Eclipse debugging without doing it manually every time? I don’t know how to configure the debugging launch with the .elf location that keeps changing. That’s the reason why I had the separate Makefile from the first place.

Ultimately the goal is being able to use both Arduino and SystemWorkbench side-by-side. If that’s the path we wanted to go to. I am not the decision maker here though.

EDIT: Hmmm… there should be a script that automatically generates Eclipse debug launch every time a .elf is built

viewtopic.php?f=35&t=113#p837 although personally I just use the command line arm-none-eabi-gdb

[Rick Kimball – Mon Sep 25, 2017 4:55 pm] –
viewtopic.php?f=35&t=113#p837 although personally I just use the command line arm-none-eabi-gdb

Your GitHub links are dead, so where can I get the script from?

@fpiSTM I merged changes from @fprwi6labs and TIM14 seems to be working just fine. Thanks!