Closed mrguen closed 5 years ago
I see two differences in the ldcript provided as compared to Altium's:
1. possibly missing No _Min_Heap_Size = 0x400; /* required amount of heap */ that was in the original Altium project 2. Added properties . = ALIGN(4); in many places
This is correct. https://github.com/stm32duino/Arduino_Core_STM32/pull/604/commits/37f6252e8b4f1948e839f9f6c78fe50ad267f9cf#diff-fddda161300d628fd4ca3bfe7a9fa835R58
The proposed PeripheralPins.c discards TIM9, TIM10 and TIM11 but I see in variant.cpp
define TIMER_TONE TIM10
define TIMER_SERVO TIM11
So it might be necessary to reactivate TIM10_CH1 instead of TIM4_CH3 TIM11_CH1 instead of TIM4_CH3 ?
No, there is no link between Tone or Servo and the Pinmap PWM array which is used for analogWrite
... Tone or Servo use the hardware timer resources and are not link to a pin....
To upload using STM32Prog, BOOT0= 1 but in this case pushing reset does not reset the program and BOOT0 must be set to 0 to manually reset.
Right this is normal... to start the program you have to come back to default Boot pattern else you start in Bootloader mode...
Passed: Blink: ok AnalogReadSerial: A0 and A15 : ok DigitalReadSerial : all 46 pins Ok but PA11 and PA12 that are DM and DP thus canno't have serial
Not ok: IWDG_button: WDT does not seem to reset eeprom_wite (value = 100) then eeprom_read: all values are '255'
For IWDG and eeprom I've tested a F401RE without any issue. About IWDG ensure to have boot0 set to 0. For eeprom, I can not help.
Your update of PeripheralPins.c is not correct and I don't understand why you do this. Anyway I will kept the variant as it is. Basic features worked including USB. Thanks for the test.
PeripheralPins.c is the file from https://github.com/stm32duino/Arduino_Tools/tree/master/src/genpinmap/Arduino/STM32F401R(B-C)Tx
It seems the other lacked some pin/timer mapping (maybe I am wrong of course I don't know this as you do)
With pin arbitration between Timers defined as in the excel file in the .zip.
I will do some other things tomorrow and come back to this afterward if you'd like.
This is the same files except the commented lines...
Yes possibly but I find it nice to have all possible mappings written. I have checked all are correct / datasheet and chose to promote TIM2 and TIM5 instead of TIM9/10/11 because they are 32 bits and that is what I am looking for with this IC !
Well as said the PWM array is for analogWrite()
to generate the PWM so we don't bother if 16 or 32 bits.
Moreover with the Hardware Timer library, we use all timer as 16 bits for genericity purpose:
https://github.com/stm32duino/wiki/wiki/HardwareTimer-library#1-introduction
But nothing prevents you from using a timer in 32 bits using LL or HAL directly!
Thanks for the info... I am very much surprised. I will have a look at the library. Usually it is also possible to access the registers so I don't see why it wouldn't be 32 bits.
For the provided API 16 bits is enough. For further use case HAL/LL could be used.
Helllo, Thanks for the huge quantity of work!
I would like to know if you plan to include in the release 1.7.0 these generic variants for F401
STM32F401CC in UFQFPN48 and LQFP64 packages
STM32F401RCT6 in LQFP64 package
Generally speaking how do you handle the different packages versions?