search

AdaCore / bb-runtimes

Source repository for the GNAT Bare Metal BSPs
Other
65 stars 51 forks source link

The setup_pll is not by default compatible with STM32h7 familly #7

Closed HackInvent closed 5 years ago

HackInvent commented 6 years ago

Hi the STM32H7 family has 3xPLLs, the setup_pll doesn't work without modifying or removing it from the BSPs. A turn around that I used in a fork is to add in cortexm.py the possibility to select the Stm32CommonBSP's sources from the init of Stm32.

lambourg commented 6 years ago

Hi, could you point us to the sources of your runtime so that we can have a look and see how we could be support the full family?

Beset regards,

HackInvent commented 6 years ago

I made this commit to add SMT32H7 in a fork

To make it work I was obliged to remove the setup_pll.ada and modify a little bit the cortexm.py to make it possible.

I don't have the full history why you added Stm32CommonBSP in cortexm.py, perhaps it is not really necessary? we can make all the customization in Stm32.init to add new mcu or board

HackInvent commented 6 years ago

Hi @lambourg Any news? if you want I can give a hand to help restructuring? Badr

lambourg commented 6 years ago

Sorry for the late reply, but I'll have a look at your fork and see where we could improve portability here. I'll let you know of course.

lambourg commented 6 years ago

Hi @HackInvent ,

So I finally found time to look at your fork.

On the history behind Stm32CommonBSP, the goal for the bb-runtimes scripts is to generate a source tree that can then be modified/enhanced to easily add new board support without having to re-run from bb-runtimes the whole generation (and thus dive into somewhat complex python infrastructure to do so).

This means that the generated source tree should avoid as much as possible duplicated source files (e.g. avoid having the same source in multiple places).

Now on the stm32h7, there's indeed incompatibilities in the way setup_pll should be implemented.

So your solution of course will work, with the drawback of having setup_pll duplicated on all stm32f* folders. I'll see if things could be more flexible here...

HackInvent commented 5 years ago

Hi @lambourg did you get a chance to look into a hint about the H7? We are working on a board based on this chip, if you have any directive we can help to refactor.

Fabien-Chouteau commented 5 years ago

Hi @HackInvent,

I commented on your repository: https://github.com/HackInvent/bb-runtimes/commit/168f25ba0dcdb93c857d1d37276c806cd50244e7

Just removing setup_pll.ad[bs] from the Stm32CommonBSP and then select the correct setup_pll from the MCU name.

We are working on a board based on this chip, if you have any directive we can help to refactor.

Awesome! We will be happy know more about this project :) Also don't hesitate to share it on twitter: @AdaProgrammers.

HackInvent commented 5 years ago

Hi @Fabien-Chouteau I just made the update as you commented. https://github.com/AdaCore/bb-runtimes/compare/master...HackInvent:master I kept a temporary folder in the commit in purpose to show the generated BSP. I also generated/built SMT32F4 example to check if the modification had no regression on the other boards. Regards, Badr

HackInvent commented 5 years ago

@Fabien-Chouteau I add here a commit for Ada_Drivers_Library https://github.com/HackInvent/Ada_Drivers_Library/commit/4230bec358868674fdc471c6e632ffc5bcbff47b to test the configuration with GPIO (simple onboard blink led). It's working fine. https://imgur.com/a/KY1ixEZ

Fabien-Chouteau commented 5 years ago

Awesome :+1:

Why did you copy the STM32.GPIO implementation? Is is one already provided not working with the STM32H7?

HackInvent commented 5 years ago

I think it was a mistake, I don't remember having an issue with STM32.GPIO.

I thought a little bit about the architecture of the bb-runtimes, in my opinion there is no urgent need to make common STM32 boards configurations. It will be better if each board have it's own files. This way when someone wants to add a new board, he has just to copy/paste existing one and modify the files in the folder of the new board. There will be no regression/impact on the other boards.

HackInvent commented 5 years ago

I thought a little bit about the architecture of the bb-runtimes, in my opinion there is no urgent need to make common STM32 boards configurations....

Never-mind, I guess it is due to reduce certification workload needs.

Fabien-Chouteau commented 5 years ago

Hi @HackInvent,

Copy paste is generally a bad idea in the long run, it raises the maintenance cost.

ezwiebel commented 4 years ago

Hi,

I know this issue is closed but I'm also looking into developing Ada SW on a nucleo-144 board with STM32H743 MCU and I can't seem to be able to open issues on @HackInvent fork to discuss it.

Looking at it though, I find it unlikely that you've been able to run your SW on the board correctly as you did not modify any of the low level things like the assembly startup script (start-common.S) for cache initialisation nor all the things pointed out here for the F7 (same processor Cortex-M7). Also, the flash SVD you use for PLL setup is the one for the F7 and does not point to the right address for the H743... what exactly is done in fact ? Who knows 😄

Maybe it is enough to pilot a GPIO though... but I wouldn't bet on it working for more complex usage. I'm currently trying to adapt the runtime to the H743 and will need to use DMA/I2C/SPI/USART and everything else. Tough work, but I'll let you know how it goes. You don't happen to have an "off the shelf" implementation lying around @lambourg @Fabien-Chouteau ? That would be wonderful 😅

Thanks.

Fabien-Chouteau commented 4 years ago

Hi @ezwiebel,

You don't happen to have an "off the shelf" implementation lying around @lambourg @Fabien-Chouteau ? That would be wonderful sweat_smile

All the "off the shelf" BSPs are in this repo already.

ezwiebel commented 4 years ago

Thanks for the answer. I'm on it, I'll let you know when done if interested. Cheers

Fabien-Chouteau commented 4 years ago

Of course, let us know :)

HackInvent commented 4 years ago

Looking at it though, I find it unlikely that you've been able to run your SW on the board correctly as you did not modify any of the low level things like the assembly startup script (start-common.S) for cache initialisation nor all the things pointed out here for the F7 (same processor Cortex-M7). Also, the flash SVD you use for PLL setup is the one for the F7 and does not point to the right address for the H743... what exactly is done in fact ? Who knows 😄

Not funny, all the low level has been modified to fit with the STM32H7 requirements, you just need to check in the right repository. https://github.com/HackInvent/Ada_Drivers_Library https://github.com/HackInvent/bb-runtimes/tree/master/arm/stm32/stm32h7xx

ezwiebel commented 4 years ago

No offense meant...

But still, if you check the flash SVD for H7 in your repo in front of the H7 reference manual, the adresses don't match...

16#40023C00# in your SVD, correct value for F7 0x52002000 in datasheet, correct value for H7

Some other things are not consistent with reference manual. As are some startup scripts. I'm not saying it didn't fulfil your needs, just that it is not mature enough to be shipped as a full H7 runtime... And it's not drama, I would've been happy to find something off the shelf cause I'm a lazy bastard, that's it ;)

HackInvent commented 4 years ago

In my fork I was testing only GPIO/I2C/USART-UART (maybe also SPI) I didn't update the flash peripheral In the process I copied/pasted the code from the F7, and updated it using Nucleo board and Adacore IDE debugger

JCGobbi commented 3 years ago

I don't know if there is still interest on an "off the shelf" runtime and ADL for the STM32H743, but if it is the case, take a look at Nucleo-STM32H743ZI. @lambourg @HackInvent