Marlin: STM32F407 troubles

[mr-miky]

STM32F407

Infinite loop before main() if REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER is enabled.

Steps to Reproduce

if REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER is enabled the card that I am developing (based on STM32F407) enters a continuous loop even before calling main() and consequently setup().

I investigated with the debugger and the micro-controller remains in continuous loop to wait for a delayMicroseconds that calls HAL_GetTick which unfortunately is always 0.

The strange thing is that the loop happens in startup_stm32f407xx.s at

/* Call static constructors */
   bl __libc_init_array

It seems that in some constructor delayMicroseconds is used.

I'm not an expert but what I understand is that SystemClock_Config of variant.c runs AFTER __libc_init_array and therefore the Systick is not configured.

I circumvented the obstacle by modifying system_stm32f4xx.c, adding HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq() / 1000); to SystemInit.

I think it's not the right solution but for the moment it works, maybe it's time to investigate.

[mr-miky]

another possible trick is to add an override of preinitVariant () in variant.c

void preinitVariant(void) {
  HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);
  HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);
}

[thinkyhead]

delayMicroseconds is called from the LiquidCrystal constructors (at least, for LPC1768). Some other external libs might also use it.

[p3p]

The strange thing is that the loop happens in startup_stm32f407xx.s at

Not so strange, global objects are initialised and constructed very early in the boot process often before the frameworks initialise the hardware which can be a problem as you might imagine. I'm not sure which library is calling your frameworks delayMicroseconds function in its constructor but Arduino based ARM platforms seem to default to using it for U8glibs delay function. We'l have to look into it a bit more as we cant modify the framework directly I don't think.

[xC0000005]

There's an open PR for STM32 Generic for exactly this problem, IIRC.

[xC0000005]

Here you go, opened by one of the people that worked on either F4 or F7 support:
https://github.com/danieleff/STM32GENERIC/pull/58

[mr-miky]

Unfortunately I limited myself to update STM32Generic without going to read the issues and PR.
It took me a week to figure out where the problem was, but that's okay so I analyzed what happens between the reset and the main ().
As far as I'm concerned, I've found a way to get around the obstacle and continue with the development of the hardware. I thought it appropriate to point this out so as to prevent someone else from wasting time.

[ktand]

In my fork of STM32GENERIC, branch devel, I have made the following adjustments:

• Force init() to be called first i.e. before static object allocation. Otherwise, statically allocated objects that need HAL may fail. For example the U8G library uses delayMicroseconds() which will never complete if SysTick timer is not initialized.
• Include binary.h for Arduino compatibility
• Fix flawed software PWM handling. It could happen that the timer used for PWM was not being reloaded correctly which could cause the PWM to stop working for up to 2^32 timer cycles... Preferably I would like to use the official STM32_Arduino_Core implementation that uses hardware PWM but unfortunately it does not support USBSerial yet.

Using the above fork, I have successfully tested the following "features" with my custom STM32F407 board:

• REPRAP_DISCOUNT_SMART_CONTROLLER
• REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
• External eeprom
• MAX7219 debug display
• SD card

[xC0000005]

Are you building using platformio? If so, what changes did you make to get the package to install/build?

[ktand]

Yes, I'm building using platformio for VS Code,

I'm using michael_l's fork of platformio/platform-ststm32. It was a long time ago but I think I followed the instructions here: http://www.stm32duino.com/viewtopic.php?t=2066

[mr-miky]

Ktand ,
are you sure it's all right in PWM.c?
I do not understand why PA0 is altered when it is called bltouch_init () which precisely uses the pwm but on another pin

[ktand]

I had issues with pwm in STM32GENERIC, see
https://github.com/danieleff/STM32GENERIC/issues/59. To resolve the issues
I created my own implementation. I have not yet submitted a PR for this but
you can find the changes here:
https://github.com/ktand/STM32GENERIC/tree/software_pwm

The PWM in STM32GENERIC does not use hardware PWM. I would recommend using
the official Arduino Core STM32. I'm using it with my own board based on
STM32F407 and it works just fine.

Regards,
Karl

On Sun, Sep 30, 2018 at 6:02 PM mr-miky [e-mail] wrote:

Ktand ,
are you sure it's all right in PWM.c?
I do not understand why PA0 is altered when it is called bltouch_init ()
which precisely uses the pwm but on another pin

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/10787#issuecomment-425731234,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQ8NJG_UMUjDddxetTKQCYPJdiQiRmUlks5ugOsqgaJpZM4UF1FP
.

[mr-miky]

@ktand

I'm already using your source code for the pwm. The original one is practically unusable. This is only happens with PA0, which is the 0 element of the pin array. Mine is just a suspect because I find the led of the extruder 2 turned on after the bltouch is initialized. On the board I made I assigned PA0 the control of the heating of an extruder that in fact I do not use waiting to investigate better.

[mr-miky]

@ktand

Something certainly does not work as it should.
The waveform is correct if the frequency of the pwm is 1KHz but if, for example, you set a pwm with frequency 50Hz ( BLTouch) you get a waveform with 100% PWM (always at high level). With 200Hz you get a 50% PWM and 1KHz frequency.
I took a quick look at the pwm.c but tonight I think to investigate better.

[ktand]

I have switched core to the official STM32 core for my STM32F407 based
board. Maybe I get some time this weekend to do some tests with
STM32GENERIC.

On Thu, Nov 8, 2018 at 7:58 PM mr-miky [e-mail] wrote:

@ktand https://github.com/ktand

Something certainly does not work as it should.
The waveform is correct if the frequency of the pwm is 1KHz but if, for
example, you set a pwm with frequency 50Hz / BLTouch) you get a waveform
with 100% PWM (always at high level). With 200Hz you get a 50% PWM and 1KHz
frequency.
I took a quick look at the pwm.c but tonight I think to investigate better.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/10787#issuecomment-437115916,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQ8NJIuLRla1HTI97KtWl_vw1Mtht2Ykks5utH7hgaJpZM4UF1FP
.

[mr-miky]

@ktand , tell me if I understood correctly,

Timer 2 generates an interrupt every 1ms.
At the interrupt you load the capture & compare with the difference between the current period and the next nearest period. When C&C generates the interrupt, yuo change the state of the related pin and repeat what was done before moving to the next 'near' period.
At the next timer interrupt (not the c&c) reset all pins to 0.
What I do not understand is how do you generate a 50Hz frequency pwm that has a period of 20ms. You should wait for 20 interrupts at 1msec but it does not seem to me that there is nothing that considers this

[boelle]

@mr-miky this is still an issue right?

[mr-miky]

The first problem, but I have not tried, has been fixed in the latest version of stm32Generic.
The PWM fixed as suggested above works but still has problems with the servo library.

[thinkyhead]

Report a new bug with whatever is left and we can put this one away.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.