search

Severson-Group / AMDC-Firmware

Embedded system code (C and Verilog) which runs the AMDC Hardware
http://docs.amdc.dev/firmware
BSD 3-Clause "New" or "Revised" License
30 stars 5 forks source link

VSI task exceeds quantum when logging is enabled #265

Open elsevers opened 2 years ago

elsevers commented 2 years ago

The VSI task is initialized by app_blink_init() (should it be?) in the AMDC v1.0.3 firmware. https://github.com/Severson-Group/AMDC-Firmware/blob/34e5cc6114574cdc6aae188c72c4cf4c26112a56/sdk/app_cpu1/user/usr/blink/app_blink.c#L8-L17

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!
npetersen2 commented 1 year ago

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

See upcoming new ticket from @GnomeTek for more details.

mslaffin commented 1 year ago

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

npetersen2 commented 1 year ago

@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.