New version 1.8.0 and Hardware Timer on MK4duo FW printer 3D

[MagoKimbra]

Hi, sorry for my bad english.
I need your help.
I am the programmer of MK4duo firmware for 3D printers.
I am using a Rumba32 with STM32F4.
Using version 1.7.0 of STM32core.
I use the TIM2 timer for the movement of the motors.
I use Hardware timer and everything works perfectly.
Yesterday I updated to version 1.8.0 and now when I try to move the motors everything freezes, the card freezes and no longer responds, it must be turned off and on again.
This is the routine I use to initialize the timer, and the routines for reading the count and write the new count:

#define STEP_TIMER TIM2
#define STEPPER_TIMER_PRESCALE 2
#define HAL_TIMER_TYPE_MAX 0xFFFFFFF

FORCE_INLINE bool HAL_timer_initialized() {
  return MK_step_timer != nullptr;
}

FORCE_INLINE bool HAL_timer_interrupt_is_enabled() {
  return HAL_timer_initialized() && MK_step_timer->hasInterrupt();
}

FORCE_INLINE hal_timer_t HAL_timer_get_current_count(const uint8_t) {
  return HAL_timer_initialized() ? MK_step_timer->getCount() : 0;
}

FORCE_INLINE void HAL_timer_set_count(const uint8_t, const hal_timer_t count) {
  if (HAL_timer_initialized()) {
    MK_step_timer->setOverflow(count + 1, TICK_FORMAT);
    if (count < MK_step_timer->getCount()) MK_step_timer->refresh(); // Generate an immediate update interrupt
}

void HAL_timer_start() {
  if (!HAL_timer_initialized()) {
    MK_step_timer = new HardwareTimer(STEP_TIMER);
    MK_step_timer->setInterruptPriority(NvicPriorityStepper, 0);
    MK_step_timer->setPrescaleFactor(STEPPER_TIMER_PRESCALE);
    MK_step_timer->setOverflow(HAL_TIMER_TYPE_MAX, TICK_FORMAT);
    MK_step_timer->attachInterrupt(Step_Handler);
    MK_step_timer->resume();
  }
}

void HAL_timer_enable_interrupt() {
  if (HAL_timer_initialized() && !MK_step_timer->hasInterrupt()) {
    MK_step_timer->attachInterrupt(Step_Handler);
  }
}

void HAL_timer_disable_interrupt() {
  if (HAL_timer_initialized() && MK_step_timer->hasInterrupt()) {
    MK_step_timer->detachInterrupt();
  }
}

uint32_t HAL_timer_get_Clk_Freq() {
  return HAL_timer_initialized() ? MK_step_timer->getTimerClkFreq() : 0;
}

I'm trying in every way to understand where the problem may be, but I really don't understand it.
I kindly ask you to give me a hand, even just to make me understand where the differences are between 1.7.0 and 1.8.0.
The rest works everything, analog reading, pwm pin.
Use Hardware Timer only for Motors.
Thank's.

EDIT: Ok I understand where the problem is.
By default the timer is in TIMER_DISABLED, so it does not perform the callback.
You have to set the mode with setMode in TIMER_OUTPUT_COMPARE, but there is no command to set the entire timer only the channel.
I solved it by putting setMode (1, TIMER_OUTPUT_COMPARE), but wouldn't it be more logical to create a command for the whole timer if you don't use the channels?

[fpistm]

Hi @MagoKimbra
thanks for the report.
Some updates have been made around the HardwareTimer API after several feedback from Marlin contributors (ex: @LinoBarreca ) .
I will let @ABOSTM comment when we will come back from holidays.

[LinoBarreca]

so is 1.8 officially out? :) Nice.
We will wait for PlatformIO to make a platform update and then we will patch what we did for 5.7.0.
I guess everyone is on vacation for Christmas right now.
By the way...Happy new year to everyone reading this <3

[ABOSTM]

Happy New year to all.
Hi @MagoKimbra,
It was the good thing to do : using setMode (1, TIMER_OUTPUT_COMPARE)
This is the way it is done in example: Timebase_callback

Nevertheless, thanks to the new implementation of HardwareTimer #806
implementation is easy to get ride of setMode() in such case.
Timer will start on resume() if callback is configured.
(and no need for a new command to set the entire timer)
see #849

[fpistm]

@MagoKimbra
Thanks @ABOSTM , I've merged #849.
I guess this solve your issue.
So I close this one. Let us know if you have any issue with that.

[MagoKimbra]

Sorry, but I've been out ... Thanks so much for the answers. The problem is not the solution that is always found, only that by releasing a firmware that relies on arduino IDE and the library, if the library changes something that normally was another thing by default, users who compile find that it does not work nothing, and it is difficult to understand why.
Then I found the solution and I also thank you for the various suggestions and subsequent changes ...
Happy New Year and sorry for the delay.

[fpistm]

@MagoKimbra
thanks for the feedback, you are right.
The API has not changed but the internal way yes but old code would be compatible.
Anyway you point a case where it is not. Now it is fixed thanks @ABOSTM and you code should be functional as before (thanks #849).

[philbowles]

Are you sure its fixed? Just compiled some code on the 1.8.0 downloaded an hour ago using Arduino 1.8.10, target = STM32-NUCLEOF429ZI...and NOTHING works, Serial hangs up, no values on GPIO pins...its unusable. Even the example blinky won't run.

Reverted the untouched code to 1.7.0 and it runs exactly as expected and always has done. There is a serious problem in 1.8.0

[fpistm]

@philbowles
Yes. It is fixed.

There is a serious problem in 1.8.0

Well, before telling this, ask you if your config is correct.
Claiming this not runs as expected does not help. I can simply answer it works on my side and then we close the discussion.
Do you really think the 1.8.0 core released since 2 month is unusable ? I guess we will got several feedback about that mainly for a simple blink.
So, be precise on your issue(s), environment/configuration and a away to reproduce with Arduino IDE.
Note that we do not support PIO environnement only in Arduino IDE env.

You can open a topic on the forum then we can discuss about this.

[philbowles]

"Do you really think the 1.8.0 core released since 2 month is unusable ?" Obviously "Yes", or I wouldn't have made the post. Maybe no-one has used it with a 429ZI? Just because it works on other boards, assuming it works for everything is not a good place to start from when I have cited a serious problem. I'm not doing this for fun, or imagining it, I'm doing it because my 429ZI is unusable with 1.8.0. and I'd appreciate it if you would take the matter seriously as I have been programming for 45 years and have a reputation for usually knowing what I'm talking about...

I will try to be more precise. I'm using ArduinoIDE 1.8.10 - I select Nucleo-144 then F429ZI and leave all the settings as default. I'm running on Windows 10. I can't think of any information that could help. What other "config" do you need?

I then take code that has been running fine on 1.7.0. for a long time. Serial.print hangs. I remove all serial prints and run the code again. It fails to recognise any GPIO pin change. I wire the pin to 5V, digitalRead returns zero. I GND the pin, it reads zero. I wiggle the wire. I use a new wire. I wet my finger and hold the end of the wire: No signal is received from the pin, period.

I revert the untouched code to 1.7.0 - it works perfectly, as it always has done.

I then re-up to 1.8.0 to provide a sample sketch for an issue report. I select the blinky. It hangs. LED goes on, then nothing. I add a Serial.begin(115200) and a serial.print in the loop just to see if it really is hanging. The serial monitor (set at 115200) prints a single garbage character then hangs.

This is pretty much my definition of "unsuable". I revert again to 1.7.0, everything works perfectly again.

So in answer again to your question "Do you think 1.8.0 ...is unusable...." then true answer is, "No, I KNOW it is on my 429ZI"

I would be grateful for any further suggestions, till then I will stick with 1.7.0, which works.

[philbowles]

"Note that we do not support PIO environnement only in Arduino IDE env." Note that I told you the first time I was using ArduinoIDE 1.8.10.

[fpistm]

Maybe no-one has used it with a 429ZI? Just because it works on other boards, assuming it works for everything is not a good place to start from when I have cited a serious problem.

You really think it is only an "assuming" ? Nucleo F429ZI works fine, blink, Ethernet, Serial, RTC,....

I'm not doing this for fun, or imagining it, I'm doing it because my 429ZI is unusable with 1.8.0. and I'd appreciate it if you would take the matter seriously as I have been programming for 45 years and have a reputation for usually knowing what I'm talking about...

Don't know nor can't guess why your one does not work.
What I can say is I see several time user coming and claiming it's not work without any description.
The fact a simple blink does not work, I think you have a config/environment issue but never reproduced or reported by any other user than you. So, as an 45 years old experiencing programmer, I guess you can figure out that my first feeling is you probably get an issue on your side?

Did you test with an other board?
Full erase your boards using the STM32CubeProgrammer, update the stlink firmware,...

[fpistm]

@philbowles
Forgot to tell you should open a topic on the forum and I also always try to help if I can. 😉