8000 L4 integration: Add cmsis files for STM MCU series L4. by tobbad · Pull Request #1888 · micropython/micropython · GitHub
[go: up one dir, main page]

Skip to content

L4 integration: Add cmsis files for STM MCU series L4. #1888

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

Closed
wants to merge 1 commit into from

Conversation

tobbad
Copy link
Contributor
@tobbad tobbad commented Mar 9, 2016

This is the 1st PR in a series of PR to support the STM32L4 series in micropython. (see http://forum.micropython.org/viewtopic.php?f=12&t=1332&sid=64e2f63af49643c3edee159171f4a365)

I add the cmsis files from STM32Cube_FW_L4_V1.3.0 with windows line ending converted to unix.

@dpgeorge
Copy link
Member
dpgeorge commented Mar 9, 2016

It's great that the L4 series is working! But adding 50k lines of headers is a lot... you only need the L476 right? Maybe we can just add that one?

@tobbad
Copy link
Contributor Author
tobbad commented Mar 9, 2016

Ok - sorry about that. I removed the not needed ones. I' ltry to reduce it to one commit.

@tobbad tobbad force-pushed the l4_integration_cmsis branch from 574684d to b91dab4 Compare March 9, 2016 13:43
@tobbad tobbad force-pushed the l4_integration_cmsis branch from b91dab4 to 142a99d Compare March 9, 2016 13:57
@tobbad
Copy link
Contributor Author
tobbad commented Mar 9, 2016

Reduced to one commit. Only added necessary files.

@SpotlightKid
Copy link
Contributor

Couldn't these ST / CMSIS files be added as git submodules somehow?

@dpgeorge
Copy link
Member
dpgeorge commented Mar 9, 2016

Couldn't these ST / CMSIS files be added as git submodules somehow?

Maybe. It is getting a bit much to have 70k+ lines of extra code, most of which wil never be used by the majority of people cloning this repository.

@dpgeorge
Copy link
Member

@tobbad I now have a Limifrog board with STM32L4 so I can test your code. I will get to it probably next week. Your code looks very clean, but the main outstanding issue is to decide how to handle the large CMSIS/HAL code drop. Probably a git submodule is the way to go.

@tobbad
Copy link
Contributor Author
tobbad commented Mar 29, 2016

@dpgeorge: The code is actually for the the STM32L4-discovery of STM.

The LimiFrog as less Flash (512MBye) and Xavier told me, that during the boot up of LimiFrog he has to do some special fixes:

About LimiFrog and bootloader: There are 2 ways to store the code in LimiFrog :

  • either through the SWD interface using an "ST-Link" USB-SWD programmer/debugger dongle (...or a Nucleo board, they have this on-board, also usable stand-alone)
  • or through the USB in DFU mode, using ST's bootloader that resides in ROM/ System Flash (...or even through other serial interfaces e.g UART for that matter).
    However there is a small limitation on LimiFrog in that case:
    the normal way would be to pull BOOT0 to GND at reset, in which case the STM32 executes the bootloader instead of user code. However, because of some interference between an on-board chip and STM32 I/Os just after reset, the bootloader is disturbed and often gets stuck in trying to boot from UART rather than booting from USB
    I have written a very short routine, to execute before any applicative code, that disables (resets) the culprit IC and checks the state of an IO accessible on the extension port to decide whether to jump to the ROM'd bootloader or continue running user's code. That works fine. If I pull the selected GPIO low at reset I can then load code using dfu-util or DfuSe. The key is to make sure this new code also starts with this small routine to keep being able to use the bootloader.
    I assume this piece of code could be inserted in the Micro Python port in the same way.

@dhylands
Copy link
Contributor

I added a mechanism to allow board specific initializations to be used. Take a look at:
https://github.com/micropython/micropython/blob/master/stmhal/boards/NETDUINO_PLUS_2/board_init.c
https://github.com/micropython/micropython/blob/master/stmhal/boards/NETDUINO_PLUS_2/mpconfigboard.h#L22

The Makefile will automatically include all of the c files from the board directory:
https://github.com/micropython/micropython/blob/master/stmhal/Makefile#L167

@tobbad
Copy link
Contributor Author
tobbad commented Mar 30, 2016

I added basic support for building LIMIFROG and deploy over stlinkk to my repo at

https://github.com/tobbad/micropython/tree/limifrog_integration

If you have a STLINK at hand (is on any discovery board) you can deploy the binary with:
make BOARD=LIMIFROG deploy2b
I need this special target (defined in mpconfigboard.mk) as the flash on LimiFrog is just 512 so the .text area (this is were firmware1.bin has to be stored) starts @ 0x080008800.

@dhylands
Copy link
Contributor

We should probably have stmhal/mpconfigport.mk setup defaults and allow the board specific mpconfigboard.mk files to override.

@pfalcon pfalcon force-pushed the master branch 4 times, most recently from 7f587c0 to 0c97e4c Compare April 10, 2016 09:45
@pfalcon pfalcon force-pushed the master branch 2 times, most recently from 9167980 to 1cc81ed Compare April 10, 2016 22:16
@dpgeorge
Copy link
Member

Ok, I have tested this entire set of PRs. I have successfully built the limifrog_integration branch of @tobbad's fork (I know that one's not the very last one to merge, but it's close enough). I have a Limifrog board and I managed to download the firmware via DFU. And it works! @tobbad you have done a great job!

I added Xavier's code to check for entering DFU mode, as described above. This way you don't need an ST-LINK debugger, the Limifrog acts just like a pyboard does.

So I'd like to merge all of these PRs. I will gradually go through them and check them, squash some things, and clean up the commit messages.

Regarding the CMSIS files and the ST HAL: after looking at it again I think the simplest thing is to just merge these new files straight into the repo. This keeps it simple (no submodules etc). And it doesn't add that much in terms of bytes: if we just include the cmsis/devinc/stm32l476.h file that's only an extra 750k compared to existing 12m in that directory; and the hal/l4 files total 3.1m, compared with existing 6.5m. I don't think it's worth going to a lot of fuss just to save 4meg from being added. If you have a differing opinion, please let it be known!

@tobbad
Copy link
Contributor Author
tobbad commented Apr 16, 2016

Thank you for your kind feedback. We have nowadays terabyte storage in out desk/laptop and 10+ MByte/s connections to the internet. In my opinion time spent to lower the memory usage on micropython is better invested than time spend reducing the storage usage of the Repo. So I agree with your conclusions regarding HAL/CMSIS files.

If you have any questions during the merge i will try to answer them as quick as possible.

Limifrog_integration: I removed the special target and switched to the same memory layout as on pyb. With this layout you just can run the release version on the board.

l4 debug: I had some issues with the tools for debugging this series. I did some fixes for stlink (use master/head) and if openocd does not want to download the debug code make a mass erase with st-flash.

BTW: There are some example scripts for limifrog on https://github.com/tobbad/micropython_lib

@dpgeorge
Copy link
Member

This PR merged in 2ba6677.

Leaving the ticket open until it's all done.

@dpgeorge
Copy link
Member
dpgeorge commented May 6, 2016

All PRs related to this L4 integration have now been merged. STM32L476DISC and LIMIFROG boards are now working.

@dpgeorge dpgeorge closed this May 6, 2016
@tobbad tobbad deleted the l4_integration_cmsis branch May 7, 2016 14:56
tannewt pushed a commit to tannewt/circuitpython that referenced this pull request May 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0