Skip to content

Conversation

@rleh
Copy link
Member

@rleh rleh commented Apr 5, 2021

This was very easy thanks to the great work done by @mikewolfram in #371.

Tested on Nucleo-F303RE.

Copy link
Member

@salkinium salkinium left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️

@rleh
Copy link
Member Author

rleh commented Apr 5, 2021

STM32F0{3,7}0xC / STM32F102 / devices modm-devices tells me about a second dma:stm32-channel-request instance that does not exist according to the datasheet and reference manual. Where does this come from and how do I fix it?

https://github.com/modm-io/modm-devices/blob/develop/devices/stm32/stm32f0-30.xml#L217

@rleh
Copy link
Member Author

rleh commented Apr 5, 2021

STM32F09{1,8} has a different problem:

<vector position="10" name="DMA1_Ch2_3_DMA2_Ch1_2"/>
<vector position="11" name="DMA1_Ch4_7_DMA2_Ch3_5"/>

I don't understand this error by now:

 x   stm32f373vct7          14.9s
In file included from modm/src/modm/platform.hpp:26,
                 from main.cpp:12:
modm/src/modm/platform/dma/dma.hpp:787:63: error: too many template-parameter-lists
  787 | struct DmaController<1>::Channel<DmaBase::Channel::Channel7>::RequestMapping<Peripheral::Tim17, DmaBase::Signal::Ch1>
      |                                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
modm/src/modm/platform/dma/dma.hpp:805:63: error: too many template-parameter-lists
  805 | struct DmaController<1>::Channel<DmaBase::Channel::Channel7>::RequestMapping<Peripheral::Tim17, DmaBase::Signal::Up>
      |                                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scons: *** [build/scons-release/main.o] Error 1

(occures on multiple devices)


The Dma-SpiMaster has some interrupt flag definitions missing on some devices, looks easy to fix...


Dma2 has only 2 channels on STM32L1?
-> No, there are 5 channels but modm-devices does not know about it.

grafik

<channels device-size="c" instance="2">
  <channel position="1">
    <signal driver="spi" instance="3" name="rx"/>
  </channel>
  <channel position="2">
    <signal driver="spi" instance="3" name="tx"/>
  </channel>
</channels>

Peripheral::Lpuart vs Peripheral::Lpuart1
... and Dac vs Dac1
... and Swpmi1

Maybe modm-devices is inconsistent/wrong here? (#608 (comment))

Miauu 🐈

@salkinium
Copy link
Member

Uff, I didn't expect there to be that many problems. The code responsible for parsing the DMA data is here, there are a lot of corrections, some of which are described in the PR.

@rleh
Copy link
Member Author

rleh commented Apr 6, 2021

Looks to me like CubeMX data is partly wrong, also modm-devices is definitely wrong in some cases 😒

I'm not motivated to deal with this any further at the moment; maybe tomorrow I'll look into enabling DMA based on a positive list for some STM32s that I use.

@rleh
Copy link
Member Author

rleh commented Apr 6, 2021

Some other issues I discovered:

From time to time (when regenerating device file in modm-devices) lbuild completely refuses to acknowledge the existence of STM32F0*. Probably (again) some cache issue...

I can't run the CI script on my Linux, because Python is unable to locate lbuild

>>> import subprocess

>>> subprocess.run(["echo $PATH"], shell=True)
[...]:/opt/doxypress:~/.local/bin:~/bin:/opt/gcc-arm-none-eabi-10-2020-q4-major/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin
CompletedProcess(args=['echo $PATH'], returncode=0)

>>> subprocess.run(["lbuild --version"], shell=True)
/bin/sh: lbuild: Kommando nicht gefunden.
CompletedProcess(args=['lbuild --version'], returncode=127)

>>> subprocess.run(["which lbuild"], shell=True)
/home/rleh/.local/bin/lbuild
CompletedProcess(args=['which lbuild'], returncode=0)

>>> subprocess.run(["$(which lbuild) --version"], shell=True)
lbuild 1.16.1
CompletedProcess(args=['$(which lbuild) --version'], returncode=0)

WTF?!

Update: ~/.local/bin:~/bin is the problem: /home/user/.local/bin:/home/user/bin works.

@salkinium
Copy link
Member

I'm not motivated to deal with this any further at the moment; maybe tomorrow I'll look into enabling DMA based on a positive list for some STM32s that I use.

Yeah, that's also what I would propose, I think this issue is overwhelming otherwise. It's very frustrating to work with the CubeMX data…

Probably (again) some cache issue...

I'm sorry… It's on my todo list for #390.

Python is unable to locate lbuild

No clue… I need to rewrite that to call lbuild directly instead of from the cmdline…

@rleh
Copy link
Member Author

rleh commented Apr 6, 2021

No clue… I need to rewrite that to call lbuild directly instead of from the cmdline…

I think thats a bad idea, because it will make debugging even harder (or in some cases nearly impossible).

@rleh
Copy link
Member Author

rleh commented Apr 11, 2021

modm/src/modm/platform/dma/dma.hpp:706:63: error: too many template-parameter-lists
  706 | struct DmaController<1>::Channel<DmaBase::Channel::Channel6>::RequestMapping<Peripheral::Tim1, DmaBase::Signal::Ch3>
      |                                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The underlying problem are some duplicate entry in modm-devices:
https://github.com/modm-io/modm-devices/blob/develop/devices/stm32/stm32f1-00-c_d_e.xml#L181-L182

<signal driver="tim" instance="1" name="ch3"/>
<signal driver="tim" instance="1" name="ch3"/>

grafik

@rleh rleh force-pushed the feature/dma_more_stm32 branch from 426aec2 to 5b114b2 Compare April 11, 2021 19:13
@rleh rleh force-pushed the feature/dma_more_stm32 branch from 5b114b2 to 293ab3c Compare April 11, 2021 20:14
@rleh rleh requested review from chris-durand and salkinium April 11, 2021 20:15
@rleh rleh added the ci:hal Triggers the exhaustive HAL compile CI jobs label Apr 11, 2021
@rleh rleh force-pushed the feature/dma_more_stm32 branch from 293ab3c to bfb7826 Compare April 11, 2021 23:55
@rleh rleh added ci:hal Triggers the exhaustive HAL compile CI jobs and removed ci:hal Triggers the exhaustive HAL compile CI jobs labels Apr 11, 2021
@rleh rleh force-pushed the feature/dma_more_stm32 branch from bfb7826 to 98e7618 Compare April 13, 2021 06:49
@rleh rleh added ci:hal Triggers the exhaustive HAL compile CI jobs and removed ci:hal Triggers the exhaustive HAL compile CI jobs labels Apr 13, 2021
@rleh rleh force-pushed the feature/dma_more_stm32 branch from 69a214e to 1dc7916 Compare April 13, 2021 22:10
@rleh rleh force-pushed the feature/dma_more_stm32 branch from 1dc7916 to 8ca2f35 Compare April 13, 2021 22:47
@rleh rleh added ci:hal Triggers the exhaustive HAL compile CI jobs and removed ci:hal Triggers the exhaustive HAL compile CI jobs labels Apr 13, 2021
@salkinium salkinium merged commit 8ca2f35 into modm-io:develop Apr 14, 2021
@rleh rleh deleted the feature/dma_more_stm32 branch April 14, 2021 09:13
@salkinium salkinium added this to the 2021q2 milestone Jun 20, 2021
@rleh rleh mentioned this pull request Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci:hal Triggers the exhaustive HAL compile CI jobs enhancement 🌈

Development

Successfully merging this pull request may close these issues.

3 participants