Printf fails half way through printing, causing firmware to cease execution?

[ironsean]

Hello,

I'm using the KSDK 1.1.0 and KDS 2.0.0 with a FRDM-K64F development board, running a new project I started with the guide in this discussion (How To: Create a New MQX RTOS for KSDK Project in KDS) I'm using the J-Link emulator with firmware 4.92 to debug. I can compile and run sample applications fine, or the Hello World application included in the linked post. However, when I then try to make a more complex project I'm running into an issue where my code ceases execution part way through printing a printf statement. I'll get partial output before debugging crashes and execution ceases like below. Flashing instead of debugging also does the same:

When the Hello and World tasks run first, I get this:

" Hello

World

Main task has started.

C"

And when I lower their priority I get this:

"Main task has started.

Config loaded, confi"

And when I remove them completely I get:

"Main task has started.

Config loaded, config" (One extra character).

(It should be printing "Config loaded, configID %d and errors %d" with 10 and 0, respectively.)

When I remove the config code and jump to the message queue code I instead get:

"Main task has started.

Initializing message que"

And there's no real code above that print so it seems to just freeze up on print calls.

I see in the debugger that _task_set_error() is entered, but in the Task List both the Main and _mqx_idle_task are OK with no error code.

In fact, I've removed almost all code except the printf statements, so it seems to be related to that that causes the crashing. Here is the most pared down code I've tried that still causes the error stopping at

"Main task has started.

Initializing message que"

#include <stdio.h>
#include <mqx.h>
#include <bsp.h>


void messaging_init(void);




void main_task(uint32_t temp)
{
  uint32_t  error, file_error;
  printf("Main task has started.\n");


  messaging_init();
}


void messaging_init(void)
{
  uint32_t result;
  printf("Initializing message queues...\n");
}

Thanks,

Sean

[ironsean · Accepted solution]

I've found out what the issue is. As found and properly described by auralcircuitry in the discussion on this guide (How To: Create a New MQX RTOS for KSDK Project in KDS) the issue is caused by the Systick_Handler not being found. This means that every time MQX is supposed to tick (every 5ms, or 200Hz), an interrupt is fired and unhandled, causing execution to cease. It's supposed to be in _Boot.S.

A workaround is defining a function in your code to process the interrupt such as this:

void SysTick_Handler(void) {}

However, this would override the actual SysTick_Handler, meaning whatever function it's supposed to perform (counting ticks? Used for the internal timing of who knows what within the MQX RTOS) won't be performed, which has to cause issues. Also, it's hard to know what else is not properly linked that will go unhandled this way.

[ironsean]

Here is the pared down project file. Note that the hello and world tasks are even disabled, and the messaging.h file not even included. Two computers and multiple K64Fs don't work with it, so it's either a conflict with the old CodeWarrior system still being installed or a problem with the project config/settings.

Sean

[ironsean]

Additional information: I tried switching from the Small Ram config to the Maximum config, with no differences.

Also, I've found out that if I use the debugger to step through the printf function calls, stepping into it until at least one character prints, then I can use the step return option to back out of the functions and have the entire print call execute correctly. If I'm not stepping through the internal functions with the debugger than it fails part way through and output/execution/debugging ceases.

[ironsean]

Further, A single printf which is too large also fails part way through. Adding _time_delay() calls after does not help. In fact the time delay call also will halt execution and cease debugging. I stepped through a _time_delay() call and in the _time_delay() function in time.c, around like 380, It nearly completed operation, but then the debugger failed to step into/past the _INT_ENABLE() function call at line 404, or possibly the _KLOGX1(KLOG_time_delay); call at 406.

I've also tried programming with the Segger debugger and the Segger OpenSDA V2 firmware sated April 23, the original undated OpenSDA V2, the Mbed K64F firmware Rev 0221 and the OpenOCD debugger, or the PEMicro K64F Firmware V108 and the PEMicro debugger. No change with any.

[ironsean]

Have confirmed with another Windows 8 machine and another K64F board with the same results.