Porting Kinetis MK64F

[dhylands]

I wrote a significant portion of the makefile stuff, so if you have any questions feel free to ask.

I don't consider it particularly complicated as far as makefiles are concerned. It seems pretty typical of multiplatform Makefiles I've worked on over the years (for anything non-trivial).

[dhylands]

I would be inclined to drop the memzip stuff.

I wrote memzip stuff long before frozen module support was added, and I would be inclined to just drop memzip and use frozen modules instead.

I also highly recommend that you use a branch based workflow. So I'd drop your pull request, and since you've only got one commit, you can fix things up with a few git commands. Something along the lines of:

Code: Select all

git checkout master
git checkout -b fshal-work
git checkout master
git reset HEAD~
git push origin fshal-work

The git checkout -b fshal-work will create an fshal-work branch, and it will include your fshal commit.
The reset command will throw away the latest commit on master. So now your master is back in sync with the micropython master branch.

Now when you goto github, it will detect you created a new branch and will have a simple button push to create a pull request.

Then when people make comments on your PR and you decide to make changes, you can use commit --amend and push -f to update the branch (and the PR) without having to create a new PR.

And since micropython master will almost certainly advance before your PR is accepted/merged its now much easier to keep your branch up to date. Just pull down the latest master from github and rebase your work branch.

Here's some github documentation on how this all works: https://guides.github.com/introduction/flow/

[dhylands]

I grabbed your branch and I thought I'd let you know that it builds fine. Once my board shows up (probably tomorrow) I'll see if I can flash it.

[neilh20]

Thanks for the tip, I have used branched development in a previous large project in 2002 it was before git. git is amazing for distributed sharing. Here is what it said

Code: Select all

git checkout master
git checkout -b fshal-work
	[i](switched to a new branch ‘fshal-work’)[/i]
git checkout master
	[i](switched to a branch ‘master’)[/i]
git reset HEAD~
git push origin fshal-work
	[i](* [new branch] fshal-work fshal-work)[/i]

I haven't tried running it yet, I'm expecting the interrupt vectors will need updating. I would also like to put in a hard-fault handler to at least make it go to a known place.
Do you have a JTAG emulator?. The FRDM-K64 comes with a populated JTAG It looks like the .elf should be loadable, but then don't know if that tells it where the sources are. My setup that has worked with KDS3 and FRDM-K64F

IMG_20150925_073732 (Small).jpg (71.39 KiB) Viewed 7444 times

The USB/SDA also has a built in JTAG interface with gdbDebugger capable of driving it - but I've only tried in in KDS3
My working environment is building/git micropython on Ubuntu [edit]14.04[/edit[ - and editors/emulator tools on win8.1
so I need to do native on Ubuntu - do you have any recommendations.?
Possibly http://mcuoneclipse.com/2015/09/04/new- ... launchbar/

[dhylands]

I don't have a JTAG, so I've typically relied on printf debugging (and thinking through the problem) to figure things out.

I've been using Visual Slick Edit as my editor for the last 20 years (unfortunately you need to buy it). Some poeple really like sublime text (free to try and only $70 to buy). gedit is free and does syntax coloring. I've also been known to use vi/vim/gvim, but I wouldn't necessarily wish that on anyone

It looks like your respository now has he fshal-work branch, but the master branch still has the extra commit. So I think I missed a couple commands. You should also do:

Code: Select all

 git checkout master
 git push -f origin master

and that will force your github repository to match up with what you have locally.

[neilh20]

Done. Online github shows neilh10/micropython/fshlhal directory has disappeared - presumably as its captured in the branch.
Ubuntu$ says

Code: Select all

git checkout master
	[already on master)]
git push -f origin master
	[master --< master (forced update)]
git remote –v
	[origin	https://github.com/neilh10/micropython.git (fetch)
	origin	https://github.com/neilh10/micropython.git (push)
	upstream	https://github.com/micropython/micropython.git (fetch)
	upstream	https://github.com/micropython/micropython.git (push)]

On github how do you see the branch ~ I can't find it online - probably can do it through $git in someway - and I have the branch backed up.
On ubunto do I need to do anything to switch to fshal-work.?

The FRDM-K64 is managed through the USB/SDA/JTAG <--> Open_SDA MK20D & has full symbolic debug/single step capability through gdbDebug(?) which I think is what is being referenced in the Launchbar plugin for Eclipse-CDT (Mars) - this shows the "<prj>_Debug_PNE" & "<prj>_Debug_OpenOCD" http://mcuoneclipse.com/2015/09/04/new- ... launchbar/
I use embeded-printf for runtime and stability testing - however the ARM architecture does a hardfault exception (nasty) when accessing an undefined space, or disabled peripheral.
The build-frdmk64f/micropython.elf might run straight off - but my instinct is to step through the hw/startup initialization.
I have to do something else for a couple of hours and then will try and work through the code start-up and then set up the tools.

[dhylands]

If you goto here: https://github.com/neilh10/micropython there is a branch dropdown which allows you to select which branch you're viewing on github.

If you select fshal-work then it will take you to this URL: https://github.com/neilh10/micropython/tree/fshal-work

On your local machine use:

Code: Select all

git checkout fshal-work

to switch to that branch.

I like to use git-prompt so that my current git branch shows up in my prompt. This is what my prompt looks like:

Code: Select all

dhylands@dave-w520 ~/micropython/micropython  (master)
2497 >

I'm currently using ubuntu 14.04 LTS on all my machines., and its been a while since I had 12.04 so I don't recall exactly how to install it. Some links that might be useful:
http://code-worrier.com/blog/git-branch-in-bash-prompt/
https://github.com/git/git/blob/master/ ... -prompt.sh
http://mediadoneright.com/content/ultim ... ash-prompt

[neilh20]

Thanks - got it. Oops also I am using mostly Ubuntu 14.04 - I have one web server that won't upgrade.

Some links that might be useful:
http://code-worrier.com/blog/git-branch-in-bash-prompt/
https://github.com/git/git/blob/master/ ... -prompt.sh
http://mediadoneright.com/content/ultim ... ash-prompt

Excellent thankyou.
Well I got some tools going - and now back looking at the linker.
There was something interesting in the supplied linker
m_flash_config (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
and it turns out this is a special flash configuration field. So it has to be written with care.
I had some new processors recently that were bricked through some sort of security write - not sure but they wouldn't let in the JTAG.
So I need to split the FLASH field up

[neilh20]

Thanks - got it. Oops also I am using mostly Ubuntu 14.04 .

Some links that might be useful:
http://code-worrier.com/blog/git-branch-in-bash-prompt/
https://github.com/git/git/blob/master/ ... -prompt.sh
http://mediadoneright.com/content/ultim ... ash-prompt

Excellent thankyou.
Well I got some tools going - and now back looking at the linker and code.
There was something interesting in the supplied MK64 linker
m_flash_config (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
and it turns out this is a special flash configuration field. So it has to be written with care.
I had some new processors recently that were bricked through some sort of security write - not sure but they wouldn't let in the JTAG.
So I need to split the FLASH field up [edit] turns out this field is catered for in the mk20dx128.c - so I have loaded up the binary through the KDS3/debug multilink emulator - but then hits a SIGTRAP. KDS3 also conveys the git status of the project so thats pretty cool [/edit]

[neilh20]

Hi Dave,
I was wondering if it would work to drop the alternative USE_ARDUINO_TOOLCHAIN environment in the make file.? You mentioned two versions to begin with - and I wasn't paying attention so is this what you were refering to.
I think the structure of the fslhal make seems to build both kinetis processors (and I want to extend it to a 3rd later) - any comments welcome.
I'm happy to drop/change the memzip, I don't have any opinion about it (other than impressed in the way its done) - as its more application above the boot/machine - I'd prefer to leave it to later as I don't want to change too much.