I experimented sudden board hangup/not responsive behavior with some S3D files. I tried wolfmanjm hack but still no relief.
Problem arises with S3D generated files, probably because of his great quantity of small (1 micro step ?!? looking for troubles…) moves.
After many hours of debugging, I think I have found something to share in this forum.
When a move has finished (last step sent to a motor) StepTicker::TIMER0_IRQHandler schedules a PendSV_IRQHandler interrupt service.
During PendSV_IRQHandler (300us ?) a lot of callbacks gets invoked, namely StepperMotor::signal_move_finished. This routine frees old movement block and (if there is a fresh block ready) schedules a new move, adding the motor to stepTicker active motor list.
BUT: if in meanwhile StepTicker::TIMER0_IRQHandler is called again (his priority is higher than PendSV) in some conditions motor gets removed from active list. I guess this happens with VERY SHORT moves (that start and end while PendSV is still being serviced ?)
As a result, we have x steps to make and no motor to service them, so board hangs up. At least, this is what I discovered thanks to a stroke of luck (a file that hangs my printer always at the same line)
I tried to stop TIMER0 while servicing PendSV and restart immediately before exiting. Now my printer is printing correctly.
I don’t know if stopping the 10us IRQ during PendSV can lead to other problems…surely I cannot perceive the 300 us delays.
Any comments ?
Imported from wikidot