Re: interrupt latency in mynewt

[will sanfilippo]

Jiacheng:

How are you measuring the latency? I presume you have a scope on a GPIO input 
and maybe set a GPIO high when you are inside the ISR and measure the time 
between them? Or are you measuring the timing using a task? There is certainly 
some hard limitation on interrupt response time but I am not sure what that is 
for the nrf52 specifically. If you tell me exactly how you are measuring the 
timing, what tasks you have running and their respective priorities, I might be 
able to hazard a guess as to why there are differences. I would also like to 
know what interrupts are enabled and their priorities.


> On Jan 27, 2017, at 6:38 PM, WangJiacheng  wrote:
> 
> Hi,
> 
> I have an interrupt triggered  by GPIO input, and observed different 
> interrupt latency from different CPU state. If all the tasks are sleep, the 
> interrupt latency is about 20us-30us, if the CPU is in idle mode with simple 
> calling “__WFI()”, the interrupt latency is about 10us-15us, and if the CPU 
> is running, the interrupt latency can be within 8us.
> 
> I do the test as following, create a low priority task with 3 case:
> 
> 1), the task loop is like
> while (1){
>   /* keep the task in sleep mode, the interrupt will be 20us-30us */
>os_time_delay(OS_TICKS_PER_SEC);
> }
> 
> 2). the task loop is like
> while (1){
>   /* put the CPU in idle mode by simple calling WFI, the interrupt will be 
> 10us-150us */
>__WFI;
> }
> 
> 3). the task loop is like
> while (1){
>   /* keep the CPU always running, the interrupt will be within 8us */
>   os_cputime_delay_usecs(100);
> }
> 
> Any idea to reduce the interrupt latency from all tasks are in sleep mode? or 
> there is a hard limitation of interrupt response time?
> 
> Thanks,
> 
> Jiacheng

Re: newNewt

[Neilh]

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 > 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 ’ 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