ARMmbed
Experimental compilers - Add HIC with STM32WB55RG
That is a lot of commits and a lot of new files. Would it be possible to clean up this PR by squashing some of those commits and review if all changes are relevant? Looking at the other STM32 HICs, I don't think the whole STM32F3xx_HAL_Driver directory is needed.
That is a lot of commits and a lot of new files. Would it be possible to clean up this PR by squashing some of those commits and review if all changes are relevant? Looking at the other STM32 HICs, I don't think the whole
STM32F3xx_HAL_Driverdirectory is needed.
@mathias-arm yes there lots of commits. We know that. The reason is three of us (students doing PG at college) are located at three different locations (due to corona) and only one of us have the board. Also, there is no documentation on how to add a new HIC. So we are trying out many things leading to lot of pushes from our side. But we will streamline everything after removing all the necessary files when we are done. Currently, the major mods we did are
- Modified the daplink_addr.h file to incorporate our uC (stm32f373xc) Flash & RAM size
- Modified the IO_Config.h file to suit our board design.
- Modified the linker script to talk properly to the startup file generated from STM32 Cube IDE
Now we are able to generate and program the binary file. uC is also starting up well and blinking LEDs (as we configured) etc. But the USB is not enumerating. This we think is because the usbd_STM32F373.c needs to be modified to use the STM32Cube HAL which is what we are doing. If you know a better and easier way to fix the usbd_STM32F373.c please let us know. The one on the stm32f103xb is not working for our stm32f373xc.
Hi @symovs, @BibyThm and @Ashleyvk,
Different projects use different processes for handling issues and pull requests in GitHub. A pull request brings the expectation of something close to be merged (there is an option to create a "draft" pull request). I think this pull request might have been created too early because it now adds two HICs and at least one of them is not working according to your comments.
You should create a discussion for each of the HICs and move there the comments you made in other issues and pull requests. You should also probably keep the two porting efforts in separate branches of your repository.
There are several HICs already supported in DAPLink, if you want to attract the help of others you could explain the motivation to add support for those MCUs.
Hi @symovs, @BibyThm and @Ashleyvk,
Different projects use different processes for handling issues and pull requests in GitHub. A pull request brings the expectation of something close to be merged (there is an option to create a "draft" pull request). I think this pull request might have been created too early because it now adds two HICs and at least one of them is not working according to your comments.
You should create a discussion for each of the HICs and move there the comments you made in other issues and pull requests. You should also probably keep the two porting efforts in separate branches of your repository.
There are several HICs already supported in DAPLink, if you want to attract the help of others you could explain the motivation to add support for those MCUs.
Hi @mathias-arm, We will create a separate pull request for STM32WB55RG HIC. For the project we are doing, we actually require STM32WB55RG HIC. We had given the board for manufacturing and meanwhile, we were working on STM32F373CC, which was available to us. The board is now manufactured and hence we moved to STM32WB55RG. The USB enumeration problem still exists with STM32F373CC and we were trying to resolve it. We will update the firmware for STM32F373CC once we resolve the issue in STM32WB55RG.
That is a lot of commits and a lot of new files. Would it be possible to clean up this PR by squashing some of those commits and review if all changes are relevant?
Closing this PR that is clearly too far from being mergeable. Open a new one when this have been cleaned up.
