Thanks.
I'm trying to understand the way it works including docker. There seems
to be some comment on the internet that docker gets in the way, only
supports one process, (so anything spawning a process isn't going to
work ?) - so I started down that route as it seems to be the easiest
way - but I really don't want to have to know anything about docker so
maybe I need to install it native. Docker also seems to have made the
machine soggy.
I have the jtag/multitech working through KinetisDesignStudio3.1
(eclipse mars I think) for another board. Maybe I will try the FRDM-K64
-Which has a label SCH-28163 Rev D1 over KDS3.1, and then possibly
create a project under KDS3.1 for
Oh yes blinky v slinky - thanks for the pointers.
But have a good weeked, not urgent :)
Cheers
Neil Hancock
On 1/27/2017 3:42 PM, marko kiiskila wrote:
Hi,
On Jan 27, 2017, at 1:39 PM, Neilh <neil...@biomonitors.com
<mailto:neil...@biomonitors.com>> wrote:
Hello Marko
Thanks for the suggestion. I was surprised as well, which is why I
thought I'd send it out.
Still doesn't work with the hardcoded address via newt:
[~/dkr/myproj]$ newt load boot_kinetis
Loading bootloader
Error: Downloading
/workspace/bin/targets/boot_kinetis/app/apps/boot/boot.elf.bin to 0x0
/workspace/repos/apache-mynewt-core/hw/bsp/frdm-k64f/frdm-k64_download.sh:
41:
/workspace/repos/apache-mynewt-core/hw/bsp/frdm-k64f/frdm-k64_download.sh:
/usr/local/bin/pyocd-flashtool: not found
I have not used docker, but I hear it’s a similar concept to Solaris
Zones, FreeBSD prisons.
So what I’m guessing is going on is that the pyocd-flashtool/pyocd
binaries are
not inside the docker container. I assume docker does chroot() to
somewhere.
Meaning; it’s possible that it has a different set of binaries than
your host machine.
Try adding ‘set -x’ at the top of the download script, and issue ‘ls
/usr/local/bin’ from
there as well. Then, if you execute newt -lDEBUG load <target>’ you
should see
all that output. This should show what the docker container has inside
it’s /usr/local/bin.
So if you can open up a shell inside docker somehow, you might be able
to install
that pyocd JTAG software yourself.
I so far have only used native setups. Therefore I’m a bit hazy on the
docker details.
I was going add openocd option to Kinetis, as I’m used to that as my
jtag server.
I have not actually used this BSP myself. I just helped the folks who
did the
work to support the MCU. Nor have I used pyocd ever before.
I do have one or 2 of these at the office (I’m WFH today), so I can
get to this
on Monday. I have been meaning to try this out anyway, so this is a
good trigger :)
When I use the direct command, with multilink JTAG/USB plugged into
FRDM-K64 with J11/cut, - it can't find the board, or is it the JTAG
device
[~/dkr/myproj]$ /usr/local/bin/pyocd-flashtool -se --address 0
bin/targets/boot_kinetis/app/apps/boot/boot.elf.bin
No connected boards
Error: There is no board connected.
Hmmm. I want to make sure that you’re using correct USB port.
Although, if you’ve
already programmed it Kinetis IDE, then you should be using the right
stuff.
Which version of their board do you have?
http://www.nxp.com/products/software-and-tools/hardware-development-tools/freedom-development-boards/freedom-development-platform-for-kinetis-k64-k63-and-k24-mcus:FRDM-K64F?tab=Design_Tools_Tab
that lists 4 different schematics for this.
So I'm hunting around for JTAG line command interface hints, usually
I use this through KinetisDesignStudio3 -so cmd line jtag is unfamiliar
so my objective is to get blinky running so I now I have control.
Is there a way to drop the .bins on the FRDM-K64 USB/SDA - usually
through the USB/SDA it only programs a single .bin - so is there a
method to programming the boot first and then the Blinky
You should be able to create a file with the whole flash contents on
it. Check out the
‘manufacturing image’ stuff with newt. But I think we should get the
download/debug
scripts to work without. Otherwise debugging things will be very painful.
Also, I can't figure out with the boot as to whether it will be
detectable on a UART. Where do I see what UART is set to the console.?
Looks like this BSP has them defined in it’s syscfg.yml file. I
figured this out
by looking at the hal uart driver for this MCU.
So check hw/bsp/frdm-k64f/syscfg.yml
Blinky does not open console, BTW. It’s just blinking LEDs. To get
console/shell,
you should use slinky (these app names are quite something).
thanks
Neil Hancock
On 1/26/2017 8:56 PM, marko kiiskila wrote:
Try running pyocd-flashtool manually with the arguments newt would
pass to it.
If that works, then at least you have the jtag communications
working ok. Or just
try changing the download script to use absolute path.
Obviously the shell running trying to execute pyocd-flashtool does
not have
the /usr/local/bin in it’s path. I’m not sure where it picks it’s
environment
variables from. I’m a bit surprised that /usr/local/bin is not in
the path,
as that’s where I’d expect openocd to be at (i.e. for other boards).
On Jan 26, 2017, at 6:19 PM, Neilh <neil...@biomonitors.com
<mailto:neil...@biomonitors.com>> wrote:
Thanks for the tips.
I had followed the docker install and then olimex instructions and
subsituted _kinetis
So I have the FRDM-K64F connected with a multlink JTAG/USB/Ubuntu,
and the J11 cut for SWD operation
I also found i needed to add
sudo -Hpip install --pre -U pyocd
which added
/usr/local/bin/pyocd-flashtool
/usr/local/bin/pyocd-gdbserver
/usr/local/bin/pyocd-tool
/usr/local/lib/python2.7/dist-packages/pyOCD
[~/dkr/myproj]$ newt load boot_kinetis
Loading bootloader
Error: Downloading
/workspace/bin/targets/boot_kinetis/app/apps/boot/boot.elf.bin to 0x0
/workspace/repos/apache-mynewt-core/hw/bsp/frdm-k64f/frdm-k64_download.sh:
41:
/workspace/repos/apache-mynewt-core/hw/bsp/frdm-k64f/frdm-k64_download.sh:pyocd-flashtool:
not found
But I have pyocd-flashtool
[~/dkr/myproj]$ whereis pyocd-flashtool
pyocd-flashtool: /usr/local/bin/pyocd-flashtool
Any suggestions? is this a docker issue?
thanks
Neil Hancock
On 1/26/2017 9:32 AM, Christopher Collins wrote:
Sorry, there's something else I forgot to mention. You'll need to put
the boot loader on your board as well. You can do this before or
after
uploading blinky.
newt target create boot-frdm-k64f &&
newt target set boot-frdm-k64f
app=@apache-mynewt-core/apps/boot \
bsp=@apache-mynewt-core/hw/bsp/frdm-k64f
\
build_profile=optimized
Then build and upload the boot loader to your board:
newt build boot-frdm-k64f
newt load boot-frdm-k64f
Chris
On Thu, Jan 26, 2017 at 09:14:02AM -0800, Christopher Collins wrote:
To start with, I would create a blinky-frdm-k64f target:
newt target copy my_blinky_sim blinky-frdm-k64f
Then configure your new target to use the frdm-k64f BSP:
newt target set blinky-frdm-k64f
bsp=@apache-mynewt-core/hw/bsp/frdm-k64f
Plug your board in and attach a debugger if necessary, and try
running
blinky on your board:
newt run blinky-frdm-k64f
If everything works, a gdb window will come up. Type c <enter>, and
check if your board's LED is blinking.
After you have blinky working on your board, you might want to
try one
of these other sample apps:
slinky: Includes shell over UART and newtmgr over shell.
bleprph: Includes BLE stack and newtmgr over BLE.
Thanks,
Chris
Alternatively, I could familiarize myself work through the
Olimex-E407
My environment so far has been IDE Freescale Kinetis Design
Studio/Eclipse building nuttx OS, and with integration to
Multilink JTAG
for blowing the flash.
There was a new feature request for an Eclipse plugin for
myNewt, but it was marked as dup, and I haven't seen any other
mention of Eclipse IDE so
far.
Any recommendation on getting started with FRDM-K64F? or should I
start with Olimex
thanks
--
Neil Hancock
