Naturally, I have several project ideas lingering around. No time to make them all (for now). One of it is interfacing the Raspberry Pi camera with a microcontroller. To store the images, I need plenty of RAM on the device, and so far the Kinetis microcontroller did not have that. Finally, Freescale announced the K64F120 a few months back, and my ordered TWR-K64F120M board arrived on my desk, waiting to be used: Finally I get an ARM Cortex-M4F with 1 MByte of FLASH and 256 KByte of RAM :-).

TWR-K64F120M

The box has comes with Quick Start Guide, USB cable, RTC battery and the board in an anti-static black card box:

The processor on the board is a MK64FN1M0VMD12 (120 MHz max clock, 1 MB FLASH, 256 KB RAM, Floating Point Unit in a 144 MAPBGA package).

The board features many configuration jumpers, plus the ‘usual’ Tower board components: LED’s, push buttons, potentiometer, accelerometer. I comes with an onboard debug interface (OpenSDA):

The back side has an SD card socket plus a holder for the battery:

Demo Software?

According to the Quick Start Guide, there should be an accelerometer application running on the board, but somehow this was not true (at least for my board): the LED’s did not do anything. There is no CD/DVD with the kit, so I was up to go to the Freescale web page (http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=TWR-K64F120M) to get my demo software loaded.

Debug Interface

The board came with this OpenSDA Firmware installed:

Eclipse Kepler

I used my Kepler DIY tool chain, and I was able to debug the board with Segger J-Link through the onboard JTAG connecter, using the V480f Segger firmware with GDB and the default board settings. For unknown reasons I was not able to use the P&E GDB Server or P&E Universal Multilink (still under investigation). The Processor Expert Driver Suite 10.3 already comes with K64F support.

CodeWarrior for MCU10.5

CodeWarrior for MCU needs a service pack added to have support for the K64F:

I already had previously installed the CW MCU v10.5 PEx Update 1.0.0. With this, I was able to create and build K64F projects using CodeWarrior. I have the same OpenSDA problem, so this let me believe that Freescale has put the wrong firmware on the board, or that my board might be damaged. Although the OpenSDA K20 microcontroller works for me as USB CDC interface.

UPDATE: Jumper J39 needs to be installed

Finally I have identified the problem why the OpenSDA debug does not work: My board (RevA, SCH B1) did *not* have J39 installed (but quickstart says it is ON by default :-(). J39 routes the SWD_CLK_TGTMCU:

The jumper is located here (I have put a blue jumper on it):

Now OpenSDA finally works!

❗ Note that using the JTAG debug port (e.g. with Segger GDB server), the jumper J39 *has to be removed*! If the jumper is on, then the Segger GDB server silently quits (crashes?). Actually it shows an error message, then closes.

UPDATE2: There is another jumper missing on the board: J16 should be set on 1-2 position, otherwise a P&E Multilink will not be able to connect to the target, and the reset button will not work:

Demo Application

As there was no demo application for the board available, I started my one using Eclipse Kepler with Processor Expert DriverSuite 10.3, ARM GNU gcc and GDB. The project is available on GitHub.

So far the demo includes the following:

• FreeRTOS V8.0.0
• 4 User LED’s
• Command Line Shell
• SD card with FatFS
• Push buttons
• Accelerometer

Shell

The OpenSDA USB CDC is used as console/shell interface (38400 Baud):

Accelerometer

The ‘main’ task blinks the blue user LED, and changes the other LED’s according the accelerometer tilt:

static portTASK_FUNCTION(MainTask, pvParameters) {
  #if PL_HAS_ACCELEROMETER
  int16_t xmg, ymg;
  #endif

  (void)pvParameters; /* parameter not used */
  #if PL_HAS_ACCELEROMETER
  (void)MMA1_Enable(); /* enable accelerometer */
  #endif
  for(;;) {
    #if PL_HAS_KEYS
    KEY1_ScanKeys();
    #endif
    #if PL_HAS_ACCELEROMETER
    xmg = MMA1_GetXmg();
    ymg = MMA1_GetYmg();
    LED1_Put(xmg>100||xmg<-100||ymg>100||ymg<-100);
    LED2_Put(xmg>500||xmg<-500||ymg>500||ymg<-500);
    LED3_Put(xmg>800||xmg<-800||ymg>800||ymg<-800);
    #endif
    LED4_Neg();
    FRTOS1_vTaskDelay(100/portTICK_RATE_MS);
  }
}

Push Buttons
If one of the push buttons gets pressed, this is reported on the console:
#if PL_HAS_KEYS
void APP_OnKeyPressed(uint8_t keys) {
  if (keys&1) {
    CLS1_SendStr((uint8_t*)"SW3 pressed!\r\n", CLS1_GetStdio()->stdOut);
  } else if (keys&2) {
    CLS1_SendStr((uint8_t*)"SW2 pressed!\r\n", CLS1_GetStdio()->stdOut);
  }
}

void APP_OnKeyReleased(uint8_t keys) {
  if (keys&1) {
    CLS1_SendStr((uint8_t*)"SW3 released!\r\n", CLS1_GetStdio()->stdOut);
  } else if (keys&2) {
    CLS1_SendStr((uint8_t*)"SW2 released!\r\n", CLS1_GetStdio()->stdOut);
  }
}

void APP_OnKeyReleasedLong(uint8_t keys) {
  if (keys&1) {
    CLS1_SendStr((uint8_t*)"SW3 long released!\r\n", CLS1_GetStdio()->stdOut);
  } else if (keys&2) {
    CLS1_SendStr((uint8_t*)"SW2 long released!\r\n", CLS1_GetStdio()->stdOut);
  }
}
#endif /* PL_HAS_KEYS */

SD Card with FatFS
One thing I lost a lot of time: Somehow I was not able t get the SD card up and running with the K64F120M SDHC interface (see this post). After many hours of debugging, I decided to do it with normal SPI, and voilà: this worked! I still do not know the cause of this, as this works for me for other boards. This might be even a silicon issue as the K64F120 is very new? So for now I have the SDHC support disabled in my application and use the SPI.
Summary
Finally I have a Freescale ARM Cortex M4F with enough leg room for my most complex applications. And with this demo application I have now have a board support package running for most parts. The potentiometer is missing (but would not be a big deal). As a larger piece the USB stack is missing, but there has to be another week-end reserved for this ;-). What is strange that the OpenSDA on the board seems not to work properly, and that the demo application on the board is not working out of the box as advertised in the Quickstart Guide? It looks like it has a wrong firmware on the board? At least I’m able to debug it over the JTAG debug port, yet another reason to have an independent JTAG programmer :-).
Happy RAMing 🙂

		
	
			

			
			
Share this:
Print
Email
Twitter
Facebook
LinkedIn
Tumblr
Pinterest
Pocket
WhatsApp
Telegram
Like Loading...


	
Related