Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[stm32] Add support for STM32L0 #602

Merged
merged 6 commits into from
Apr 1, 2021

Conversation

chris-durand
Copy link
Member

@chris-durand chris-durand commented Apr 1, 2021

This adds support for STM32L0 devices.

  • Fix USART data in modm-devices
  • Add RCC for L0
  • Add Nucleo L031K6 BSP
  • Add Nucleo L031K6 blink example
  • Test example in hardware
  • Add L0 to CI jobs
  • Fix compilation of L0 timers
  • Fix UART interrupt loop for buffered tx / unbuffered rx
  • Fix G0 usart shared interrupt problem due to updating device files (fix postponed, device are ignored for now)

@chris-durand
Copy link
Member Author

chris-durand commented Apr 1, 2021

synchronize_docs.py crashes inside the uart module.lb, I will look into it tomorrow.

Traceback (most recent call last):
  File "/home/chris/modm/src/modm/platform/uart/stm32/module.lb", line 101, in prepare
    props["shared_irq_ids"] = range(int(parts[0]), int(parts[1]) + 1)
ValueError: invalid literal for int() with base 10: 'LPUART2'

It is caused by G0 shared irq ids not matching the format the lbuild file expects.

@salkinium
Copy link
Member

salkinium commented Apr 1, 2021

Yup, there are more issues with shared IRQs with I2C and SPI. See #566. The fix is not trivial, I would recommend upgrading modm-devices (and STM32 CMSIS headers) and adding the G0Cx and G0Bx devices to ignored.txt. Then we can fix the problems in a separate PR.

Alternatively we first fix/test #566 and then continue with this PR. Depends on how quick you need L0 support in upstream modm (and if you want to fix the I2C/SPI shared IRQ problems).

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.

Very nice, I like it (so far).

@chris-durand
Copy link
Member Author

Alternatively we first fix/test #566 and then continue with this PR. Depends on how quick you need L0 support in upstream modm (and if you want to fix the I2C/SPI shared IRQ problems).

I will put the failing G0 controllers in the ignore list for now since a colleague of mine at work needs L0 support soon.
The G0 problems are best handled in a separate PR.

@chris-durand
Copy link
Member Author

I fixed a problem in the UART driver that occurs when there is a tx buffer but no rx buffer. The controller got stuck on reception of data because the RX interrupt was enabled but the flag was never acknowledged.

@chris-durand
Copy link
Member Author

Is there any documentation that needs a manual update after adding the L0 series?

@chris-durand
Copy link
Member Author

@salkinium The files generated by synchronize_docs.py in the CI and my computer don't agree. I get from the CI:

Please synchronize the modm documentation:

    $ python3 tools/scripts/synchronize_docs.py

and then commit the results!
Error: Process completed with exit code 1.

@chris-durand
Copy link
Member Author

More G0 issues (stm32g051k8u6, stm32g061k8u6, stm32g050k8t6):

-    stm32g061k8u6           0.5s

ERROR: In 'modm:cmsis:device':

Traceback (most recent call last):
  File "/__w/modm/modm/ext/st/module.lb", line 84, in common_rcc_map
    define = getDefineForDevice(device.identifier, match)
  File "/__w/modm/modm/ext/st/module.lb", line 35, in getDefineForDevice
    minlen = min(len(d) for d in deviceDefines)
ValueError: min() arg is an empty sequence

@chris-durand
Copy link
Member Author

The G0{5, 6}* issue should be fixed by updating the ST CMSIS submodule.

@salkinium
Copy link
Member

I fixed a problem in the UART driver that occurs when there is a tx buffer but no rx buffer.

😱😱😱😱😱😱😱😱 That's quite horrifying…

The G0{5, 6}* issue should be fixed by updating the ST CMSIS submodule.

You also need to add these header patches (ST decided to remove these definitions, but only for G0 wtf).

@chris-durand
Copy link
Member Author

You also need to add these header patches (ST decided to remove these definitions, but only for G0 wtf).

I cherry-picked your commit and removed mine that updates the CMSIS headers. Let's see what the CI says.

@chris-durand
Copy link
Member Author

@salkinium There is something weird going on with synchronize_docs.py. The output on my system is different to the CI. Both are running Ubuntu 20.04.

@salkinium salkinium added the ci:hal Triggers the exhaustive HAL compile CI jobs label Apr 1, 2021
@salkinium
Copy link
Member

The output on my system is different to the CI. Both are running Ubuntu 20.04.

I have the same problem… I'll check what I can do.

@chris-durand
Copy link
Member Author

May I force-push to fix the two typos?

@salkinium
Copy link
Member

Absolutely, it's your branch.

@chris-durand
Copy link
Member Author

Thanks, will also split the stm32l0-compile-all tests into 2 parts. It was 33 minutes on the last run.

@chris-durand
Copy link
Member Author

The split stm32l0-compile-all-1 stm32l0-compile-all-2 checks don't appear in the list. Does github only update the hal tasks when you trigger them by tagging?

@salkinium salkinium added ci:hal Triggers the exhaustive HAL compile CI jobs and removed ci:hal Triggers the exhaustive HAL compile CI jobs labels Apr 1, 2021
@chris-durand
Copy link
Member Author

That worked, thanks.

@salkinium
Copy link
Member

Ideally I'd want a button that the reviewers but also the PR owner can press. But I guess we cannot have nice things…

@chris-durand
Copy link
Member Author

chris-durand commented Apr 1, 2021

But I guess we cannot have nice things…

We are doing embedded on microcontrollers here. Since when are we the people who can have nice things 😉

@salkinium
Copy link
Member

salkinium commented Apr 1, 2021

The compile-all workflow now has 20 jobs, which is the parallism limit from GHA, so it'll block all progress until it has finished running…

@chris-durand
Copy link
Member Author

It seems modm-io/modm-devices#58 is ready for merging.

@salkinium
Copy link
Member

I still cannot fix the dox sync problem. I'm going to do the release 2021q1 now, and I'm cherry-picking the UART fix, since that's really important.

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.

Ok, I approve the L0 releated changed, so thanks!

However, the CI is still broken, so I'm going to rebase and force push your branch some. Sorry for the emails…

@chris-durand
Copy link
Member Author

Should I look into finding out why the CI is broken or will you? I am working on different stuff right now, but I might get to it later. My idea would be to get the build docker container and debug it in there.

@salkinium
Copy link
Member

Should I look into finding out why the CI is broken or will you?

No, I will, hence a few commits. I suspect some issues with Python 3.8 (CI) vs 3.9 (local), but I'm not sure yet.

@chris-durand
Copy link
Member Author

chris-durand commented Apr 1, 2021

I have 3.8 as well as I am running the same OS version (Ubuntu 20.04) on the machine I am writing this from. My suspicion is right now some python package version.

@chris-durand
Copy link
Member Author

The build-docs-test has a broken pip command: pip3 --upgrade instead of pip3 install --upgrade. Don't know if that is related to the problem.

@salkinium
Copy link
Member

I rebased onto develop and now the script does indeed return the right thing, but now the CI is broken…

@chris-durand
Copy link
Member Author

chris-durand commented Apr 1, 2021

Docker pull gets an HTTP 500 from ghcr.io:

  /usr/bin/docker pull ghcr.io/modm-ext/modm-build-cortex-m:latest
  Error response from daemon: Head https://ghcr.io/v2/modm-ext/modm-build-cortex-m/manifests/latest: received unexpected HTTP status: 500 Internal Server Error
  Warning: Docker pull failed with exit code 1, back off 7.528 seconds before retry.

Copy link
Member

@rleh rleh left a comment

Choose a reason for hiding this comment

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

Nice work!

src/modm/board/nucleo_l031k6/board.hpp Outdated Show resolved Hide resolved
@rleh
Copy link
Member

rleh commented Apr 1, 2021

but now the CI is broken…

Docker pull gets an HTTP 500 from ghcr.io: [...]

https://www.githubstatus.com/:
grafik
I guess we have to wait...

@chris-durand
Copy link
Member Author

Now even the arm.com download server fails in travis ci. Microsoft cloud has network issues: https://status.azure.com/en-us/status.

@salkinium salkinium added ci:hal Triggers the exhaustive HAL compile CI jobs and removed ci:hal Triggers the exhaustive HAL compile CI jobs labels Apr 1, 2021
@salkinium
Copy link
Member

Yay, let's merge this!

@salkinium salkinium merged commit 0cf1c65 into modm-io:develop Apr 1, 2021
@chris-durand chris-durand deleted the feature/stm32l0 branch April 2, 2021 00:15
@salkinium salkinium added this to the 2021q2 milestone Jun 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
advanced 🤯 ci:hal Triggers the exhaustive HAL compile CI jobs feature 🚧
Development

Successfully merging this pull request may close these issues.

3 participants