Skip to content
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

VSI task exceeds quantum when logging is enabled #265

Open
elsevers opened this issue Mar 27, 2022 · 3 comments · Fixed by #278
Open

VSI task exceeds quantum when logging is enabled #265

elsevers opened this issue Mar 27, 2022 · 3 comments · Fixed by #278
Assignees
Labels
bug Something isn't working

Comments

@elsevers
Copy link
Contributor

The VSI task is initialized by app_blink_init() (should it be?) in the AMDC v1.0.3 firmware.

void app_blink_init(void)
{
// Register "blink" command with system
cmd_blink_register();
// Initialize blink task with system
task_blink_init();
task_vsi_init();
}

When the code is compiled with time quantum checking and logging turned on, it causes the AMDC code to error out upon boot up with this message displayed on the UART: ERROR: OVERRUN SCHEDULER TIME QUANTUM! This happens immediately upon completion of the initialization code.

Interestingly, if I run this in a debug environment, where I hit the go button on CPU 0 and then CPU 1, I do not have this issue. So there does seem to be some element of a race condition here.

user_config.h compile options:

#define USER_CONFIG_ENABLE_TIME_QUANTUM_CHECKING (1)
#define USER_CONFIG_ENABLE_LOGGING (1)

Printout of UART terminal

BSP:    Initializing...
ENC:    Initializing...
ENC:    Setting pulses per rev bits = 14...
PWM:    Initializing...
STATUS LINES:   Initializing...
DAC:    Initializing...
EDDY CURRENT SENSOR:    Initializing...
GP3IO LINES:    Initializing...
DB:     Initializing serial task...
CMD:    Initializing command tasks...
SCHED:  Initializing scheduler...
SCHED:  Tasks per second: 10000
SCHED:  Running scheduler...
ERROR: OVERRUN SCHEDULER TIME QUANTUM!
@elsevers elsevers added the bug Something isn't working label Mar 27, 2022
@npetersen2 npetersen2 linked a pull request Jul 1, 2022 that will close this issue
@npetersen2 npetersen2 self-assigned this Jul 7, 2022
@npetersen2
Copy link
Collaborator

Supposedly solved in #278, but according to @GnomeTek there are still issues.

See upcoming new ticket from @GnomeTek for more details.

@mslaffin
Copy link
Contributor

mslaffin commented Oct 4, 2022

I ran into the same issue that was reported here. Does anyone know where the reference from @GnomeTek is indicated to provide more details?

@mslaffin mslaffin reopened this Oct 4, 2022
@npetersen2
Copy link
Collaborator

npetersen2 commented Oct 5, 2022

@mslaffin thanks for reporting this.

If you are interested in trying to track this down, this PR (#281 or #106) provides a code profiling timer API which will help figure out what is taking so long. Since the system has only one single interrupt, it should be straight forward to debug and find the slow element.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants