Hi Anthony and others,
Thanks for your excellent discussion of init_bsp() problems and getting stuck in the dispatch.s!!
I have a very similar problem where at startup my _bsp_enable_card function in init_bsp.c hangs inside the dispatch.s loop in _pend_svc (near no_one_to_run). We are using MQX 4.0 on a Kinetis K20 with a custom board. Our BSP was cloned from the TWRK20D72M BSP.
The calling tree is:
main -> _mqx -> _bsp_enable_card -> systick_init -> <excpt 0xE> -> _pend_svc (dispatch.s).
In my case, I believe that when our bootloader starts up (after a software reset or else a watchdog timeout reset), that the bootloader jumps to MQX main entry point when somehow there is still a pending PENDSV task switch request.
The PENDSVSET bit is set in the SCB ICSR register (asynchronous PENDSV is pending but not yet handled) at the time the init_bsp() function calls _bsp_enable_card. When the systick_init function modifies the SVCall priority by writing to the SCB_SHPR2 register, the asynchronous pending exception is immediately triggered (see the bold line from init_bsp.c code:
static void systick_init(void)
{
/* Get system clock for active clock configuration */
uint32_t system_clock = _cm_get_clock(_cm_get_clock_configuration(), CM_CLOCK_SOURCE_CORE);
.
.
systick_config(system_clock, BSP_ALARM_FREQUENCY);
SYST_CSR = 7;
/* SVCall priority*/
SCB_SHPR2 |= 0x10000000; <------ Exception 0xE (PENDSV) occurs right here
/* SysTick priority*/
SCB_SHPR3 |= SCB_SHPR3_PRI_15(CORTEX_PRIOR(BSP_TIMER_INTERRUPT_PRIORITY));
}I assume that SVC priority bits in SHPR2 apply to both SVCall and PENDSV exceptions? Once the SVC priority has been elevated, this triggers the asynchronous pending PENDSV exception 14 (0xE) immediately, and the code is hijacked away to the _pend_svc handler for vector 0x0E (ivINT_PendableSrvReq). Of course this is problematic as there are no MQX tasks initialized at the time that _bsp_enable_card is called by the MQX BSP initialization code!!!
Note the calling stack at the time I get the exception in the images below.
SCB registers including ICSR:
So the next question then is why is there a pending service request (PENDSVSET bit is 1 and VECTPENDING is 0xE) when MQX starts up?
I have been testing hundreds of deliberate software resets to repeat MQX initialization, and finally was able to repeat the intermittent hang or loop in dispatch.s where this issue occurred. After each software reset (deliberately setting SYSRESETREQ bit in AIRCR at the completion of the completion of the autostart task), our bootloader will run after reset and jump to the application entry point which calls the application main() entry point which starts up MQX. Is it possible that somehow that the ICSR register (and in particular the pending service request PENDSVSET) was not cleared at the time a software reset was performed (via SYSRESETREQ) or when a watchdog timeout in WDOG causes a reset? Normally, I would not expect that there would be any service requests for a task switch pending (PENDSV) during MQX startup.
Your comments are most appreciated!
Cheers,
Gord Finlay
Robert,
Let me try to explain the Z issue. One of the issues we encountered was that the micro we were using on our board had the Z in the part number. The Z in the part number denotes initial silicon from Freescale. There are newer parts that do not have the Z in them. Our issue was that we were trying to clone a BSP from a newer silicon part (non-Z) and then trying to use that BSP on an older silicon part (Z). It is my understanding that If you cloned the twrk60n512, then this should not be your issue. But it was ours and what you described is very similar to what was occuring for us.
Do you have your debugger set to start at program entry point or main? We were able to debugger this issue when it was set to program entry point.
Thanks,
Doug
