Skip to content

Add new Thunderpack v1.1: STM32F411 #1013

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

Merged
merged 7 commits into from
Mar 30, 2020

Conversation

jgillick
Copy link
Contributor

@jgillick jgillick commented Mar 26, 2020

Summary

Adds the new Thunderpack board (v1.1), which replaces the STM32L07 chip from v1 with an STM32F411.

Version 1.1 branch of the project: https://github.com/jgillick/ThunderPack/tree/STM32F4

@fpistm fpistm added the new variant Add support of new bard label Mar 26, 2020
@fpistm
Copy link
Member

fpistm commented Mar 26, 2020

Hi @jgillick
thanks for update.
Please fix the astyle issue:

diff --git a/variants/THUNDERPACK_F411/variant.cpp b/variants/THUNDERPACK_F411/variant.cpp
index 2e1c0a2..7ea64d8 100644
--- a/variants/THUNDERPACK_F411/variant.cpp
+++ b/variants/THUNDERPACK_F411/variant.cpp
@@ -101,8 +101,8 @@ WEAK void SystemClock_Config(void)
   }
 
   // Select PLL as system clock source and configure the HCLK, PCLK1 and PCLK2 clocks dividers
-  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
-                                |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
+  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_SYSCLK
+                                | RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2;
   RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
   RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
   RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV2;

@fpistm
Copy link
Member

fpistm commented Mar 26, 2020

Could you also update this file:
https://github.com/stm32duino/Arduino_Core_STM32/blob/master/CI/build/conf/cores_config.json

to ignore both THUNDERPACK as you rename one and create a new one.

Thanks.

@fpistm fpistm self-requested a review March 26, 2020 08:24
fpistm added 2 commits March 26, 2020 18:02
Since NUM_ANALOG_FIRST is defined and analog pins are contiguous

Signed-off-by: Frederic Pillon <[email protected]>
Signed-off-by: Frederic Pillon <[email protected]>
Copy link
Member

@fpistm fpistm left a comment

Choose a reason for hiding this comment

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

I think it is possible to merge both in the same variant directory.
I will propose you a version.

Signed-off-by: Frederic Pillon <[email protected]>
@fpistm
Copy link
Member

fpistm commented Mar 27, 2020

Hi @jgillick
I've updated your branch with some fixes and also a merge of both variant.
Please, could you test on your side and give me your feedback?
Thanks

@fpistm fpistm added the waiting feedback Further information is required label Mar 27, 2020
@jgillick
Copy link
Contributor Author

@fpistm Your changes work great on both boards. I also made an additional small commit to remove an unused macro.

@fpistm
Copy link
Member

fpistm commented Mar 28, 2020

I though you have a HSE at 24 MHz. I saw it on your schematics.
By default it is 25 8MHz so if it is not this value it have to be define.

@fpistm
Copy link
Member

fpistm commented Mar 28, 2020

From here
image

And by default HSE_VALUE is 8 MHz:

#define HSE_VALUE 8000000U /*!< Value of the External oscillator in Hz */

@fpistm
Copy link
Member

fpistm commented Mar 29, 2020

@jgillick
any update on HSE value ?

@jgillick
Copy link
Contributor Author

Ah, you're absolutely right, thanks for the correction I've reverted that commit.

@fpistm fpistm removed the waiting feedback Further information is required label Mar 30, 2020
@fpistm fpistm added this to the 1.9.0 milestone Mar 30, 2020
@fpistm fpistm merged commit 5c4c35e into stm32duino:master Mar 30, 2020
@matthijskooijman
Copy link
Contributor

@jgillick I'm working on some USB refactoring. Can you tell me if there is an external 1.5k pullup on the board? Or are you relying on the internal pullup (which would be better AFAICS)?

@fpistm
Copy link
Member

fpistm commented Apr 28, 2020

@matthijskooijman
I think no, there is only an ESD protection:
image

@matthijskooijman
Copy link
Contributor

Ok, great! I couldn't find any schematic to confirm yesterday, but this looks good. Thanks, I'll update my commit I'm about to push accordingly.

@fpistm
Copy link
Member

fpistm commented Apr 28, 2020

@jgillick
Copy link
Contributor Author

Yes, that's the correct schematic. I clearly need to update the chip reference, but the rest of the circuit is the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new variant Add support of new bard
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants