KDS / Eclipse newbie could use some help getting started

[k64konfused]

Hi Mark, I'm trying my best to get running with KDS and uTasker on my FRDM-K64F, but so far I am completely failing.

First of all, I am relying on two documents to get started: 1) the readme file and 2) the uTasker v1.4 User Guide - First Steps PDF.

Steps 1-3 in the readme are obviously very basic and I have all of the software downloaded and installed.
Step 4 I couldn't do because the software demo seems to be for the "tower board", which I do not have.
Once I got to step 5, I consulted the User Guide, but found the one specific to v1.4.

Here's where I got hung up.  After I made a copy of Applications/uTaskerV1.4 and configured the simulator in Visual Studio, the next step was to add a new task to my project.

Specific questions at this point:

• when you say "add a new source file to the project", by "project" are you talking about the renamed project I created in the Applications folder, or are you saying that it should be in the root extracted uTasker folder?  I've done it both ways -- when I look at the Project Explorer in KDS, should I have the Application, Hardware, stack, and uTasker folders, or should I just see Includes?  Please see the following image:
  
• If I put main.cpp into Applications/uTaskerDemo and then build, I just get a "Nothing to build for project uTasker" message
• If I put main.cpp into the other project that just shows Includes, then I get the error "fatal error: config.h: No such file or directory"

If you could help me fill in the details that I'm missing, I'd really appreciate it so I can start trying out uTasker.  I apologize for these questions if the answers seem obvious.  I'm just having a little trouble piecing the bits together.  Thank you!

[mark]

Hi

I wouldn't try making a new project yet since you can simply use the uTaskerV1.4 project as it is.
Therefore follow http://www.utasker.com/docs/KINETIS/uTaskerV1.4_Kinetis.pdf and not http://www.utasker.com/docs/uTasker/uTaskerV1.4_user_guide.PDF.

Specifically, to work with KDS on the FRDM-K64F, starting with Release 1.4.7 do the following:

1. Delete all CW project files from the project root directory and copy the KDS project files from \Applications\uTaskerV1.4\KinetisDesignStudio\Project_Settings to the project root. The project root is the highest directory - the level where the folders \Applications, \uTasker etc. are located. This is also explained in the readme.txt file in the project root directory (V1.4.7 has CW set rather than KDS and they both need their project files at the same location - it is a bit of nuisance with Eclipe projects which want to have their files here but are otherwise not compatible with each other - same goes for Atollic)
2. Start KDS in a workspace of your choice - then import the project (see the CW video since KDS works the same)
3. Check that the compiler setting is for Cortex M4 (and not Cortex M0+) and select the linker script file \Applications\uTaskerV1.4\KinetisCodeWarrior\Linker_Files\K_1M_256.ld to match your chip  (don't worry that this is a linker script in the CW directory since this can be shared for all GCC based builds). Again, this is shown in the CW video and is almost identical in KDS.
4. Select the uTaskerV1.4 target for Flash  (rather than the serial loader, or others)
5. In \Applications\uTaskerV1.4\config.h comment in KINETIS_K60 to choose the family (comment out whatever is active if it doesn't match - I think that the default in that release is KINETIS_KE00). Then comment in the board FRDM_K64F, rather than TWR_K64F120M (in case it is selected) to select the exact HW.
6. Build and load to the board and you should have the project running. You can enable or disable USB, UART, SD card, ETHERNET and various TCP/IP services in the same file to configure what you want and don't (note that Ethernet is disabled by default in that release so you will probably want to enable ETH_INTERFACE). More detailed configurations are in \Applications\uTaskerV1.4\app_hw_kinetis.h (eg. choosing which UART the debug interface is on, whether SD card works with SDHC or SPI etc.).

Good luck

Regards

Mark

[k64konfused]

Thank you Mark, I certainly appreciate your prompt reply and will try out your suggestions ASAP!

[k64konfused]

Mark, I got a little delayed in trying your suggestions, but I followed them a moment ago.  Everything compiles fine, but I can't seem to run the program on the target to test things out.  I'm not sure how to proceed, given the following messages in my console.



FYI, I am currently using the mbed bootloader.  Do I need to load the Segger J-Link OpenSDA firmware instead?

[mark]

Hi

KDS can't work with the mbed boot loader.

- If you want to load the binary file (withoutz debugging) you can drag and drop it on the mbed boot loader when it appears as a USB hard drive.

- If you want to use KDS to load and debug you need to load the P&E debugger to the board. You can get details in this thread: https://community.freescale.com/thread/323324 and also a link to the code to be loaded.

Regards

Mark

[k64konfused]

Thanks, Mark!  While there is still a gap in my knowledge regarding KDS, Eclipse, and various settings, it does look like the P&E bootloader did the trick.  Once I realized that I had to specify the .elf file (I'm used to Visual Studio which does everything for me), I was able to debug the application.  RGB LED is blinking green and I can ping the board at the specified IP address, so perhaps now I can shift back to trying out the simulator, as well as getting other peripherals to work in uTasker.

[mark]

Hi

That sounds good.

Now that you basically have the complete infrastructure operating you can use the simulator to help you configure what you need and test that it is configured correctly, as well as doing some additional programming and debugging. Then you should be able to build the same with KDS, load to the board and verify the same behaviour.

When you find that you are not needing KDS to do actual debug work it is practical to reload the MBED boot loader to simply copy the .bin to the board.
Alternatively you can load the uTasker serial loader to the board (it has several modes such as Ethernet Web Server or USB loading) and then load using it. It also supports the Freescale KBOOT USB-HID loader.

Regards

Mark

[k64konfused]

Thanks, Mark.  I just want to make sure I'm understanding things properly here, so here's an example.

I need to implement a Wiznet library over SPI so that I can add a 2nd NIC to the FRDM-K64F.  Ideally, I'd simulate this first, but there isn't a way to send SPI commands to an external board.  Therefore, I should simply write an interface for the library, then derive a simulation layer from this interface that the VS simulator project will call into.  Once I prove that I can send simulated data back and forth, then I would implement the hardware layer and run through KDS.

While it's not possible to send SPI data, is the SPI interface something that is possible to emulate?  In other words, I just need to confirm that I can make the uTasker SPI library call, and then have a simulated layer send back pre-packaged data.  I think this is basically what you do for UARTs?

[mark]

Hi

Take a look at the SPI Flash interface (in spi_flash_kinetis_sst25.h, spi_flash_kinetis_stmicro.h and spi_flash_kinetis_atmel.h). It allows the SPI Flash operation to be simulated but basically assumes that the SPI code works and passes the individual bytes to the interface in WinSim.c.
It doesn't make much sense to emulate the SPI interface itself since it is really only passing bytes of data back and forth.

In your case I would make use of the fact that the TCP/IP stack supports multiple networks and multiple network interfaces, especially if the Wiznet that you are using doesn't contain TCP/IP. I woudl interface the SPI Rx/Tx interface to the same NIC as the Ethernet one is connected to since the two can have different IP and MAC addresses so you could then ensure that the two networks are operating correctly over the single NIC.

Regards

Mark

[mark]

Another technique is to use the final HW to interface with the SPI device but rather than have the complete application on the board just send each received packet (received via SPI) in a UDP frame to the simulator. The simulator runs the complete application with a UDP socket in place of the SPI interface so the real HW is an extension to it. Rather than sending generated frames to teh SPI they are sent in a UDP frame to the board, which passes it on to the SPI based device. Once application development is complete, remove the UDP socket and connect to the SPI HW instead.

Regards

Mark

[k64konfused]

Thank you for the suggestions, Mark.  I have to confess that I might need to read them a couple of times before I really understand.  I'll post up whatever questions I come up with later on tonight. 

[k64konfused]

Hi Mark, I had to shift my attention to other things, but I'm back to learning how to use uTasker.  I'd like to get going with creating a socket and making a remote server connection.  However, the first thing I need to do is to be able to create my own task function where inside I do all of the socket calls.

I'm reading through the uTasker User Guide -- First Steps document, and it says to add the task identifier to ctNodes[].  The problem I see is that I'm running in the simulator under Windows, and in this case, all of the tasks are disabled because they are inside of a #if defined OPSYS_CONFIG block.  But surely there are tasks running somewhere, since the demo app is responding to ping.

Can you point me in the right direction?  Perhaps there's another document I should be reading?  Or is my demo project somehow misconfigured?

Thank you!

[k64konfused]

I should not rely on grayed out sections in the IDE. 

I added the code and it works, fnMyFirstTask executes.  Awesome!  Moving on...

[mark]

Hi

Yes, be wary about greyed out code since all IDEs make mistakes on displaying these correctly (neither Eclipse and nore VisualStudio get it correct in all cases).
The best test is to type in a typo in the area you want to be sure of. If it builds without errors the area is NOT used. If there is a syntax error it means that the area IS used (irrespective of what the IDE may display).

Regards

Mark

[k64konfused]

In your case I would make use of the fact that the TCP/IP stack supports multiple networks and multiple network interfaces, especially if the Wiznet that you are using doesn't contain TCP/IP.

Mark, I have a rough proof-of-concept that shows uTasker will support the number of remote connections that I need.  Now I'm coming back to your suggestions regarding simulation of SPI data coming in from a Wiznet chip.

Are you saying that I could add another PHY to the board at some point, and uTasker will be able to bind it to a different IP address / subnet?  It seems like that would have advantages over using the Wiznet chip, which has the TCP/IP stack in silicon, but would require me to write more application code.  If I could add another physical interface and leverage your library, that would be pretty awesome.

*However*, when I looked at the K64F datasheet, it looked like it only supports one ethernet interface.  I'm not experienced in this area, but since I only see RMII0 (and not an RMII1), I assume that the only way to do what you're saying is to add another ethernet interface.  If so, can you recommend a compatible chip that you have used to show that a second interface will work?

Thanks, and sorry if this is a dumb ethernet question.