ChibiOS Free Embedded RTOS

Code porting from ChibiOS 18.2.1 to ChibiOS 19.1.4 works fine, ChibiOS 20.3.1 has a problem. I have separate builds for each version, with mcuconf.h, halconf.h, chconf.h and Makefile from the relevant ChibiOS versions and files updated as appropriate.

Edit to add: Using STM32F407 DISC1 board
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]

I populate a buffer with a sine wave of a given frequency, output via DAC (very similar to testhal/STM32/STM32F4xx/DAC/main.c, but not using the callback) and read back via ADC as a test signal. I use 1024 sample buffers (12 bit), and join two buffers together, so the raw trace shows the same DAC data repeated. The left trace is the incoming signal, the right trace is the spectrum.
From Version 19.1.4 (which works the same as 18.2.1):


With version 20.3.1 the data is garbled in places, and the frequency doubled:


I have tested with an oscilloscope and an external signal which confirms the ADC code is working properly and the DAC is producing bad data.

I suspect it's related to the different CR settings in os/hal/ports/STM32/LLD/DACv1/hal_dac_lld.c and I'll try to examine that in the debugger.

It may be DMA related as it seems similar to the following, although I'm not using DUAL mode
viewtopic.php?t=2988

Thanks
Mike

I can confirm that the testhal/STM32/STM32F4xx/DAC programs for 18.2.1 and 19.1.4 behave as expected (or at least give similar results):


For 20.3.1 the results are:

Hi,

I have no access to an oscilloscope for a while because lockdown. I think I understood the problem, it happened when implementing the new DMA support like you suggested.

There is a a note the the reference manual stating that registers should be accessed always as 32 bits but the driver stopped working when I tried to do exactly that.

Could you try the following?

1) Search all STM32_DMA_CR_PSIZE_WORD (there are 6 of them, only 4 to be replaced at 655, 663, 671, 699).
2) Replace it with STM32_DMA_CR_MSIZE_HWORD or STM32_DMA_CR_MSIZE_BYTE depending on the MSIZE or condition (make peripheral and memory the same width).

Giovanni

I will try that later - may be tomorrow.

The screen captures were using ChibiOS & a web browser as a low spec oscilloscope, which works well up to a few hundred kHz.

Thanks
Mike

mikeprotts wrote:The screen captures were using ChibiOS & a web browser as a low spec oscilloscope, which works well up to a few hundred kHz.

Could you share how to use web browser as a low spec oscilloscope?
thanks.

mikeprotts wrote:I will try that later

That worked fine. I assumed you meant STM32_DMA_CR_PSIZE_HWORD and STM32_DMA_CR_PSIZE_BYTE as appropriate.

Thanks
Mike

ticchen wrote:Could you share how to use web browser as a low spec oscilloscope?

I capture signal using ADC (up to 700kSPS with current config) and make it available by using the STM board work as a web server (LWIP). It also generates spectrum data using the CMSIS DSP libraries for a Fourier transform (FFT). That's just binary data at that stage.

I then use an Apache server (on Raspberry Pi) as a reverse proxy. This provides the html page and javascript to fetch the data, and then uses JSXGraph to produce the plots.

It's part of a bigger project, and if possible this part may be open sourced.

Mike

Fixed as bug #1100.

Giovanni

Thanks.

Just to confirm the DAC test program works fine. The displays earlier were affected by having an uninitialised pin connected as a loopback to the DAC. The normal trace is here: