Hello everybody,
based on the WS2812-LED-Driver_ChibiOS [1] project, I would like to control WS2812 leds.
When looking into the reference manual [2] on page 170, I decided to use the following setup:
#define PORT_WS2812 GPIOA // GPIO group
#define PIN_WS2812 1 // GPIO pin in group
#define WS2812_TIM_N 5 // timer, 1-11
#define WS2812_TIM_CH 3 // timer channel, 0-3
#define WS2812_DMA_STREAM STM32_DMA1_STREAM0 // DMA stream for TIMx_UP (look up in reference manual under DMA Channel selection)
#define WS2812_DMA_CHANNEL 6 // DMA channel for TIMx_UP
halconf.h: (modified or appended to the file as found in the board specific demo)
[...]
#define HAL_USE_PWM TRUE
[...]
#define STM32_DMA_REQUIRED TRUE
mcuconf.h: (modified or appended to the file as found in the board specific demo)
[...]
#define STM32_PWM_USE_TIM5 TRUE
[...]
Makefile: (the most important section probably)
[...]
# Define project name here
PROJECT = ch
# Target settings.
MCU = cortex-m4
# Imported source files and paths.
#CHIBIOS = ../ChibiOS-master
CHIBIOS = ../ChibiOS-19.1.x
#CHIBIOS = ../ChibiOS-19.1.3
#CHIBIOS = ../ChibiOS-16.x
CONFDIR := ./cfg
BUILDDIR := ./build
DEPDIR := ./.dep
# Licensing files.
include $(CHIBIOS)/os/license/license.mk
# Startup files.
include $(CHIBIOS)/os/common/startup/ARMCMx/compilers/GCC/mk/startup_stm32f4xx.mk
# HAL-OSAL files (optional).
include $(CHIBIOS)/os/hal/hal.mk
include $(CHIBIOS)/os/hal/ports/STM32/STM32F4xx/platform.mk
include $(CHIBIOS)/os/hal/boards/ST_NUCLEO64_F411RE/board.mk
include $(CHIBIOS)/os/hal/osal/rt/osal.mk
# RTOS files (optional).
include $(CHIBIOS)/os/rt/rt.mk
include $(CHIBIOS)/os/common/ports/ARMCMx/compilers/GCC/mk/port_v7m.mk
# Auto-build files in ./source recursively.
include $(CHIBIOS)/tools/mk/autobuild.mk
# Define linker script file here
LDSCRIPT= $(STARTUPLD)/STM32F411xE.ld
# C sources that can be compiled in ARM or THUMB mode depending on the global
# setting.
CSRC = $(ALLCSRC) \
$(TESTSRC) \
ws2812.c \
main.c
[...]
The firmware is built based on the stable_19.x branch.
Is there anything I missed? Anything that changed since ChibiOS 16.x, which needs to be done?
My level of expertise: I'm new to this level of microcontroller programming. Got my first touch on ChibiOS around 2 weeks ago. So I know the basic build up and I'm interested to program drivers (interop libraries) for the nanoframework.
Already, many thanks for any help!
- Thomas
[1] https://github.com/joewa/WS2812-LED-Driver_ChibiOS
[2] https://www.st.com/content/ccc/resource ... 119316.pdf
WS2812-LED-Driver_ChibiOS for ST_NUCLEO64_F411RE
Moderator: RoccoMarco
- Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: WS2812-LED-Driver_ChibiOS for ST_NUCLEO64_F411RE
Hi,
What is the problem? or what is the question?
Since 16.x a lot of things changed. In general, when switching to a new version it is mandatory to take makefiles and configuration files from the new one.
Giovanni
What is the problem? or what is the question?
Since 16.x a lot of things changed. In general, when switching to a new version it is mandatory to take makefiles and configuration files from the new one.
Giovanni
Re: WS2812-LED-Driver_ChibiOS for ST_NUCLEO64_F411RE
Good morning Giovanni!
Yes, I ensured that the Makefile and configs are taken from the device's demo project in the stable_19.1.x branch.
Additionally, I took some time and commited all changes to a forked repo on Github, so you can see every step I made.
https://github.com/thopiekar/WS2812-LED ... ucleo411re
Here are the problems I have. After reading myself into the topics of DMAs, Timers and GPIO access (since I'm new into this level of embedded programming), I went over the ws2812{.c, .h} and adjusted the defines to my needs.
Therefore, I came to this setup:
https://github.com/thopiekar/WS2812-LED ... 0e4d8c8272
However, when connecting the LED stripe to the GPIO port I get nothing. A connected oscilloscope confirms that the port is on LOW all the time.
Therefore, I took OpenOCD and went to the place, where the buffer is being written and checked it's content. The buffer is definitely written with data.
PS: Here is the build log: https://pastebin.com/JeshaD17
Therefore, the questions are:
1. What has been done incorrectly while porting the example from 16.x to 19.1.x (stable) and from STM32F4-Discovery to STM32Nucleo411RE?
2. How can I keep debugging and understanding the problem? Logically, I configured the DMA and from my understanding its actions are happening outside my debug-able application, right?
3. While reading through the internet, I read that I need to take care about "special function registers". It is a hint worth to take a look at? Need to investigate whether these are debug-able via OpenOCD, too.
- Thomas
Yes, I ensured that the Makefile and configs are taken from the device's demo project in the stable_19.1.x branch.
Additionally, I took some time and commited all changes to a forked repo on Github, so you can see every step I made.
https://github.com/thopiekar/WS2812-LED ... ucleo411re
Here are the problems I have. After reading myself into the topics of DMAs, Timers and GPIO access (since I'm new into this level of embedded programming), I went over the ws2812{.c, .h} and adjusted the defines to my needs.
Therefore, I came to this setup:
https://github.com/thopiekar/WS2812-LED ... 0e4d8c8272
However, when connecting the LED stripe to the GPIO port I get nothing. A connected oscilloscope confirms that the port is on LOW all the time.
Therefore, I took OpenOCD and went to the place, where the buffer is being written and checked it's content. The buffer is definitely written with data.
PS: Here is the build log: https://pastebin.com/JeshaD17
Therefore, the questions are:
1. What has been done incorrectly while porting the example from 16.x to 19.1.x (stable) and from STM32F4-Discovery to STM32Nucleo411RE?
2. How can I keep debugging and understanding the problem? Logically, I configured the DMA and from my understanding its actions are happening outside my debug-able application, right?
3. While reading through the internet, I read that I need to take care about "special function registers". It is a hint worth to take a look at? Need to investigate whether these are debug-able via OpenOCD, too.
- Thomas
Last edited by thopiekar on Tue Feb 11, 2020 10:41 am, edited 1 time in total.
- Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: WS2812-LED-Driver_ChibiOS for ST_NUCLEO64_F411RE
It is likely a GPIO setup problem in board.h, you need to setup GPIO pins according to your needs.
Giovanni
Giovanni
Re: WS2812-LED-Driver_ChibiOS for ST_NUCLEO64_F411RE
Thank you for your quick reply!
I tested yesterday already different GPIO pins including different GPIO bays (GPIOA, GPIOB, ...).
My reference led for the heart beat works fine.
At least from your reply and looking into the board.h, I understand that you believe the GPIO mapping is wrong, right?
Many thanks already!
I tested yesterday already different GPIO pins including different GPIO bays (GPIOA, GPIOB, ...).
My reference led for the heart beat works fine.
At least from your reply and looking into the board.h, I understand that you believe the GPIO mapping is wrong, right?
Many thanks already!
Re: WS2812-LED-Driver_ChibiOS for ST_NUCLEO64_F411RE
A little follow up from here. I looked more into detail around the "alternate function mapping" and noticed that I'm restricted to a GPIO indeed.
However, after adjusting the GPIO and ensuring that WS2812_AF is defined as 2, I still get no input on the (moved) GPIO PA3, which shall be at ARD_D1.
The pin mapping as stated by mbedOS:
Is there something I might still miss? Something I likely misunderstood from your point of view?
- Thomas
However, after adjusting the GPIO and ensuring that WS2812_AF is defined as 2, I still get no input on the (moved) GPIO PA3, which shall be at ARD_D1.
The pin mapping as stated by mbedOS:
Is there something I might still miss? Something I likely misunderstood from your point of view?
- Thomas