While inspecting the context switch mechanism for msp430, I realized that in addition to all registers being pushed onto the stack, the critical nesting counter also has to be saved.

portSAVE_CONTEXT macro

    /* Save the remaining registers. */
    pushm_x #12, r15                ; Pushes registers r4 through r15 onto the stack
    mov.w   &usCriticalNesting, r14 ; Need to save the task specific critical nesting counter
    push_x  r14
    mov_x   &pxCurrentTCB, r12      ; copy pointer to TCB structure into r12
    mov_x   sp, 0( r12 )            ; pxTopOfStack is the first field in the TCB structure, so this copies the stack pointer into pxTopOfStack by dereferencing r12
    endm

What is the reason for having a separate global variable usCriticalNesting and having to save/restore it every time a context switch occurs? Why not have usCriticalNesting be part of the TCB_t structure, which would make context switching easier?

The TCB is common to all FreeRTOS ports (of which there are many), whereas the critical section handling is different on each port, and often optimised in a way it couldn’t be if the count was in the TCB (because the count would have to be retrieved from the TCB when the task was restored). Some ports define portCRITICALNESTINGIN_TCB to 1, in which case the nesting count IS in the TCB – but the MSP430 port is very old and pre-dates that feature.

Thanks for the quick response. If I update the msp430 port to support portCRITICALNESTINGIN_TCB, where would I submit a patch?

This used to be done via the FreeRTOS Interactive site, but unfortunately the forum hosts no longer allow attachments to the posts.