from:"marko kiiskila"

Re: srodata section alignment issue in hw/bsp/hifive1/hilive1.ld file

2022-08-24 Thread Marko Kiiskila

There was no attached file, I assume that would’ve had
the error you are seeing.

Regardless, what you have there is a reasonable way
to get .data padded to 8 byte alignment. Linker script is
the right place to make that happen.

> On 24. Aug 2022, at 18.08, 范姜徐霖  wrote:
> 
> I try to port ble_app program to my board from bsp/hifive1.
> I found something wrong at srodata alignment. (see attached file)
> the .data section size is 0x94, and the following .srodata section is 
> alignment at 2**3
> so .sordata section start at 0x98. 4-bytes are skipped. 
> we do not always have this error, it depends. 
> I guess it happen at ".data section size is not 8-byte alignment"
> 
> I modify the hifive1.ld to make sure .data section size is 8-byte alignment.
> --
>   .data  :
>   {
> *(.data .data.*)
> *(.gnu.linkonce.d.*)
> . = ALIGN(8);     } >dtcm AT>itcm 
> --
>  
> dont know is there anything missing?
> 
> Jack 
>

Re: Cortex-M hardware stack limit checking

2019-11-27 Thread Marko Kiiskila

Option 3 sounds best to me as well. > On 26 Nov 2019, at 18.36, Łukasz Rymanowski > wrote: > > option 3 looks good to me: +1 > > Best > Łukasz > > On Mon, 25 Nov 2019 at 21:11, Jerzy Kasenberg > wrote: >> >> HI, >> >> I vote for option 3 >> >> My reason, apart what Andrzej mentioned (usefulness and debugging), >> is that there is a notorious coverity warning popping up about usage of >> address _tasktop[stack_size]. >> >> best regards >> Jerzy >> >> pon., 25 lis 2019 o 16:28 Andrzej Kaczmarek >> napisał(a): >> >>> Hi, >>> >>> I recently created a PR which adds support for hardware stack limit >>> checking on Cortex-M33. It was already approved by few people but >>> apparently there are different opinions of how this should be implemented >>> so I would like to get more opinions on this since we likely will have more >>> MCUs with this feature soon, so consider this as a voting. >>> >>> PR: https://github.com/apache/mynewt-core/pull/2108 >>> >>> Here are proposed ways to do this: >>> 1. use stack top and stack size to calculate PSPLIM on every context switch >>> this does not require any modification in os_task structure and adds 4 >>> instructions on each context switch >>> 2. add stack bottom to os_task >>> this extends os_task struct by 4 bytes and adds 2 instructions on each >>> context switch >>> 3. change stack top to stack bottom in os_task >>> this does not change the size of os_task struct and adds 2 instructions on >>> each context switch, however it may break code which accesses os_task >>> structure directly (like mcumgr does - it should be modified to use proper >>> API anyway) >>> >>> My personal preference is option 3 since it is more useful to have stack >>> bottom in os_task struct instead of stack top. For example, stack overflow >>> or usage is determined using stack bottom. Also when debugging it's easier >>> to inspect stack by using stack bottom rather than stack top. In general, >>> seems like you only need stack top when initializing it but this is done >>> only once (even os_task_init has 'stack_bottom' parameter, not >>> 'stack_top'). >>> >>> Best, >>> Andrzej >>>

Re: Thoughts on deprecating LOG_VERSION 2 and making the default LOG_VERSION 3

2019-11-08 Thread marko kiiskila

> On 7 Nov 2019, at 16.50, Christopher Collins wrote: > > On Thu, Nov 07, 2019 at 11:56:36AM -0800, Vipul Rahane wrote: >> Hello, >> >> LOG_VERSION 2 has been around for quite some time but is mostly just a >> string based log. LOG_VERSION 3 supports string based logs as well as >> others. LOG_VERSION 2 does not play well with the MCUmgr mobile library as >> well. >> >> I would like to suggest getting rid of LOG_VERSION 2 which would allow us >> to make the code a bit simpler and not worrying about backwards >> compatibility. >> >> This discussion was mainly triggered by a PR >> https://github.com/apache/mynewt-core/pull/2087 by Jerzy for adding back >> string based reboot log just to make it work with LOG_VERSION 2. >> >> LOG_VERSION 2 also doesn't play well with the MCUmgr mobile library. >> >> I suggest we deprecate LOG_VERSION 2 and make the default 3 going forward. > > I agree. Version 3 has been around for quite a while (two years?) and > it is superior to version 2. I am fine with dropping support for > version 2. > I’d ok with that one as well.

Re: Removed SUCCESS and FAIL #define statements in LoRa Node's utilities.h

2019-10-17 Thread marko kiiskila

Hi Frank, It’s all good. Thanks for the PR. > On 16 Oct 2019, at 23.08, Frank wrote: > > Hi all, > > following Marko's advice, I just created a PR > > https://github.com/apache/mynewt-core/pull/2047 > > to remove the SUCCESS and FAIL #define statements in > net/lora/node/include/node/utilities.h. They are not used within the > (Semtech) net/lora code, however, they conflict with the CMSIS ErrorStatus > enum type definitions of several STM32 MCUs. > > Example: > > Error: In file included from > repos/apache-mynewt-core/net/lora/node/include/node/mac/LoRaMac.h:52:0, > from > repos/apache-mynewt-core/net/lora/node/src/mac/region/Region.c:31: > repos/apache-mynewt-core/net/lora/node/include/node/utilities.h:35:53: error: > expected identifier before numeric constant > #define SUCCESS 1 > ^ > repos/apache-mynewt-core/hw/mcu/stm/stm32f0xx/src/ext/Drivers/CMSIS/Device/ST/STM32F0xx/Include/stm32f0xx.h:191:3: > note: in expansion of macro 'SUCCESS' > SUCCESS = !ERROR > ^~~ > > However, I am not sure, whether this is the way to do it. > > Best, > Frank

Re: Earlier check whether to include LORA_NODE_CLI in lora_cli.c

2019-10-16 Thread marko kiiskila

Thanks for noticing. Opened this PR for it: https://github.com/apache/mynewt-core/pull/2044 We do recommend creating PRs for the fixes; those are easier to bring in. https://cwiki.apache.org/confluence/display/MYNEWT/Submitting+Pull+Requests > On 15 Oct 2019, at 23.30, myn...@hackdaworld.org wrote: > > Hi all, > > if you want to build a lora node firmware > > pkg.deps: >- "@apache-mynewt-core/net/lora/node" > > without LORA_NODE_CLI support > > syscfg.vals: >LORA_NODE_CLI: 0 >LORA_NODE_LOG_CLI: 0 > > and (thus) without shell and parse dependency added to your project, you will > get an error like: > > Compiling repos/apache-mynewt-core/net/lora/node/src/lora_cli.c > Error: repos/apache-mynewt-core/net/lora/node/src/lora_cli.c:23:10: fatal > error: shell/shell.h: No such file or directory > #include "shell/shell.h" > ^~~ > compilation terminated. > > The attached patch fixes this issue by checking for LORA_NODE_CLI support > earlier. > > Hope I didn't get anything wrong. > > Best, > Frank >

Re: Unifying Newtmgr (NMP) protocol and MCUmgr (SMP) into the MCUmgr repo

2019-10-10 Thread marko kiiskila

Sorry for being difficult here, but.. To be exact nmgr_uart came after newtmgr-over-shell. The reason it came to be was smaller memory footprint platforms, and assumption was that folks might still want option to newtmgr-over-uart after their dev was done. It got picked up for serial bootloader initially as it was small in size, and easy to integrate. I’m going to vote -1 for removing it. I believe the use cases justifying it’s initial existence are still valid. > On 10 Oct 2019, at 0.18, Vipul Rahane wrote: > > Thanks Will and Chris for your response, removing it and transitioning it > to smp_shell. This will be part of the MCUmgr changes to mynewt-core. > > > > On Wed, Oct 9, 2019 at 1:45 PM will sanfilippo wrote: > >> +1 on my part but not sure I am in the best position to vote :-) >> >>> On Oct 9, 2019, at 12:42 PM, Vipul Rahane wrote: >>> >>> Hello, >>> >>> While making the changes for MCUmgr, we came across nmgr_uart which is a >>> predecessor of nmgr_shell. So far, from what I gather, the functionality >> is >>> the same except for the fact that shell can bring in other code which can >>> increase the code size a bit. >>> >>> As a solution I was suggesting removing nmgr_uart and transitioning to >>> smp_shell as part of the MCUmgr changes. >>> >>> What does the community think about it and does anybody have issues with >> it. >>> >>> This question was raised as the CI did not catch errors with smp_uart and >>> nothing really uses it in the mynewt ecosystem. I am looking for .a quick >>> turn around on this question, so, any input would be fine. Thanks. >>> >>> Regards, >>> Vipul Rahane >>> >>> On Fri, Sep 27, 2019 at 11:38 AM Vipul Rahane wrote: >>> Hello fellow developers :-) So, Miguel and I have been working on unifying Newtmgr into the MCUmgr repo (https://github.com/apache/mynewt-mcumgr). There are no protocol level changes, since MCUmgr(SMP) and Newtmgr(NMP) were the same and so, everything should work off the bat for everybody. The PRs related to this change are: 1. https://github.com/apache/mynewt-core/pull/1917 2. https://github.com/apache/mynewt-mcumgr/pull/27 3. https://github.com/apache/mynewt-nimble/pull/577 We have also added a transient package for backwards compatibility. So, this should be a fairly smooth transition for everybody. Details about the change: - Replace newtmgr with SMP and MCUmgr - The change addresses issue #1871 - Make stats, logs and img_mgmt work with MCUmgr - Make default group commands work with MCUmgr - Add transient packages for backwards compatibility - Update apps to have the updated dependencies - Add syscfgs for MGMT commands Eg: CONFIG_MGMT, STATS_MGMT, LOG_MGMT, etc - Make OICMGR use OMP from MCUmgr - Transition from Newtmgr -> SMP - Remove cborattr and update cborattr in MCUmgr - Fix builds for log version 2 - We are also removing support for log_fcb_slot1 since it is not really used by the community or any modules in the core repo. - Updating mynewt port of MCUmgr - Adding Stats, Logs, datetime and other default commands support to MCUmgr - Changing mgmt_group_register() in MCUmgr so that it allows re-registration of command groups - Fix dependency and build issues in MCUmgr for mynewt port and apps - Adding support for log version 3 and image hash changes - Adding support for image management lazy erase - Adding support for config mgmt - Updating cborattr in MCUmgr to have similar support as mynewt-core - Fix unit tests and add some more for cborattr just like in mynewt-core - Change log_mgmt to use fragmenting so that an entry can be divided into smaller chunks while reading. - Fix mynewt port of os_mgmt - Add changes for backwards compatibility - Add sample app: omp_svr for trying out OICMGR over BLE/Serial - Fix reboot_log for soft resets Some more stuff that would follow after this change would be: 1. Release version for MCUmgr 2. Unifying MCUmgr tool Also, there were a lot of fixes that got in as part of this effort in >> the MCUmgr repo. I do encourage everybody to try it out. -- Regards, Vipul Rahane >>> >>> >>> -- >>> >>> Regards, >>> Vipul Rahane >> >> > > -- > > Regards, > Vipul Rahane

Re: Newt feature: run custom commands at build time

2019-09-25 Thread marko kiiskila

> On 24 Sep 2019, at 20.14, Christopher Collins wrote: > > Hi Marko, > > On Tue, Sep 24, 2019 at 03:19:24PM +0300, marko kiiskila wrote: >> Thanks, this is a very useful feature. >> >>> On 24 Sep 2019, at 3.50, Christopher Collins wrote: >>> >> ... >>> >>> A package specifies custom commands in its `pkg.yml` file. There are >>> two types of commands: 1) pre_cmds (run before the build), and 2) >>> post_cmds (run after the build). >>> >>> ### EXAMPLE >>> >>> Example (apps/blinky/pkg.yml): >>> >>> pkg.pre_cmds: >>> scripts/pre_build1.sh: 100 >>> scripts/pre_build2.sh: 200 >>> >>> pkg.post_cmds: >>> scripts/post_build.sh: 100 >>> >>> For each command, the string on the left specifies the command to run. >>> The number on the right indicates the command's relative ordering. >> >> I wasn’t sure about need for numbering, but I can see a use if execution >> of custom commands depends on a syscfg variable being set. > > I also wasn't sure about using numbered stages. It would be simpler if > each package specified a sequence of commands rather than a mapping. > > I was envisioning a case where package A generates some intermediate > file, then package B reads this file and produces the final output. In > this scenario, B's scripts must run after A's scripts. Assigning stages > to each command allows the user to enforce this ordering. Yes you are > right - packages would need to use syscfg settings to define the stages > for this to be useful. > > Another abstract use case: several scripts emit strings to some temp > files, then a final script would gather these files and generate a .c / > .h pair. Admittedly, I can't think of a concrete example where this > would be needed. > > My feeling is we should continue using numeric stages here because a) > they could conceivably be useful, and b) it's already implemented this > way :). I'm really uncertain about this though, so if you (or anyone > else) has a strong opinion about this, please just let me know and I'll > go with it. I do not have strong opinion about this one. I’m fine with the scheme you have described. > >> I think one useful addition would be to have another class of commands >> for linking phase. Often there’s a need to convert the binary to some >> other format, or slap in another header (like with DA1469x bootloader). >> Maybe have such an option for BSP packages? pkg.post_cmds would >> get executed after generating object files, and maybe pkg.post_link_cmds >> would get executed after linking? > > That is a good idea. How about this naming scheme: > >* pre_build_cmds >* pre_link_cmds >* post_build_cmds > > ? That seems reasonable. > > I also think we would need some an additional environment variables to > make this useful: > >* MYNEWT_PKG_BIN_DIR(dir where .o / .a files get written) >* MYNEWT_PKG_BIN_FILE (full path of .a file) > > While we are at it, might as well add one more: > >* MYNEWT_USER_WORK_DIR (temp dir shared by all scripts) > > It might be useful for scripts that feed input to other scripts. > Sounds good. If we need to add more, we can do that later. — M

Re: Newt feature: run custom commands at build time

2019-09-24 Thread marko kiiskila

Thanks, this is a very useful feature. > On 24 Sep 2019, at 3.50, Christopher Collins wrote: > ... > > A package specifies custom commands in its `pkg.yml` file. There are > two types of commands: 1) pre_cmds (run before the build), and 2) > post_cmds (run after the build). > > ### EXAMPLE > > Example (apps/blinky/pkg.yml): > >pkg.pre_cmds: >scripts/pre_build1.sh: 100 >scripts/pre_build2.sh: 200 > >pkg.post_cmds: >scripts/post_build.sh: 100 > > For each command, the string on the left specifies the command to run. > The number on the right indicates the command's relative ordering. I wasn’t sure about need for numbering, but I can see a use if execution of custom commands depends on a syscfg variable being set. I think one useful addition would be to have another class of commands for linking phase. Often there’s a need to convert the binary to some other format, or slap in another header (like with DA1469x bootloader). Maybe have such an option for BSP packages? pkg.post_cmds would get executed after generating object files, and maybe pkg.post_link_cmds would get executed after linking?

fs/fcb2 API

2019-09-09 Thread marko kiiskila

Hi, I was going to rename API elements under fs/fcb2 to have ‘fcb2’ prefix instead of current ‘fcb’. Currently the namespace is the same as it is for fs/fcb, even though the API is not the same. Let me know if you’re already using FCB2, and still need to have the existing API available in parallel. — M

Re: [VOTE] Release Apache Mynewt 1.7.0-rc1 and Apache NimBLE 1.2.0-rc1

2019-07-19 Thread marko kiiskila

+1 > On 19 Jul 2019, at 16.36, Miguel Azevedo wrote: > > +1 (binding) > > On Fri, 19 Jul 2019, 14:19 Fabio Utzig, wrote: > >> On Fri, Jul 19, 2019, at 9:37 AM, Szymon Janc wrote: >>> Hello all, >>> >>> I am pleased to be calling this vote for the source release of >>> Apache Mynewt 1.7.0 and Apache NimBLE 1.2.0. >> >>> [ ] +1 Release this package >>> [ ] 0 I don't feel strongly about it, but don't object >>> [ ] -1 Do not release this package because... >> >> +1 (binding) >> >>

Re: Mynewt load command query

2019-06-17 Thread marko kiiskila

> On 16 Jun 2019, at 7.29, Asmita Jha wrote: > > > > Hello, > > I am working on Real-time location system using MDEK1001 kit. I am > successfully able to do things with the already built firmware image that > has come with the board. I am now trying to implement using my newt as given > on the decawav github site : https://github.com/Decawave/mynewt-dw1000-apps. > I am facing some issues, I am posting the issue here. > > I erased the default flash image using JLink. Now, while loading the > bootloader as per given guideline on github, it is stuck at point . Same > thing is happening when I am trying to load blinky example as given on > mynewt website. I have shown here the verbose that I got : Windows systems have been problematic in the past, not sure what the current expected dev system setup is supposed to be. I imagine you followed the latest info from mynewt.apache.org ? Problems are mostly due to pathnames. > > newt load dwm1001_boot -v > Loading bootloader > Load command: > E:/Projects/RTLS/nRF/GitCodes/mynewt-dw1000-apps/repos/mynewt-dw1000-core/hw > /bsp/dwm1001/dwm1001_download.cmd Debug tip: add ‘set -x’ in the start of E:/Projects/RTLS/nRF/GitCodes/mynewt-dw1000-apps/repos/mynewt-dw1000-core/hw/bsp/dwm1001/dwm1001_download.sh it’ll cause it to echo everything the shell script is running underneath. Specifically, you’ll see the exact command line used when doing the download. That on it’s own might tell you what’s not working. If not, uou can cut’n’paste that and execute the command(s) by hand. See what gets stuck. > E:/Projects/RTLS/nRF/GitCodes/mynewt-dw1000-apps/repos/mynewt-dw1000-core/hw > /bsp/dwm1001 bin\targets\dwm1001_boot\app\apps\boot\boot > Environment: > > *BOOT_LOADER=1 > > *FEATURES=BASELIBC_PRESENT BOOT_LOADER BSP_NRF52 CONSOLE_UART_BAUD > CONSOLE_UART_DEV CONSOLE_UART_FLOW_CONTROL DW1000_DEVICE_0_IRQ > DW1000_DEVICE_0_RST DW1000_DEVICE_0_RX_ANT_DLY DW1000_DEVICE_0_SS > DW1000_DEVICE_0_TX_ANT_DLY DW1000_DEVICE_BAUDRATE_HIGH > DW1000_DEVICE_BAUDRATE_LOW FLASH_MAP_MAX_AREAS HAL_FLASH_VERIFY_BUF_SZ > I2C_0_FREQ_KHZ I2C_1_FREQ_KHZ I2C_1_PIN_SCL I2C_1_PIN_SDA MBEDTLS_AES_C > MBEDTLS_BASE64_C MBEDTLS_ECP_DP_SECP224R1 MBEDTLS_ENTROPY_C > MBEDTLS_PKCS1_V15 MBEDTLS_PKCS1_V21 MCU_DCDC_ENABLED > MCU_FLASH_MIN_WRITE_SIZE MCU_NRF52832 MSYS_1_BLOCK_SIZE NFC_PINS_AS_GPIO > OS_CPUTIME_FREQ OS_CTX_SW_STACK_GUARD OS_IDLE_TICKLESS_MS_MAX > OS_IDLE_TICKLESS_MS_MIN OS_MAIN_STACK_SIZE OS_MAIN_TASK_PRIO > OS_SYSVIEW_TRACE_CALLOUT OS_SYSVIEW_TRACE_EVENTQ OS_SYSVIEW_TRACE_MUTEX > OS_SYSVIEW_TRACE_SEM QSPI_FLASH_SECTOR_COUNT QSPI_PIN_CS QSPI_PIN_DIO0 > QSPI_PIN_DIO1 QSPI_PIN_DIO2 QSPI_PIN_DIO3 QSPI_PIN_SCK SANITY_INTERVAL > SPI_0_MASTER_PIN_MISO SPI_0_MASTER_PIN_MOSI SPI_0_MASTER_PIN_SCK TIMER_0 > UARTBB_0_PIN_RX UARTBB_0_PIN_TX UART_0_PIN_CTS UART_0_PIN_RTS UART_0_PIN_RX > UART_0_PIN_TX UART_1_PIN_CTS UART_1_PIN_RTS WATCHDOG_INTERVAL XTAL_32768 > > *FLASH_OFFSET=0x0 > > *IMAGE_SLOT=0 > > * > CORE_PATH=E:/Projects/RTLS/nRF/GitCodes/mynewt-dw1000-apps/repos/apache-myne > wt-core > > * > BSP_PATH=E:/Projects/RTLS/nRF/GitCodes/mynewt-dw1000-apps/repos/mynewt-dw100 > 0-core/hw/bsp/dwm1001 > > *BIN_BASENAME=bin\targets\dwm1001_boot\app\apps\boot\boot > > After this, nothing is happening . How much time does it takes to upload the > bootloader? Less than a second. Should exit pretty much immediately. I have not used decawave, but some boards come with flash locked (redbear nano2, so you had to reset the locking with JLinkExe before downloading things). Good luck, M

Re: Adding a callback before asm("bkpt") in the assert function and hal_system_reset()

2019-05-03 Thread marko kiiskila

:) It would not, as in that scenario there is no gdb context to execute these. If C_DEBUGEN bit in the Debug Halting Control and Status Register (DHCSR) is not cleared on debugger detach, I don’t think firmware can do it either. It’s JLink/openocd which is supposed to clear this when it detaches. You could at least clear that manually at the end of the BSP download script. Possibly could attempt to clear it in hook-quit with gdb. Doing those 2 things might lessen the likelihood of that bit staying set. > On 3 May 2019, at 12.41, Vipul Rahane wrote: > > Hi Marko, > > Exactly what I was thinking just did not know how to do it but there was > one hiccup with this approach. Would this work when the device is not > physically connected to the debugger but was previously connected to the > debugger but still keeps thinking that it was since the MCU is in the debug > state. > > On Fri, May 3, 2019 at 2:37 AM marko kiiskila wrote: > >> You can execute stuff within gdb when it hits a breakpoint. >> >> function hook-stop gets called when you stop in debugger. >> hook-run and hook-continue execute if you ‘run’ or ‘continue’ from >> debugger, respectively. >> >> define hook-stop >> handle SIGALRM nopass >> end >> >> define hook-run >> handle SIGALRM pass >> end >> >> define hook-continue >> handle SIGALRM pass >> end >> >> If you load this this script in the debug script, these will happen >> automagically for your BSP. No code changes necessary then, >> or conditionally compiled code. >> >>> On 3 May 2019, at 10.31, Andrzej Kaczmarek < >> andrzej.kaczma...@codecoup.pl> wrote: >>> >>> Hi, >>> >>> I already put some of comments below in (already merged) PR which seems >> to >>> add this functionality, but this gives more context about the change >> itself >>> so I have few more comments. >>> >>> On Fri, May 3, 2019 at 1:57 AM Vipul Rahane wrote: >>> >>>> Hello, >>>> >>>> So, we are running into an issue where some peripheral needs to get shut >>>> down before the breakpoint gets hit. this only happens when the >> debugger is >>>> connected and so, it quite isolated in terms on functionality. >>>> >>> >>> It would be better to have such callback/whatever as a general option, >> not >>> only while debugger is connected, since this makes it more generic and >> you >>> can easily check if debugger is connected in your callback. >>> >>> >>>> There are different approaches we could follow: >>>> >>>> 1. Have a macro (syscfg) define that function and call that macro >>>> >>>> 154 #ifdef MYNEWT_VAL_HAL_SYSTEM_PRE_BKPT_CB >>>> 155HAL_SYSTEM_PRE_BKPT_CB(); >>>> 156 #endif >>>> 157 >>>> 158 #if !MYNEWT_VAL(MCU_DEBUG_IGNORE_BKPT) >>>> 159asm("bkpt"); >>>> 160 #endif >>>> >>>> 2. Have a `hal_system_pre_bkpt_cb()` function, register a callback and >> have >>>> one specific MCU call it only if a syscfg is set, something like: >>>> >>>> 154 #ifdef MYNEWT_VAL(HAL_SYSTEM_PRE_BKPT_CB) >>>> 155hal_system_pre_bkpt_cb(); >>>> 156 #endif >>>> 157 >>>> 158 #if !MYNEWT_VAL(MCU_DEBUG_IGNORE_BKPT) >>>> 159asm("bkpt"); >>>> 160 #endif >>>> >>> >>> I am not a fan of injecting code via syscfg, so definitely would prefer >>> callback approach or just have a function declaraction that application >>> should define if those callbacks are enabled. - this is quite low level >> API >>> so user-friendliness of a callbacks is not something I'd require, but >> otoh >>> there may be some scenarios where callbacks could be useful (I don't have >>> anything specific in mind). >>> >>> Also refering to what was done in PR, I do not think that having a single >>> syscfg defined in MCU which controls code in both hal_system and >> kernel/os >>> is a good idea. I'd prefer separate options for callback in >>> hal_system_reset (like MCU_PRE_RESET_CALLBACK) and __assert_func (like >>> OS_ASSERT_CALLBACK). >>> >>> These are just some simple suggestions we could follow, obviously there >> is >>>> a hard way of doing this thing where we change APIs and register a >> callback >>>> and have assert take that callback as an argument but I am not a big >> fan of >>>> changing standard APIs. >>>> >>>> If others have a suggestion, please let me know. If not I am going to >>>> assume everybody is fine with option 2. >>>> >>>> -- >>>> >>>> Regards, >>>> Vipul Rahane >>>> >>> >>> Best, >>> Andrzej > > > Regards, > Vipul Rahane > >> >> >> -- > > Regards, > Vipul Rahane

Re: Adding a callback before asm("bkpt") in the assert function and hal_system_reset()

2019-05-03 Thread marko kiiskila

You can execute stuff within gdb when it hits a breakpoint. function hook-stop gets called when you stop in debugger. hook-run and hook-continue execute if you ‘run’ or ‘continue’ from debugger, respectively. define hook-stop handle SIGALRM nopass end define hook-run handle SIGALRM pass end define hook-continue handle SIGALRM pass end If you load this this script in the debug script, these will happen automagically for your BSP. No code changes necessary then, or conditionally compiled code. > On 3 May 2019, at 10.31, Andrzej Kaczmarek > wrote: > > Hi, > > I already put some of comments below in (already merged) PR which seems to > add this functionality, but this gives more context about the change itself > so I have few more comments. > > On Fri, May 3, 2019 at 1:57 AM Vipul Rahane wrote: > >> Hello, >> >> So, we are running into an issue where some peripheral needs to get shut >> down before the breakpoint gets hit. this only happens when the debugger is >> connected and so, it quite isolated in terms on functionality. >> > > It would be better to have such callback/whatever as a general option, not > only while debugger is connected, since this makes it more generic and you > can easily check if debugger is connected in your callback. > > >> There are different approaches we could follow: >> >> 1. Have a macro (syscfg) define that function and call that macro >> >> 154 #ifdef MYNEWT_VAL_HAL_SYSTEM_PRE_BKPT_CB >> 155HAL_SYSTEM_PRE_BKPT_CB(); >> 156 #endif >> 157 >> 158 #if !MYNEWT_VAL(MCU_DEBUG_IGNORE_BKPT) >> 159asm("bkpt"); >> 160 #endif >> >> 2. Have a `hal_system_pre_bkpt_cb()` function, register a callback and have >> one specific MCU call it only if a syscfg is set, something like: >> >> 154 #ifdef MYNEWT_VAL(HAL_SYSTEM_PRE_BKPT_CB) >> 155hal_system_pre_bkpt_cb(); >> 156 #endif >> 157 >> 158 #if !MYNEWT_VAL(MCU_DEBUG_IGNORE_BKPT) >> 159asm("bkpt"); >> 160 #endif >> > > I am not a fan of injecting code via syscfg, so definitely would prefer > callback approach or just have a function declaraction that application > should define if those callbacks are enabled. - this is quite low level API > so user-friendliness of a callbacks is not something I'd require, but otoh > there may be some scenarios where callbacks could be useful (I don't have > anything specific in mind). > > Also refering to what was done in PR, I do not think that having a single > syscfg defined in MCU which controls code in both hal_system and kernel/os > is a good idea. I'd prefer separate options for callback in > hal_system_reset (like MCU_PRE_RESET_CALLBACK) and __assert_func (like > OS_ASSERT_CALLBACK). > > These are just some simple suggestions we could follow, obviously there is >> a hard way of doing this thing where we change APIs and register a callback >> and have assert take that callback as an argument but I am not a big fan of >> changing standard APIs. >> >> If others have a suggestion, please let me know. If not I am going to >> assume everybody is fine with option 2. >> >> -- >> >> Regards, >> Vipul Rahane >> > > Best, > Andrzej

Re: Blinky targets do not load

2019-01-28 Thread marko kiiskila

Hi Simon, I have a source tree of openocd 0.10 with that capability. And I have built versions for Linux/MacOS as well, although you probably don’t want those. Let me know if you want me to send the source tarball. I should be able to generate a patch file out of it too. Bummer that the binaries are not there anymore. I use openocd to flash nrf52 occasionally. > On Jan 25, 2019, at 10:39 PM, Simon Ratner wrote: > > Correct, the version of openocd in homebrew does not work with nRF52. There > used to be a link to pre-built binaries that do work, but that link is gone > in the latest version of the docs. I have just run into this myself - no > idea why/when the docs were changed. > > Compare: > http://mynewt.apache.org/v1_4_0/get_started/native_install/cross_tools.html#installing-openocd-on-mac-os > http://mynewt.apache.org/latest/get_started/native_install/cross_tools.html#installing-openocd-on-mac-os > > There is still a comment about this in the new docs (in the previous > section), but the link to download is gone and the instructions tell you to > install from brew, which does not work. > > simon > > > On Thu, Jan 3, 2019 at 8:09 AM Fabio Utzig wrote: > >> Hi Duane, >> >> I believe, but am not entirely sure, that OpenOCD 0.10.0 release was not >> able to flash nrf52x devices. I would suggest installing the latest from >> git. If using homebrew: >> >> $ brew install --HEAD open-ocd >> >> Or "reinstall" might work (sorry, not macOS user here!) >> >> Best, >> Fabio >> >> On Thu, Jan 3, 2019, at 1:26 PM, Duane Hooton wrote: >>> I am attempting to establish a newt environment on a MacBook running >>> Mojave. This is a new computer and only supports usb-c ports. I have >>> attached a newt nano2 through an adapter to one of these ports. >>> >>> I have meticulously followed the steps to produce the Blinky app and >>> associated boot loader. Here is the output from newt target show: >>> >>> targets/my_blinky_sim >>> >>>app=apps/blinky >>> >>>bsp=@apache-mynewt-core/hw/bsp/native >>> >>>build_profile=debug >>> >>> targets/rbnano2_blinky >>> >>>app=apps/blinky >>> >>>bsp=@apache-mynewt-core/hw/bsp/rb-nano2 >>> >>>build_profile=debug >>> >>> targets/rbnano2_boot >>> >>>app=@apache-mynewt-core/apps/boot >>> >>>bsp=@apache-mynewt-core/hw/bsp/rb-nano2 >>> >>>build_profile=optimized >>> >>> The targets build successfully but when I attempt to load them I get the >>> following output: >>> >>> newt load rbnano2_blinky -v >>> >>> Loading app image into slot 1 >>> >>> Load command: >>> /Users/dhooton/Documents/projects/proxy/blinky/repos/apache-mynewt-core/ >>> hw/bsp/rb-nano2/rb-nano2_download.sh >>> /Users/dhooton/Documents/projects/proxy/blinky/repos/apache-mynewt-core/ >>> hw/bsp/rb-nano2 >>> bin/targets/rbnano2_blinky/app/apps/blinky/blinky >>> >>> Environment: >>> >>> * FEATURES=BASELIBC_PRESENT BSP_NRF52 CONSOLE_UART_BAUD CONSOLE_UART_DEV >>> CONSOLE_UART_FLOW_CONTROL FLASH_MAP_MAX_AREAS HAL_FLASH_VERIFY_BUF_SZ >>> I2C_0_FREQ_KHZ I2C_0_PIN_SCL I2C_0_PIN_SDA I2C_1_FREQ_KHZ >> MCU_DCDC_ENABLED >>> MCU_FLASH_MIN_WRITE_SIZE MCU_NRF52832 MSYS_1_BLOCK_COUNT >> MSYS_1_BLOCK_SIZE >>> NFC_PINS_AS_GPIO OS_CPUTIME_FREQ OS_CTX_SW_STACK_GUARD >>> OS_IDLE_TICKLESS_MS_MAX OS_IDLE_TICKLESS_MS_MIN OS_MAIN_STACK_SIZE >>> OS_MAIN_TASK_PRIO OS_SCHEDULING OS_SYSVIEW_TRACE_CALLOUT >>> OS_SYSVIEW_TRACE_EVENTQ OS_SYSVIEW_TRACE_MUTEX OS_SYSVIEW_TRACE_SEM >>> QSPI_FLASH_SECTOR_COUNT QSPI_PIN_CS QSPI_PIN_DIO0 QSPI_PIN_DIO1 >>> QSPI_PIN_DIO2 QSPI_PIN_DIO3 QSPI_PIN_SCK SANITY_INTERVAL >>> SPI_0_MASTER_PIN_MISO SPI_0_MASTER_PIN_MOSI SPI_0_MASTER_PIN_SCK >>> SPI_0_SLAVE_PIN_MISO SPI_0_SLAVE_PIN_MOSI SPI_0_SLAVE_PIN_SCK >>> SPI_0_SLAVE_PIN_SS SPI_1_MASTER_PIN_MISO SPI_1_MASTER_PIN_MOSI >>> SPI_1_MASTER_PIN_SCK SPI_1_SLAVE_PIN_MISO SPI_1_SLAVE_PIN_MOSI >>> SPI_1_SLAVE_PIN_SCK SPI_1_SLAVE_PIN_SS SYSINIT_CONSTRAIN_INIT TIMER_0 >>> UARTBB_0_PIN_RX UARTBB_0_PIN_TX UART_0 UART_0_PIN_CTS UART_0_PIN_RTS >>> UART_0_PIN_RX UART_0_PIN_TX UART_1_PIN_CTS UART_1_PIN_RTS >> WATCHDOG_INTERVAL >>> XTAL_32768 >>> >>> * FLASH_OFFSET=0x8000 >>> >>> * IMAGE_SLOT=0 >>> >>> * >>> CORE_PATH=/Users/dhooton/Documents/projects/proxy/blinky/repos/apache- >>> mynewt-core >>> >>> * >>> BSP_PATH=/Users/dhooton/Documents/projects/proxy/blinky/repos/apache- >>> mynewt-core/hw/bsp/rb-nano2 >>> >>> * BIN_BASENAME=bin/targets/rbnano2_blinky/app/apps/blinky/blinky >>> >>> Error: >>> >>> Downloading bin/targets/rbnano2_blinky/app/apps/blinky/blinky.img to >> 0x8000 >>> >>> Open On-Chip Debugger 0.10.0 >>> >>> Licensed under GNU GPL v2 >>> >>> For bug reports, read >>> >>> http://openocd.org/doc/doxygen/bugs.html >>> >>> Info : auto-selecting first available session transport "swd". To >> override >>> use 'transport select '. >>> >>> adapter speed: 1 kHz >>> >>> cortex_m reset_config sysresetreq >>> >>> Info : CMSIS-DAP: SWD Supported >>> >>> Info : CMSIS-DAP: Interface Initialised (SWD) >>>

***UNCHECKED*** Re: msec and nsec delay in mynewt OS

2018-09-19 Thread marko kiiskila

> On Sep 19, 2018, at 4:48 PM, Rohit Gujarathi wrote: > > Hello all, > > I am new to mynewt OS and was wondering whats the most optimised way to get > accurate msec and nsec delay. > > I want to be able to call this delay in libraries as well. > E.g.: https://mynewt.apache.org/latest/os/core_os/cputime/os_cputime.html

Re: Getting involved ...

2018-09-17 Thread marko kiiskila

> On Sep 16, 2018, at 7:11 PM, Andrew Eliasz wrote: > > myNewtOS looks most interesting. > I would like to get involved ... and, in particular, > I would like to start with building some simple applications for the > BBC:Microbit > which is supported. Welcome. > Are there any really simple examples to get started ... > i.e. which compiler(s) to install, which build tools, dependencies and > suitable HAL layers and such … Start here. http://mynewt.apache.org/quick-start/ That should get your tools setup and a simple example loaded to microbit. Documentation about HAL http://mynewt.apache.org/latest/os/modules/hal/hal.html .

Re: Mynewt crash when releasing semaphore

2018-08-31 Thread marko kiiskila

it’s easiest to inspect these addresses with gdb :) arm-none-eabi-gdb bin/targets/……. .elf and then start feeding those addresses to see which ones look likely to be part of callchain. x/i 0x0003b4d8 x/i 0x000246a7 x/i 0x0003b4d8 etc > On Aug 31, 2018, at 3:30 PM, Aditya Xavier > wrote: > > Am really bad at GDB. Also its like a rabbit hole :) > > I ported over my application with the git version of Mynewt-core, and enabled > OS_CRASH_STACKTRACE. > > With it enabled, the following is the dump. > > #mesh-onoff STATUS: Sent ! > Action Received over MESH Length :- 14 > 000486 Unhandled interrupt (3), exception sp 0x2000aba0 > 000486 r0:0xcf0f98cb r1:0x5c5a76b3 r2:0x681af5c8 r3:0xb1334673 > 000486 r4:0x2000ac68 r5:0x0007 r6:0x r7:0x28a9 > 000486 r8:0x2000acf0 r9:0x00012101 r10:0xd7229882 r11:0xd929b3bb > 000486 r12:0x7e3cdeb8 lr:0x2266a80b pc:0x59d8de5b psr:0xe8eb9828 > 000486 ICSR:0x00421803 HFSR:0x4000 CFSR:0x0004 > 000486 BFAR:0xe000ed38 MMFAR:0xe000ed34 > 000486 task:DECODE_TASK > 000486 0x2000abec: 0x0003b4d8 > 000486 0x2000abf4: 0x000246a7 > 000486 0x2000ac04: 0x0003b4d8 > 000486 0x2000ac0c: 0x0002488d > 000486 0x2000ac4c: 0x00012101 > 000486 0x2000ad0c: 0xc1e7 > 000486 0x2000ad1c: 0xc1e7 > 000486 0x2000ad2c: 0xc211 > 000486 0x2000ad30: 0x0003ad44 > 000486 0x2000ad3c: 0x00013023 > 000486 0x2000ad58: 0x000238e1 > 000486 0x2000ad60: 0x00037f81 > 000486 0x2000ad6c: 0x00023a79 > 000486 0x2000ad70: 0x00039b80 > 000486 0x2000ad74: 0x00039b7f > 000486 0x2000ad84: 0x00023587 > 000486 0x2000ada8: 0x87cd > 000486 0x2000adc4: 0xd51d > 000486 0x2000adc8: 0xd51c > 000486 0x2000add8: 0x000398cd > 000486 0x2000ade4: 0x87e9 > 000486 0x2000ae08: 0x00010001 > 000486 0x2000ae0c: 0x0001c239 > 000486 0x2000ae10: 0x0003b35c > 000486 0x2000ae1c: 0x00020001 > 000486 0x2000ae20: 0x0001c38d > 000486 0x2000ae30: 0x00030001 > 000486 0x2000ae34: 0x0001c509 > 000486 0x2000ae48: 0x0001c38d > 000486 0x2000ae5c: 0x0001c509 > 000486 0x2000ae70: 0x0001c239 > 000486 0x2000ae74: 0x0003b37c > 000486 0x2000ae84: 0x0001c38d > 000486 0x2000ae98: 0x0001c509 > 000486 0x2000aeac: 0x0001c54d > 000486 0x2000aec0: 0x0001c239 > 000486 0x2000aec4: 0x0003ba28 > 000486 0x2000aed4: 0x0001c38d > 000486 0x2000aee8: 0x0001c509 > 000486 0x2000aefc: 0x0001c38d > 000486 0x2000af10: 0x0001c509 > 000486 0x2000af24: 0x0001c54d > 000486 0x2000af38: 0x0001c38d > 000486 0x2000af4c: 0x0001c509 > 000486 0x2000af60: 0x0001c38d > 000486 0x2000af74: 0x0001c509 > 000486 0x2000af88: 0x0001c54d > 000486 0x2000af9c: 0x0001c38d > 000486 0x2000afb0: 0x0001c509 > > >> On 31-Aug-2018, at 5:21 PM, marko kiiskila wrote: >> >> Some suggestions (inline). >> >>> On Aug 31, 2018, at 2:32 PM, Aditya Xavier >>> wrote: >>> >>> Gosh, this doesn’t make much sense to me :( >>> >>> (gdb) monitor go >>> (gdb) monitor reset >>> Resetting target >>> (gdb) c >>> Continuing. >>> >>> Program received signal SIGTRAP, Trace/breakpoint trap. >>> hal_system_reset () at >>> repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_system.c:50 >>> 50 asm("bkpt"); >>> (gdb) bt >>> #0 hal_system_reset () at >>> repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_system.c:50 >>> #1 0xbf2e in os_default_irq (tf=0x2000ffc8) at >>> repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:170 >>> #2 0xda56 in os_default_irq_asm () at >>> repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/m4/HAL_CM4.s:260 >>> #3 >>> #4 0x in ?? () >>> Backtrace stopped: previous frame identical to this frame (corrupt stack?) >>> (gdb) frame 1 >>> #1 0xbf2e in os_default_irq (tf=0x2000ffc8) at >>> repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:170 >>> 170 hal_system_reset(); >>> (gdb) p/x *tf >>> $1 = {ef = 0x2000abd0, r4 = 0x1b00, r5 = 0x2000acc0, r6 = 0x2000aca0, >>> r7 = 0x7, r8 = 0x0, r9 = 0x28a9, r10 = 0x2000ad28, r11 = 0x11d91, lr = >>> 0xfffd} >>> (gdb) p/x *tf->ef >>> $2 = {r0 = 0xd7229882, r1 = 0xd929b3bb, r2 = 0xcf0f98cb, r3 = 0x5c5a76b3, >>> r12 = 0x681af5c8, lr = 0xb1334673, pc = 0x7e3cdeb8, psr = 0x2266a80b} >>> (gdb) x/32x 0xd7229882 >>> 0xd7229882: 0x 0x 0x 0x >>> 0xd7229892: 0x 0x 0x 0x >>&

Re: Mynewt crash when releasing semaphore

2018-08-31 Thread marko kiiskila

8_t state[Nk*Nb]; That could be writing that random looking data in the stack. encrypted data should look like gibberish. Follow the stack a bit further starting continuing from 0x2000ac50. See if you find who called it. I’m hazarding a guess that one of those args passed to aes_encrypt() is pointing to stack, and there’s not enough memory allocated to hold that data. >> On 31-Aug-2018, at 4:46 PM, marko kiiskila wrote: >> >> Sure. Something like this: >> >> 000933 compat> crash div0 >> crash div0 >> 003157 Unhandled interrupt (3), exception sp 0x20001dd8 >> 003157 r0:0x r1:0x00017161 r2:0x r3:0x002a >> 003157 r4:0x200041d6 r5:0x r6:0x2318 r7:0x >> 003157 r8:0x r9:0x r10:0x r11:0x >> 003157 r12:0x lr:0x00014949 pc:0x00014978 psr:0x6100 >> 003157 ICSR:0x00421803 HFSR:0x4000 CFSR:0x0200 >> 003157 BFAR:0xe000ed38 MMFAR:0xe000ed34 >> >> Then from gdb: >> >> Program received signal SIGTRAP, Trace/breakpoint trap. >> hal_system_reset () >> at repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_system.c:50 >> 50 asm("bkpt"); >> (gdb) bt >> #0 hal_system_reset () >> at repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_system.c:50 >> #1 0x8be8 in os_default_irq (tf=0x2000ffc0) >> at repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:171 >> #2 0xa5b6 in os_default_irq_asm () >> at repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/m4/HAL_CM4.s:260 >> #3 >> #4 0x in ?? () >> #5 0x812c in Reset_Handler () >> at >> repos/apache-mynewt-core/hw/bsp/nrf52dk/src/arch/cortex_m4/gcc_startup_nrf52.s:180 >> Backtrace stopped: previous frame identical to this frame (corrupt stack?) >> (gdb) frame 1 >> #1 0x8be8 in os_default_irq (tf=0x2000ffc0) >> at repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:171 >> 171 hal_system_reset(); >> (gdb) p/x *tf >> $1 = {ef = 0x20001dd8, r4 = 0x200041d6, r5 = 0x0, r6 = 0x2318, r7 = 0x0, >> r8 = 0x0, r9 = 0x0, r10 = 0x0, r11 = 0x0, lr = 0xfffd} >> (gdb) p/x *tf->ef >> $2 = {r0 = 0x0, r1 = 0x17161, r2 = 0x0, r3 = 0x2a, r12 = 0x0, lr = 0x14949, >> pc = 0x14978, psr = 0x6100} >> (gdb) x/32x 0x20001dd8 >> 0x20001dd8 : 0x 0x00017161 >> 0x 0x002a >> 0x20001de8 : 0x 0x00014949 >> 0x00014978 0x6100 >> 0x20001df8 : 0x0003 0x >> 0x 0x002a >> 0x20001e08 : 0x0001 0x0002 >> 0x000a 0x00014a21 >> 0x20001e18 : 0x00014a15 0xebd9 >> 0x 0x200041d0 >> 0x20001e28 : 0x200041d6 0x >> 0x000a 0x0001574d >> 0x20001e38 : 0x00015741 0xc925 >> 0x200041d0 0x0011 >> 0x20001e48 : 0x0073 0x200041d3 >> 0x 0xede9 >> (gdb) p &__text >> $3 = ( *) 0x8020 <__isr_vector> >> (gdb) p &__etext >> $4 = ( *) 0x175f0 >> (gdb) x/i 0x00017161 >> 0x17161:movsr0, r0 >> (gdb) x/i 0x00014949 >> 0x14949 : cbz r0, 0x1496a >> (gdb) x/i 0x00014978 >> 0x14978 : sdivr3, r3, r2 >> (gdb) x/i 0x00014a21 >> 0x14a21 : cbz r0, 0x14a28 >> (gdb) x/i 0x00014a15 >> 0x14a15 :push{r3, lr} >> (gdb) list *0x14949 >> 0x14949 is in crash_device >> (repos/apache-mynewt-core/test/crash_test/src/crash_test.c:42). >> warning: Source file is more recent than executable. >> 37 int >> 38 crash_device(char *how) >> 39 { >> 40 volatile int val1, val2, val3; >> 41 >> 42 if (!strcmp(how, "div0")) { >> 43 >> 44 val1 = 42; >> 45 val2 = 0; >> 46 >> (gdb) list *0x00014a21 >> 0x14a21 is in crash_cli_cmd >> (repos/apache-mynewt-core/test/crash_test/src/crash_cli.c:41). >> 36 }; >> 37 >> 38 static int >> 39 crash_cli_cmd(int argc, char **argv) >> 40 { >> 41 if (argc >= 2 && crash_device(argv[1]) == 0) { >> 42 return 0; >> 43 } >> 44 console_printf("Usage crash [div0|jump0|ref0|assert|wdog]\n"); >> 45 return 0; >> (gdb) list *0x14a21 >> 0x14a21 is in crash_cli_cmd >> (repos/apache-mynewt-core/test/crash_test/src/crash_cli.c:41). >> 36 }; >> 37 >> 38 static int >&

Re: Mynewt crash when releasing semaphore

2018-08-31 Thread marko kiiskila

asm("bkpt"); > (gdb) where > #0 hal_system_reset () at > repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_system.c:50 > #1 0xbf2e in os_default_irq (tf=0x2000ffc8) at > repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:170 > #2 0xda56 in os_default_irq_asm () at > repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/m4/HAL_CM4.s:260 > #3 > #4 0x in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > > >> On 31-Aug-2018, at 4:30 PM, marko kiiskila wrote: >> >> >> >>> On Aug 31, 2018, at 1:47 PM, Aditya Xavier >>> wrote: >>> >>> Hi ! >>> >>> Am having an issue with Sending and Receiving a Mesh Message. Though am >>> positive the problem is more towards releasing the semaphore. >>> >>> Action Received over MESH Length :- 15 >>> 012273 Unhandled interrupt (3), exception sp 0x2000abd0 >>> 012273 r0:0xd7229882 r1:0xd929b3bb r2:0xcf0f98cb r3:0x5c5a76b3 >>> 012273 r4:0x1b00 r5:0x2000acc0 r6:0x2000aca0 r7:0x0008 >>> 012273 r8:0x r9:0x28a9 r10:0x2000ad28 r11:0x00011d91 >>> 012273 r12:0x681af5c8 lr:0xb1334673 pc:0x7e3cdeb8 psr:0x2266a80b >>> 012273 ICSR:0x00411803 HFSR:0x4000 CFSR:0x0004 >>> 012273 BFAR:0xe000ed38 MMFAR:0xe000ed34 >>> >>> Am sending a group mesh message for testing. The sequence of events are as >>> follows. >>> >>> Button TASK -> send message over MESH -> Mesh receives message on model -> >>> copies the data and starts releases the Semaphore for another task -> LOG >>> Task starts and logs the message. >>> >>> In this entire flow, the moment I receive the message and release the >>> semaphore the firmware crashes. >>> >>> I tried increasing the STACK size of the LOG task, however that didn’t help. >>> >>> Could someone let me know how to understand where / why the crash is >>> happening ? >> >> Looking at your registers they seem to be garbage, so I’m guessing stack >> corruption of some sort; does not have to be overflow. >> Try turning on OS_CRASH_STACKTRACE, or manually walk the stack for looking >> for things which >> look like pointers to text. >> >> >

Re: I2C retries

2018-08-30 Thread marko kiiskila

> On Aug 30, 2018, at 7:21 PM, Christopher Collins wrote: > > On Wed, Aug 29, 2018 at 10:06:37PM -0500, Greg Stein wrote: >> On Wed, Aug 29, 2018 at 8:59 PM Christopher Collins >> wrote: >> >>> Hello all, >>> >>> I noticed the HAL master I2C API does not include any retry logic. As >>> you probably know, in I2C, the default state of the SCL line is NACK. >>> >> >> Euh... ACK/NACK is on SDA while the master cycles SCL. > > Yes, you are right. Thanks for the correction. > > [...] > >> Or that something monkeyed the bus, so the peripheral decided to stop >> receiving/processing. ... Your basic point holds: a peripheral might just >> go away for any number of reasons. I wouldn't even bother with the on_dnack >> flag. Seems better to consider retry at the whole-packet level. It all gets >> sent, or it did not and should be retried. > > Thank you for the insight. I am starting to think you are right - > retries should be done by the low-level HAL implementation. So, my > current thinking is that we should make the following changes: > > 1. Define a common set of error code for the I2C HAL [1]. > 2. Add a single member to the `hal_i2c_master_data` struct: `tries` [2] > 3. Modify the HAL I2C implementations so that they retry up to (tries-1) > times when an unexpected NACK is recieved. Sounds good. Extending the struct seems like the natural place to do it. I don’t think we should worry about binary compatibility. > [1] We should do the same for the other HAL APIs (i.e., non-I2C), but > that can come later. Not sure this makes sense for other ones, as i2c is the only one with ACK. > > [2] I prefer specifying number of tries rather than number of retries. > I think it helps avoid some ambiguity. Seems fine to me. > > All comments welcome. > > Thanks, > Chris

Re: debounce/debounce.h

2018-08-28 Thread marko kiiskila

Thanks, what I meant to say was that minimally one of the header files should be renamed for builds to work :) Although similar paths to the header is probably also confusing. > On Aug 28, 2018, at 6:04 PM, Christopher Collins wrote: > > I added the second one (util/debounce) without checking if another one > already existed. I'll come up with a new name for util/debounce today > and submit a PR. > > Chris > > On Tue, Aug 28, 2018 at 05:33:22PM +0300, marko kiiskila wrote: >> mynewt-core has 2 debounce packages. Trying to include both packages >> within a project is giving me trouble. >> >> I think one should be renamed. Which one? >> >> [marko@IsMyLaptop:~/src2/incubator-mynewt-blinky/repos/apache-mynewt-core]$ >> find . -name debounce.h >> ./hw/drivers/debounce/include/debounce/debounce.h >> ./util/debounce/include/debounce/debounce.h >>

debounce/debounce.h

2018-08-28 Thread marko kiiskila

mynewt-core has 2 debounce packages. Trying to include both packages within a project is giving me trouble. I think one should be renamed. Which one? [marko@IsMyLaptop:~/src2/incubator-mynewt-blinky/repos/apache-mynewt-core]$ find . -name debounce.h ./hw/drivers/debounce/include/debounce/debounce.h ./util/debounce/include/debounce/debounce.h

Re: CBOR Decoding problem

2018-08-13 Thread marko kiiskila

It is possible it might not work right off the bat. At least, I have not built such objects myself. We do accept contributions ;) You can also build code using the tinycbor decoder. This is what cborattr itself uses, if you don’t have time to augment cborattr. > On Aug 13, 2018, at 10:28 AM, Aditya Xavier > wrote: > > Thanks for replying ! > > Yeah, but If I do that, I won’t have an Array of Arrays right ? > > i.e. I want to have {a:[1,2,3,4], b:[ {c:[1,2,3,4,5]}, {c:[1,2,3,4,5]}]} > structure.. > > Which means, I need multiple instances of C object. Hence the struct c_object > creation.. If I make CborAttrArrayType > > Am not sure that will work. > > Please correct me if am wrong. > > Thanks, > Aditya Xavier. > > > >> On 13-Aug-2018, at 12:53 PM, marko kiiskila wrote: >> >> “c" looks like an int array instead of an object. Hope that helps >> >>> On Aug 10, 2018, at 10:06 AM, Aditya Xavier >>> wrote: >>> >>> Hello ! >>> >>> >>> Require some guidance on how to write a CBOR parsing implementation for the >>> following structure. >>> >>> {a:[1,2,3,4], b:[ {c:[1,2,3,4,5]}, {c:[1,2,3,4,5]}]} >>> >>> I tried the following implementation. >>> ——— >>> >>> uint64_t a[5]; >>> Int a_count = 0; >>> >>> struct c_object{ >>> int c[6]; >>> }c_arr_objs[5]; >>> int c_obj_count = 0; >>> >>> struct cbor_attr_t c_attrs[] = { >>> { >>> .attribute = “c", >>> .type = CborAttrObjectType, >>> CBORATTR_STRUCT_OBJECT(struct c_object, c), >>> .dflt.integer = 0 >>> }, >>> { >>> .attribute = NULL >>> } >>> }; >>> >>> >>> struct cbor_attr_t root_attrs[] = { >>> { >>> .attribute = “a", >>> .type = CborAttrArrayType, >>> .addr.array.element_type = CborAttrUnsignedIntegerType, >>> .addr.array.arr.uintegers.store = a, >>> .addr.array.count = _count, >>> .addr.array.maxlen = sizeof(a) / sizeof(a[0]), >>> .nodefault = true >>> }, >>> { >>> .attribute = “b", >>> .type = CborAttrArrayType, >>> CBORATTR_STRUCT_ARRAY(c_arr_objs, c_attrs, _obj_count), >>> .nodefault = true >>> }, >>> { >>> .attribute = NULL >>> } >>> }; >>> >>> ——— >>> >>> >>> I assumed this to work as I have been using the same albeit without ‘c’ >>> being a int Array. It works when I use ‘c’ as a Int etc, but not as a int >>> Array, >>> >>> The example :- >>> https://github.com/apache/mynewt-core/blob/master/encoding/cborattr/test/src/testcases/cborattr_decode_object_array.c >>> >>> <https://github.com/apache/mynewt-core/blob/master/encoding/cborattr/test/src/testcases/cborattr_decode_object_array.c> >>> >>> Has a similar implementation for Text String instead of Int Array. >>> >>> Thanks, >>> Aditya Xavier. >>> >>> >>> >> >

Re: FCB revamp

2018-07-30 Thread marko kiiskila

Hi, > On Jul 30, 2018, at 1:47 PM, Laczen JMS wrote: > > Hi Marko and Will, > > I have been studying fcb and I think you can leave it at 8 bit as it > was. The crc can only be interpreted as a check that > the closing was done properly. As soon as the crc check fails this > only means that the closing failed. It could just as well > be fixed to zero instead of a crc. That is a valid point. If you can’t trust your data path to flash, what can you trust? > > When writing errors (bit errors) would occur fcb would need a lot more > protection, the length which is written first could > no longer be trusted and it would be impossible to find the crc. The > writing of the length can also be a more problematic > case to solve, what happens when the write of the length fails and the > length that is read is pointing outside the sector ? On the other hand, there are flashes where multiple write cycles to same location are allowed; you can keep turning more bits to zero. There you can corrupt the data after writing. And on some the default, unwritten state is 0 (this we need to address for FCB, image management). You’re right; adding mechanisms to detect corruption of length field, for example, starts to get complicated and costly. Recovery is easier to do, however, if we use a stronger version of CRC. I.e. if CRC does not match, then just go forward a byte at a time until it does. > > Kind regards, > > Jehudi > > > Op ma 30 jul. 2018 om 11:10 schreef marko kiiskila : >> >> Thanks for the response, Will. >> >> I made it one-byte because the scenario where the CRC check strength comes >> into play is somewhat rare; >> it is to detect partial writes. I.e. when fcb_append_finish() fails to get >> called. This, presumably, would >> onlly happen on crash/power outage within a specific time window. This is >> not used as an error detection >> mechanism on a channel where we expect bit errors. >> >> The way I did it was I added 2 syscfg knobs to control which CRC is included >> in the build. In case you get >> really tight on code space. Of course, newtmgr uses CRC16, so if you have >> that enabled, >> there is no gain. >> There’s 3 different options when starting FCB: inherit from flash, force 16 >> bit, or force 8 bits. If the flash region >> has not been initialized with anything, then the ‘inherit’ option will >> prefer 16 bits over 8 bits. >> So if you need to worry about backwards compatibility, set ‘inherit’. If you >> want to use 16 bit, and are flashing >> a new device, use ‘inherit’ or set ‘force 16bits’. If you need to keep FCB >> region backwards compatible, use >> option ‘force 8 bits’. >> >> >>> On Jul 27, 2018, at 11:05 PM, will sanfilippo wrote: >>> >>> I realize I am a bit late with these comments but better late than never I >>> guess. Well, maybe some or all of these comments should never be made :-) >>> This could be a horrible idea but why not just make it backward >>> incompatible? (for #2). Maybe have a syscfg for folks that want to use the >>> old format in the code? I would even consider making all entries have a >>> two-byte CRC (regardless of length of data written). I presume the resume >>> that it was one-byte was to save flash space? Heck, maybe even allow the >>> syscfg to specify a 32-bit CRC (for those with lots of flash and/or really >>> do not want a false positive to occur). >>> >>> Will >>>> On Jul 26, 2018, at 5:10 AM, marko kiiskila wrote: >>>> >>>> Hi, >>>> >>>> there’s few issues with FCB which I need to fix. >>>> >>>> 1) Compressing flash sector in the middle of write. >>>> Currently the cycle of operation is expected to be the following: >>>> fcb_append() -> get offset to write data to >>>> flash_area_write() -> write data >>>> fcb_append_finish() -> writes CRC etc >>>> >>>> This is not too great if the location returned by fcb_append() gets >>>> rotated to be >>>> scratch area before fcb_append_finish() is called. Which is quite possible >>>> if you’re using FCB to store logs, and data comes from different tasks. >>>> >>>> 2) CRC is 1 byte only. It’s ok for short config entries, but for longer >>>> things >>>> (log entries) is not good enough. >>>> >>>> To fix 1 I was going to add linkage to fcb_entry such that FCB can track >>>> of incomplete writes, and add a write routine which should be used when >>>> doing the write. >>>> >>>> Issue 2 is a little bit more cumbersome. I want to be able to at least >>>> allow backwards compatibility, where code figures out from data in >>>> the flash which CRC format is there. But then be able to switch to >>>> 16 bit CRC format as new flash areas are written. Or keep using >>>> the old format, because you want to do downgrade to old SW version >>>> if necessary. >>>> >>>> So that’s what I’m currently thinking of trying to achieve. Let me know >>>> if you guys have other things to take into consideration here. >>> >>

Re: FCB revamp

2018-07-26 Thread marko kiiskila

> On Jul 26, 2018, at 3:10 PM, marko kiiskila wrote: > > Hi, > > there’s few issues with FCB which I need to fix. > > 1) Compressing flash sector in the middle of write. > Currently the cycle of operation is expected to be the following: > fcb_append() -> get offset to write data to > flash_area_write() -> write data > fcb_append_finish() -> writes CRC etc > > This is not too great if the location returned by fcb_append() gets rotated > to be > scratch area before fcb_append_finish() is called. Which is quite possible > if you’re using FCB to store logs, and data comes from different tasks. Note that this is not an issue when storing config in FCB; locking within config module ascertains that this will not happen. But for log_fcb this race condition exists. Which makes me lean towards not having the write tracking inside FCB, but rather at a user of FCB. I.e. with logs it would cancel writes where target is an area in the flash which was erased from underneath. > > 2) CRC is 1 byte only. It’s ok for short config entries, but for longer things > (log entries) is not good enough. > > To fix 1 I was going to add linkage to fcb_entry such that FCB can track > of incomplete writes, and add a write routine which should be used when > doing the write. > > Issue 2 is a little bit more cumbersome. I want to be able to at least > allow backwards compatibility, where code figures out from data in > the flash which CRC format is there. But then be able to switch to > 16 bit CRC format as new flash areas are written. Or keep using > the old format, because you want to do downgrade to old SW version > if necessary. > > So that’s what I’m currently thinking of trying to achieve. Let me know > if you guys have other things to take into consideration here.

FCB revamp

2018-07-26 Thread marko kiiskila

Hi, there’s few issues with FCB which I need to fix. 1) Compressing flash sector in the middle of write. Currently the cycle of operation is expected to be the following: fcb_append() -> get offset to write data to flash_area_write() -> write data fcb_append_finish() -> writes CRC etc This is not too great if the location returned by fcb_append() gets rotated to be scratch area before fcb_append_finish() is called. Which is quite possible if you’re using FCB to store logs, and data comes from different tasks. 2) CRC is 1 byte only. It’s ok for short config entries, but for longer things (log entries) is not good enough. To fix 1 I was going to add linkage to fcb_entry such that FCB can track of incomplete writes, and add a write routine which should be used when doing the write. Issue 2 is a little bit more cumbersome. I want to be able to at least allow backwards compatibility, where code figures out from data in the flash which CRC format is there. But then be able to switch to 16 bit CRC format as new flash areas are written. Or keep using the old format, because you want to do downgrade to old SW version if necessary. So that’s what I’m currently thinking of trying to achieve. Let me know if you guys have other things to take into consideration here.

Re: newtmgr fs command fails in sim

2018-07-06 Thread marko kiiskila

> On Jul 6, 2018, at 5:49 PM, Kevin Townsend wrote: > > Hi Chris, >> The error codes that come back in newtmgr responses are always (or at >> least should be) MGMT_ERR codes: >> https://github.com/apache/mynewt-core/blob/42bb5acc2f049d346c81f25e8c354bc3c6afefd4/mgmt/mgmt/include/mgmt/mgmt.h#L65 >> >> `MGMT_ERR_ENOENT` is indicated when the newtmgr command isn't recognized >> (it is also used for other conditions; seems like we should have a >> dedicated error code for "command not supported). > Thanks for the point, and the quick reply! > > Command not supported would be more helpful, yes, but not a major problem. >> Did you enable the `FS_NMGR` syscfg setting? > That was indeed the problem. I did dig through the various packages looking > at the CFG values, but didn't notice that one. Works great in the sim now > with: > > # Enable newtmgr commands. > STATS_NEWTMGR: 1 # Enable stats over newtmgr > LOG_NEWTMGR: 1# Enable log over newtmgr > CONFIG_NEWTMGR: 1 # Enable config over newtmgr > FS_NMGR: 1# Enable 'fs' access from newtmgr > > It's a shame the naming is sort of inconsistent (inner OCD self speaking), > but that's a minor detail. :P > I know what you mean. There’s other examples of the same. But then renaming these would break people’s build targets. Which is not nice :) Although I guess we could do this if we gave people enough warning.

Re: 1 Wire HAL

2018-07-03 Thread marko kiiskila

Hi Kevin, I was thinking separate packages for different implementations, and then syscfg knobs inside the respective ones. E.g. GPIO/timer and UART selection. These packages would implement the ‘1-wire’ API, and chip drivers would then depend on that API. The PJRC API is simple, which I like. Seems like a good starting point. > On Jul 3, 2018, at 3:31 PM, Kevin Townsend wrote: > > Hi Marko, > > IMHO, The PJRC lib is a sensible basis for a Mynewt 1-Wire package since it's > seen a fair amount of real-world use, and the underlying implementation could > be configured via the syscfg.yml file (timer+GPIO or something else like UART > if you have one free)? > > Kevin > > > On 03/07/18 12:07, marko kiiskila wrote: >> Sounds like a candidate for driver interface, not HAL. I agree with Miguel. >> User could pick the implementation which uses UART, or one which >> uses hal_timer with hal_gpio. >> >> However; Sam, you don’t think a generic driver interface makes sense? >> If you had driver package which implemented an API similar to this: >> One-Wire Library, https://www.pjrc.com/teensy/td_libs_OneWire.html >> <https://www.pjrc.com/teensy/td_libs_OneWire.html>, >> would you have been able to use it? >> >>> On Jul 3, 2018, at 3:11 AM, Sam Lewis wrote: >>> >>> It might be more difficult to make a generic driver for but I've had some >>> great success using a UART peripheral to read/write 1 wire devices. There's >>> a good writeup of how this works in this app note: >>> https://www.maximintegrated.com/en/app-notes/index.mvp/id/214 >>> >>> The benefit is less CPU time needed for bit banging but you need to make >>> sure your 1 wire device fits the timing constraints of your UART peripheral. >>> >>> Just thought it was worth mentioning, might be something to consider. >>> >>> Sam >>> >>> >>> >>> On Tue., 3 Jul. 2018, 6:11 am Kevin Townsend, >>> wrote: >>> >>>> Hi Miguel, >>>> >>>> Good to hear! >>>> >>>> Yeah, GPIO is the only way I've ever implemented this and I think a >>>> simple SW implementation is the way to go here. >>>> >>>> K. >>>> >>>> >>>> On 02/07/18 21:39, Miguel Azevedo wrote: >>>>> Hi Kevin, >>>>> I actually do have some code for 1-wire I implemented a few days ago. >>>>> AFAIK most MCUs we support don't have 1-wire specific hardware, so why >>>>> not have a general implementation(using hal_timer) instead of one >>>>> implementation per MCU? >>>>> >>>>> Thanks, >>>>> >>>>> Miguel >>>>> On Mon, Jul 2, 2018 at 8:10 PM Kevin Townsend >>>>> wrote: >>>>>> Is there any interest is discussing how to add Dallas 1-Wire support to >>>>>> the HAL? https://en.wikipedia.org/wiki/1-Wire >>>>>> >>>>>> It's a bit of a niche item, but an interesting protocol (you can power >>>>>> some devices from the single GPIO line) and there are some very common >>>>>> and cheap waterproof temp sensors and a few other common items that are >>>>>> only available in 1 wire. >>>>>> >>>>>> I'm happy to put one or two test drivers together for common items like >>>>>> the DS18B20 (https://www.adafruit.com/product/381) ... but the HAL >>>>>> implementation is something that should probably be discussed with the >>>>>> wider community first. >>>>>> >>>>>> Kevin >>>>>> >>>> >> >

Re: 1 Wire HAL

2018-07-03 Thread marko kiiskila

Sounds like a candidate for driver interface, not HAL. I agree with Miguel. User could pick the implementation which uses UART, or one which uses hal_timer with hal_gpio. However; Sam, you don’t think a generic driver interface makes sense? If you had driver package which implemented an API similar to this: One-Wire Library, https://www.pjrc.com/teensy/td_libs_OneWire.html , would you have been able to use it? > On Jul 3, 2018, at 3:11 AM, Sam Lewis wrote: > > It might be more difficult to make a generic driver for but I've had some > great success using a UART peripheral to read/write 1 wire devices. There's > a good writeup of how this works in this app note: > https://www.maximintegrated.com/en/app-notes/index.mvp/id/214 > > The benefit is less CPU time needed for bit banging but you need to make > sure your 1 wire device fits the timing constraints of your UART peripheral. > > Just thought it was worth mentioning, might be something to consider. > > Sam > > > > On Tue., 3 Jul. 2018, 6:11 am Kevin Townsend, > wrote: > >> Hi Miguel, >> >> Good to hear! >> >> Yeah, GPIO is the only way I've ever implemented this and I think a >> simple SW implementation is the way to go here. >> >> K. >> >> >> On 02/07/18 21:39, Miguel Azevedo wrote: >>> Hi Kevin, >>> I actually do have some code for 1-wire I implemented a few days ago. >>> AFAIK most MCUs we support don't have 1-wire specific hardware, so why >>> not have a general implementation(using hal_timer) instead of one >>> implementation per MCU? >>> >>> Thanks, >>> >>> Miguel >>> On Mon, Jul 2, 2018 at 8:10 PM Kevin Townsend >>> wrote: Is there any interest is discussing how to add Dallas 1-Wire support to the HAL? https://en.wikipedia.org/wiki/1-Wire It's a bit of a niche item, but an interesting protocol (you can power some devices from the single GPIO line) and there are some very common and cheap waterproof temp sensors and a few other common items that are only available in 1 wire. I'm happy to put one or two test drivers together for common items like the DS18B20 (https://www.adafruit.com/product/381) ... but the HAL implementation is something that should probably be discussed with the wider community first. Kevin >>> >> >>

Re: Linking of tests when app itself has a main

2018-06-27 Thread marko kiiskila

Hi René, unittest framework was developed assuming that apps themselves would not have test suites. Only individual packages/libraries. So the method you described is pretty much what you’d need to do. Or alternatively create a library out of the components you want to create unittests for. > On Jun 27, 2018, at 11:42 AM, Rene Beckmann wrote: > > Hello, > > I hope this is the right place to ask this, I'm very sorry if not. > I am currently experimenting with Apache MyNewt, have written a tiny app > (apps/simple) and created a test suite (apps/simple/test) for it. > The apps/simple/test/pkg.yml contains "apps/simple/" as pkg.deps. > The problem is that my app itself contains a main function, as well as the > test suite (guarded by #if MYNEWT_VAL(SELFTEST) ). When running "newt test > apps/simple", newt properly compiles the test, seems to find its main > function, however it happily overrides it with the one found in the main > app, so the test does not run. The test project found in the docs tests a > library, which does not contain a main function, so this is not covered. I > could help myself by using: > #if MYNEWT_VAL(SELFTEST) > #else > int main... > #endif > However, that's neither pretty nor do I believe that this is the correct > way to do it. Maybe someone can point me to something that makes newt > ignore the app's main by default? > > Regards, > René Beckmann > -- > > René Beckmann > > Student Assistant > > > http://www.itemis.de > > > itemis AG > Am Brambusch 15-24 > 44536 Lünen > > Rechtlicher Hinweis: > Amtsgericht Dortmund, HRB 20621 > Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus > Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, > Jennifer Fiorentino

Re: config id package usage

2018-06-22 Thread marko kiiskila

I’m thinking maybe we’d just malloc() that thing, if it comes from sys/config. And allow it to be set by BSP, and add that model/mfg info. Following the same model with those ones. > On Jun 22, 2018, at 10:04 AM, Jacob Rosenthal wrote: > > So now I think we just need to argue about the default serial size in the > upstream bsps. With something similar to chris's recent pr on hw_id_size > people can redefine size to whatever they want when they alter bsp, but > what should the default bsp size be? The existing id package is 64 > chars. UUID's nowadays are 128bit, ie 4 of the 32bit uicr registers on a > nordic which I guess is what Id naively argue for. How are others doing > serials these days? Is there an existing proprietary/open backend for > serial generation that we could keep in mind? I saw that bitmark thing > recently. > > > On Mon, Jun 18, 2018 at 11:31 AM marko kiiskila wrote: > >> >> >>> On Jun 16, 2018, at 9:34 AM, Jacob Rosenthal >> wrote: >>> >>> I think you're saying create a CONFIG_NVMC much like we have CONFIG_FCB >> and >>> CONFIG_NFFS >>> >>> Looking more into the config system >>> "Configuration items are stored as key-value pairs, where both the key >> and >>> the value are expected to be strings" >>> >>> Im not sure strings and config are a good fit as at least on the nrf >>> devices Im familiar with we have a total of 32 32bit registers. >> >> You would not store the key as in it’s full there, just a short key (which >> then would be expanded), followed by value. >> >> However, that’s probably too custom of a thing to make a good fit here. >> >>> So I think its more likely well have to have custom functions at the >>> bsp/mcu layer much like exsiting nrf52_hw_id.c and then something that >>> registers those into strings dynamically into the id package (again like >>> hw_id) rather than waste all the memory to duplicate the data as a >> string… >> >> Yeah, I think that would be better. We could allow that data to be filled >> in >> from BSP code (or wherever). And we should add that model & mfg >> pointers as well. This would be an improvement. >> >>> Maybe the bsp/mcu itself can just register a config like "bsp/serial", >>> "bsp/custom1" instead of us trying to infinitely extend the id package >> for >>> custom nvmic functions >> >> That, while possible, I would not use. I want to find the identifying >> pieces >> of info from the same place, regardless of BSP/MCU combo. >> >>> >>> >>> On Tue, Jun 12, 2018 at 3:47 AM marko kiiskila wrote: >>> >>>> >>>> >>>>> On Jun 12, 2018, at 8:24 AM, Jacob Rosenthal >>>> wrote: >>>>> >>>>> I dig the config id package for what it has available, but several >> things >>>>> puzzle me. >>>>> >>>>> Obviously I can fork this and make all these changes for my project, >> but >>>>> just feeling out how people are using this. >>>>> >>>>> I tend to think of the id package kind of replacing or being the source >>>> of >>>>> truth for Device Information service. >>>>> >>>>> As such I feel like were missing a model/style and manufacturer name >>>> value >>>>> in here. >>>> >>>> I think that’s true, those are often used. It started with hwid, and as >>>> people >>>> don’t want to use that as device id for their stuff, then the serial >>>> number. >>>> >>>>> >>>>> Also the serial puzzles me, Is anyone using this? It seems odd to me >> that >>>>> youd have user settable serial number.. Isnt it more likley wed burn a >>>>> serial into user registers on the micro? And on top of that its holding >>>>> 64byte array by default empty. >>>> >>>> People are using it. Whether it takes space in RAM or not could be made >>>> configurable though. >>>> >>>> What is missing is a more fine-grained access control, >>>> which would allow people access to specific operations, e.g. allow >>>> config read but prevent config writes. I would have needed this already, >>>> but haven’t had time to think what it should look like :) >>>> >>>> Updating serial number makes no sense, but you need to be able to set >>>> it at the factory. >>>> >>>>> >>>>> What if we expose id/serial to the bsp definition like we do in say >>>>> nrf52_hw_id.c and let the user populate it however they like, most >> likely >>>>> from (in this nordic case) UICR->CUSTOMER >>>> >>>> I would recommend writing a new backend to config, which reads data >>>> from UICR. As you might’ve noticed, you can specify multiple sources >>>> as a source of config. I have not verified that all the right APIs are >>>> exposed >>>> by the sys/config to allow config backend to live in a different >> package, >>>> but the intent was that you’d be able to make part of config anywhere. >>>> EEPROM has most often been brought up. >>>> >>>> >> >>

Re: OC_SERVER

2018-06-21 Thread marko kiiskila

Indeed, the address is the address of the board. I assumed you were using simulator, as your newtmgr target specified 127.0.0.1as the address? To get more output on the firmware console, you can turn on OC_DEBUG, OC_LOGGING, and set LOG_LEVEL to 0. Also do the log_register() with oic_log, similar to what slinky_oic does. This should make the OIC logs appear in the console; you can verify this with serial. > On Jun 21, 2018, at 2:07 PM, Jan Clement > wrote: > > Hello Marko, > > > OC_TRANSPORT_IP and OC_TRANSPORT_IPV4 are both set. > > The ip-adress should be the one from the board, right? I always get a > timeout. Is there a way to activate some kind of verbose output? > > I start the service by calling > > oc_main_init((oc_handler_t *)_oc_handler); > > as in the slinky_oic app, which also does not connect. > > any ideas? > > Regards, > jan > > > > Am 21.06.2018 um 22:14 schrieb marko kiiskila: >>> On Jun 21, 2018, at 10:59 AM, marko kiiskila wrote: >>> >>>> On Jun 21, 2018, at 2:19 AM, Jan Clement >>>> wrote: >>>> >>>> Hello you All, >>>> >>>> at the moment I am stuck at connecting to the oic server via newtmgr over >>>> udp. the connection works fine with serial but ip is not. >>>> >>>> I added a connection with >>>> >>>> newtmgr conn add myudp5683 type=oic_udp connstring=[127.0.0.1]:5683 >>>> >>>> the port number is from the documentation, is it the correct one? And >>>> where could i change it? >>> >>> Make sure that you have syscfg knobs OC_TRANSPORT_IP and OC_TRANSPORT_IPV4 >>> turned on. >>> >>> 5683 is the right port. There’s a define in >>> net/oic/src/port/mynewt/ip4_adaptor.c, if you need to change it. >>> Making it adjustable with syscfg is ok, if you want to create a PR. >>> >> BTW, here are profiles I’m using for communicating with the server over >> loopback interface. >> [marko@IsMyLaptop:~]$ newtmgr conn show v4_lo >> Connection profiles: >> v4_lo: type=oic_udp, connstring='[127.0.0.1]:5683' >> [marko@IsMyLaptop:~]$ newtmgr conn show v6_lo >> Connection profiles: >> v6_lo: type=oic_udp, connstring='[::1]:5683'

Re: OC_SERVER

2018-06-21 Thread marko kiiskila

> On Jun 21, 2018, at 10:59 AM, marko kiiskila wrote: > >> On Jun 21, 2018, at 2:19 AM, Jan Clement >> wrote: >> >> Hello you All, >> >> at the moment I am stuck at connecting to the oic server via newtmgr over >> udp. the connection works fine with serial but ip is not. >> >> I added a connection with >> >> newtmgr conn add myudp5683 type=oic_udp connstring=[127.0.0.1]:5683 >> >> the port number is from the documentation, is it the correct one? And where >> could i change it? > > Make sure that you have syscfg knobs OC_TRANSPORT_IP and OC_TRANSPORT_IPV4 > turned on. > > 5683 is the right port. There’s a define in > net/oic/src/port/mynewt/ip4_adaptor.c, if you need to change it. > Making it adjustable with syscfg is ok, if you want to create a PR. > BTW, here are profiles I’m using for communicating with the server over loopback interface. [marko@IsMyLaptop:~]$ newtmgr conn show v4_lo Connection profiles: v4_lo: type=oic_udp, connstring='[127.0.0.1]:5683' [marko@IsMyLaptop:~]$ newtmgr conn show v6_lo Connection profiles: v6_lo: type=oic_udp, connstring='[::1]:5683'

Re: config id package usage

2018-06-18 Thread marko kiiskila

> On Jun 16, 2018, at 9:34 AM, Jacob Rosenthal wrote: > > I think you're saying create a CONFIG_NVMC much like we have CONFIG_FCB and > CONFIG_NFFS > > Looking more into the config system > "Configuration items are stored as key-value pairs, where both the key and > the value are expected to be strings" > > Im not sure strings and config are a good fit as at least on the nrf > devices Im familiar with we have a total of 32 32bit registers. You would not store the key as in it’s full there, just a short key (which then would be expanded), followed by value. However, that’s probably too custom of a thing to make a good fit here. > So I think its more likely well have to have custom functions at the > bsp/mcu layer much like exsiting nrf52_hw_id.c and then something that > registers those into strings dynamically into the id package (again like > hw_id) rather than waste all the memory to duplicate the data as a string… Yeah, I think that would be better. We could allow that data to be filled in from BSP code (or wherever). And we should add that model & mfg pointers as well. This would be an improvement. > Maybe the bsp/mcu itself can just register a config like "bsp/serial", > "bsp/custom1" instead of us trying to infinitely extend the id package for > custom nvmic functions That, while possible, I would not use. I want to find the identifying pieces of info from the same place, regardless of BSP/MCU combo. > > > On Tue, Jun 12, 2018 at 3:47 AM marko kiiskila wrote: > >> >> >>> On Jun 12, 2018, at 8:24 AM, Jacob Rosenthal >> wrote: >>> >>> I dig the config id package for what it has available, but several things >>> puzzle me. >>> >>> Obviously I can fork this and make all these changes for my project, but >>> just feeling out how people are using this. >>> >>> I tend to think of the id package kind of replacing or being the source >> of >>> truth for Device Information service. >>> >>> As such I feel like were missing a model/style and manufacturer name >> value >>> in here. >> >> I think that’s true, those are often used. It started with hwid, and as >> people >> don’t want to use that as device id for their stuff, then the serial >> number. >> >>> >>> Also the serial puzzles me, Is anyone using this? It seems odd to me that >>> youd have user settable serial number.. Isnt it more likley wed burn a >>> serial into user registers on the micro? And on top of that its holding >>> 64byte array by default empty. >> >> People are using it. Whether it takes space in RAM or not could be made >> configurable though. >> >> What is missing is a more fine-grained access control, >> which would allow people access to specific operations, e.g. allow >> config read but prevent config writes. I would have needed this already, >> but haven’t had time to think what it should look like :) >> >> Updating serial number makes no sense, but you need to be able to set >> it at the factory. >> >>> >>> What if we expose id/serial to the bsp definition like we do in say >>> nrf52_hw_id.c and let the user populate it however they like, most likely >>> from (in this nordic case) UICR->CUSTOMER >> >> I would recommend writing a new backend to config, which reads data >> from UICR. As you might’ve noticed, you can specify multiple sources >> as a source of config. I have not verified that all the right APIs are >> exposed >> by the sys/config to allow config backend to live in a different package, >> but the intent was that you’d be able to make part of config anywhere. >> EEPROM has most often been brought up. >> >>

Re: [DISCUSS] Release Apache Mynewt 1.4.0-rc1 and Apache NimBLE 1.0.0-rc1

2018-06-08 Thread marko kiiskila

SHA files in the release directory should identify the type of checksum calculated, i.e. should end with .sha512, not with .sha. Otherwise, checksums and signatures verify ok. > On Jun 8, 2018, at 11:44 AM, Szymon Janc wrote: > > Hi Jacob, > > On Thursday, 7 June 2018 18:09:44 CEST Jacob Rosenthal wrote: >> Just scanning through PRs for a few more notables: >> TLC5971 ADP5061, ms5840, lis2dw12, sx1272, BMA2XX, debounce >> blinker, easing, button >> >> On Thu, Jun 7, 2018 at 9:02 AM Jacob Rosenthal >> >> wrote: >>> A few major changes I didnt see in the RN >>> nordic adc drivers brought back in >>> nordic pwm driver >>> drv2605 driver (erm and lra) >>> >>> On Wed, Jun 6, 2018 at 12:45 PM Szymon Janc wrote: Hi all, This thread is for any and all discussion regarding the release of Apache Mynewt 1.4.0 and Apache NimBLE 1.0.0. All feedback is welcome. > > Thanks for updating Release Notes. > > -- > pozdrawiam > Szymon Janc > >

Re: rfc (stm32) pin descriptor, AF encoding

2018-05-14 Thread marko kiiskila

Quite clever, I like this idea. This will allow us to simplify all peripheral structures for STM32s a bit. > On May 14, 2018, at 2:32 PM, Fabio Utzig wrote: > > I like the proposed changes! > > Fabio > > On Sun, May 13, 2018, at 1:02 AM, markus wrote: >> For the pwm driver I took a stab at a more holistic pin descriptor and >> wanted to solicit feedback and opinions. >> >> The core is in mcu.h: >> https://github.com/mlampert/mynewt-core/blob/feature/stm32-pwm-enabled/hw/mcu/stm/stm32f7xx/include/mcu/mcu.h >> >> Instead of using a struct data type I decided to go with bit >> encoding and macros, for the sole reason of API compatibility. A pin >> descriptor with an AF assignment can be passed to any API that accepts >> a pin (as long as the type is at least a uint16_t). >> >> For instance, it allows us to fold the functionality of >> hal_gpio_init_af into hal_gpio_init_in and hal_gpio_init_out and >> eliminate the stm specific api additions. >> >> Assuming the API allows a 32-bit pin type the encoding can be expanded >> to pin speed, strength, logic standard (although I haven't seen that in >> any of the ARMs - yet) >> >> The other advantage of a bit encoding is that the entire pin descriptor >> can be defined in a single constant: >> >> /* AF=2 of PB7 */ >> #define PWM_PIN 0x2017 >> And if the GPIO pin is already defined: >> https://github.com/mlampert/mynewt-core/blob/feature/stm32-pwm-enabled/apps/pwm_test/src/main.c#L27 >> >> Internal use currently looks something like this: >> https://github.com/mlampert/mynewt-core/blob/feature/stm32-pwm-enabled/hw/drivers/pwm/pwm_stm32/src/pwm_stm32.c#L289 >> >> with the (stm) hal_gpio refactoring mentioned above that line would >> simple become: >> if (hal_gpio_init_out(cfg->pin, 0)) { >> >> I've only implemented this for the stm32f7 in order to reduce the >> refactoring effort if we want to go a different direction. >> >> Thoughts? Comments? ...

Re: Console Read Issue

2018-04-21 Thread marko kiiskila

Console itself uses uart driver interface. Other examples you can use mgmt/newtmgr/transport/nmgr_uart/src/nmgr_uart.c https://github.com/runtimeco/mynewt_arduino_zero/blob/master/libs/espduino/src/espduino.c boot/boot_serial/src/boot_uart.c the air quality sensor tutorial: http://mynewt.apache.org/latest/os/tutorials/air_quality_sensor/#air-quality-sensor-project <http://mynewt.apache.org/latest/os/tutorials/air_quality_sensor/#air-quality-sensor-project> > On Apr 21, 2018, at 9:06 PM, Aditya Xavier <adityaxav...@me.com> wrote: > > I went through HAL UART APIs however am not able to understand how to receive > UART data. > > Is there any example out there which would tell me how to use the relevant > functions (hal_uart_start_rx ? ) so that we can receive binary data over UART > ? > > Any help is much appreciated. > > Thanks, > Aditya Xavier. > > >> On 21-Apr-2018, at 8:44 PM, Aditya Xavier <adityaxav...@me.com> wrote: >> >> Could you specifically point how to use the uart driver interface? >> >> I’ll look at how to base64 encode as well.. >> >> Sent from my iPhone >> >>> On 21-Apr-2018, at 8:17 PM, marko kiiskila <ma...@runtime.io> wrote: >>> >>> Console is for printable characters only, not meant for binary data. >>> You should go straight to uart driver interface, or base64 encode your CBOR. >>> >>>> On Apr 21, 2018, at 4:30 PM, Aditya Xavier <adityaxav...@me.com> wrote: >>>> >>>> Hi Mynewt Team, >>>> >>>> It seems UART is not capable of handling non-asci characters and instead >>>> enters new line on occurrence of one. >>>> >>>> Thanks, >>>> Aditya Xavier. >>>> >>>> >>>>> On 21-Apr-2018, at 5:28 PM, Aditya Xavier <adityaxav...@me.com> wrote: >>>>> >>>>> Hi Mynewt Team, >>>>> >>>>> Am facing issues with console_read API. >>>>> >>>>> I have a MCU sending CBOR data to nRF over UART. >>>>> >>>>> Console_read works perfect when receiving data from USB->Serial adapter >>>>> (Computer) & RTT. >>>>> >>>>> Console_read give multiple hits ( i.e. multiple times it would reach >>>>> either /*Got Full line - break …*/ or /*Do some work…*/ >>>>> >>>>> How do I fix such a situation. >>>>> >>>>> Thanks, >>>>> Aditya Xavier. >>>>> >>>>> >>>>> #define MAX_INPUT 128 >>>>> >>>>> static void >>>>> read_function(void *arg) >>>>> { >>>>> char buf[MAX_INPUT]; >>>>> int rc; >>>>> int full_line; >>>>> int off; >>>>> >>>>> off = 0; >>>>> while (1) { >>>>>rc = console_read(buf + off, MAX_INPUT - off, _line); >>>>>if (rc <= 0 && !full_line) { >>>>>continue; >>>>>} >>>>>off += rc; >>>>>if (!full_line) { >>>>>if (off == MAX_INPUT) { >>>>>/* >>>>> * Full line, no newline yet. Reset the input buffer. >>>>> */ >>>>>off = 0; >>>>>} >>>>>continue; >>>>>} >>>>>/* Got full line - break out of the loop and process the input data */ >>>>>break; >>>>> } >>>>> >>>>> /* Process the input line here */ >>>>> >>>>> >>>>> return; >>>>> } >>>>> static void myapp_process_input(struct os_event *ev); >>>>> >>>>> static struct os_eventq avail_queue; >>>>> >>>>> static struct console_input myapp_console_buf; >>>>> >>>>> static struct os_event myapp_console_event = { >>>>> .ev_cb = myapp_process_input, >>>>> .ev_arg = _console_buf >>>>> }; >>>>> >>>>> /* Event callback to process a line of input from console. */ >>>>> static void >>>>> myapp_process_input(struct os_event *ev) >>>>> { >>>>> char *line; >>>>> struct console_input *input; >>>>> >>>>> input = ev->ev_arg; >>>>> assert (input != NULL); >>>>> >>>>> line = input->line; >>>>> /* Do some work with line */ >>>>> >>>>> /* Done processing line. Add the event back to the avail_queue */ >>>>> os_eventq_put(_queue, ev); >>>>> return; >>>>> } >>>>> >>>>> static void >>>>> myapp_init(void) >>>>> { >>>>> os_eventq_init(_queue); >>>>> os_eventq_put(_queue, _console_event); >>>>> >>>>> console_set_queues(_queue, os_eventq_dflt_get()); >>>>> } >>>>> >>>> >>> >

Re: Debugging the mynewt bootloader

2018-04-19 Thread marko kiiskila

Just reset the target; it’ll restart from the beginning. Presumably the bootloader will do the same work every time it runs? ‘mon reset’ is what you’d issue from gdb prompt. You can enable console within bootloader, if absolutely necessary. Replace the console/stub package with console/full, and call sysinit() from your main. Note that bootloader size might increase it’s size such that you’ll need to shift any subsequent data in the flash further away. Hope that helps, M > On Apr 19, 2018, at 5:14 PM, Niall Begley wrote: > > Hi everyone, I'm new to mynewt (and RTOS's in general) and I'm looking to > do something that I think is a little outside the scope of a lot of the > documentation on the mynewt site (as far as I can tell) and I was hoping to > get some guidance. > > Basically, I'm interested in modifying the existing digital signature > systems in place for secure boot loading, but I'm running into a problem > actually debugging the changes I'm making. When I run "newt run" on my > bootloader, GDB appears to only load when the digital signature is already > halfway through validation. For example, here is what the stack looks like > immediately after breaking into GDB when the bootloader is set to perform > RSA signature validation: > > #0 memset (dst=0x80002d28, c=c@entry=0, n=) at > repos/apache-mynewt-core/libc/baselibc/src/memset.c:24 > #1 0x200025ca in mbedtls_mpi_lset (X=X@entry=0x80002fd0, z=z@entry=0) at > repos/apache-mynewt-core/crypto/mbedtls/src/bignum.c:295 > #2 0x20002f0c in mbedtls_mpi_mul_mpi (X=X@entry=0x80002fd0, A=0x80002f54, > A@entry=0x80002fd0, B=B@entry=0x80002f84) >at repos/apache-mynewt-core/crypto/mbedtls/src/bignum.c:1193 > #3 0x20002f5a in mbedtls_mpi_mul_int (X=X@entry=0x80002fd0, > A=A@entry=0x80002fd0, > b=) >at repos/apache-mynewt-core/crypto/mbedtls/src/bignum.c:1220 > #4 0x200031e4 in mbedtls_mpi_div_mpi (Q=Q@entry=0x0, R=R@entry=0x80003694, > A=A@entry=0x80003694, B=B@entry=0x80003cec) >at repos/apache-mynewt-core/crypto/mbedtls/src/bignum.c:1388 > #5 0x20003320 in mbedtls_mpi_mod_mpi (R=R@entry=0x80003694, > A=A@entry=0x80003694, > B=B@entry=0x80003cec) >at repos/apache-mynewt-core/crypto/mbedtls/src/bignum.c:1460 > #6 0x20003648 in mbedtls_mpi_exp_mod (X=X@entry=0x800036e4, > A=A@entry=0x800036e4, > E=E@entry=0x80003cf8, N=N@entry=0x80003cec, >_RR=_RR@entry=0x80003d4c) at > repos/apache-mynewt-core/crypto/mbedtls/src/bignum.c:1662 > #7 0x20003a00 in mbedtls_rsa_public (ctx=ctx@entry=0x80003ce4, >input=input@entry=0x80003e2c > "\002\005\256\024\350R\fV\214\207(\222\246>\016j\222t\200d2V\327\265h9F\005 > \305\030\312t\255\357\b\024\203\020C)Ң\f!\031\024\203\035*b\220b\f!\031N\225\265\356\061F2\232\016|\024\203\035*\203\230\327\301H1\004", >output=output@entry=0x80003714 "\n\001") at > repos/apache-mynewt-core/crypto/mbedtls/src/rsa.c:312 > #8 0x20001946 in bootutil_cmp_rsasig ( >sig=0x80003e2c > "\002\005\256\024\350R\fV\214\207(\222\246>\016j\222t\200d2V\327\265h9F\005 > \305\030\312t\255\357\b\024\203\020C)Ң\f!\031\024\203\035*b\220b\f!\031N\225\265\356\061F2\232\016|\024\203\035*\203\230\327\301H1\004", > hlen=32, >hash=0x80003e0c > "u\362~\202\361\245\"\206\204\370aD\241JC\304#\352\202Ҫ\247\216yA)\002\341\071wNN\002\005\256\024\350R\fV\214\207(\222\246>\016j\222t\200d2V\327\265h9F\005 > \305\030\312t\255\357\b\024\203\020C)Ң\f!\031\024\203\035*b\220b\f!\031N\225\265\356\061F2\232\016|\024\203\035*\203\230\327\301H1\004", > ctx=0x80003ce4) at repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c:91 > #9 bootutil_verify_sig ( >hash=hash@entry=0x80003e0c > "u\362~\202\361\245\"\206\204\370aD\241JC\304#\352\202Ҫ\247\216yA)\002\341\071wNN\002\005\256\024\350R\fV\214\207(\222\246>\016j\222t\200d2V\327\265h9F\005 > \305\030\312t\255\357\b\024\203\020C)Ң\f!\031\024\203\035*b\220b\f!\031N\225\265\356\061F2\232\016|\024\203\035*\203\230\327\301H1\004", > hlen=hlen@entry=32, >sig=sig@entry=0x80003e2c > "\002\005\256\024\350R\fV\214\207(\222\246>\016j\222t\200d2V\327\265h9F\005 > \305\030\312t\255\357\b\024\203\020C)Ң\f!\031\024\203\035*b\220b\f!\031N\225\265\356\061F2\232\016|\024\203\035*\203\230\327\301H1\004", >slen=slen@entry=256, key_id=) at > repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c:145 > #10 0x20001842 in bootutil_img_validate (hdr=hdr@entry=0x87c4 > , fap=fap@entry=0x20005e84 , >tmp_buf=, tmp_buf_sz=tmp_buf_sz@entry=256, > seed=seed@entry=0x0, seed_len=seed_len@entry=0, >out_hash=out_hash@entry=0x0) at > repos/apache-mynewt-core/boot/bootutil/src/image_validate.c:215 > #11 0x2e2e in boot_image_check (fap=0x20005e84 , > hdr=0x87c4 ) >at repos/apache-mynewt-core/boot/bootutil/src/loader.c:518 > #12 boot_validate_slot (slot=slot@entry=0) at > repos/apache-mynewt-core/boot/bootutil/src/loader.c:576 > #13 0x200011b4 in boot_go (rsp=rsp@entry=0x80003fd4) at >

Re: Retained Register Interface (also, hi!)

2018-04-03 Thread marko kiiskila

Hi Alvaro, I’d recommend a new API in HAL. One where register contents will survive reset, depending on the type of reset. Have #define HAL_RETAIN_REG_MAX XXX in some MCU specific header file. And then in hal/hal_retain_reg.h #ifnfdef HAL_RETAIN_REG_MAX #define HAL_RETAIN_REG_MAX 0 #endif void hal_retain_reg_write(unsigned int reg, uint32_t val); uint32_t hal_retain_reg_read(unsigned int reg); HAL_RETAIN_REG_MAX would presumably be 2 for nrf52, and a little bit higher for STMs. For platforms which don’t have peripheral supporting this kind of storage, you can carve out space from RAM by reserving the space within linker script. hal_retain is a bit long as a prefix, though :) > On Apr 3, 2018, at 6:36 PM, Alvaro Prieto wrote: > > Hello, > > My name is Alvaro. I'm a firmware/hardware engineer and I've been playing > with mynewt at home and at work for a few months now. I mostly hang out in > the mynewt slack, but I've been advised to come here for hal and other > source change discussions. > > The one today has to deal with a hal friendly way to access retained > registers. By that, I mean registers that survive a soft reset. > (NRF_POWER->GPREGRET on the NRF series). > My question is: How do we implement this? > > For background, my goal is to enter the serial bootloader without > necessarily using the boot pin, so: > 1. Set magic value in retained register > 2. Call NVIC_SystemReset() > 3. Bootloader sees magic value, clears it, and enters bootloader > > While this is easy to do by just writing to the NRF_POWER->GPREGRET > register, it doesn't really for for any other platforms. The STM series has > the RTC backup registers, but other platforms might not support it. > > Should I add retain register read/write functions to hal_system or should I > add a new hal_retained_reg. > > Looking forward to getting this working :D > > Cheers, > > Alvaro

Re: Move driver _shell_init into driver pkg.init instead of app main

2018-03-01 Thread marko kiiskila

+1 on using sysinit > On Mar 1, 2018, at 6:18 PM, Jacob Rosenthal wrote: > > shell_init in the app feels odd. > https://github.com/apache/mynewt-core/blob/master/apps/sensors_test/src/main.c#L411 > > It feels like they should be down in the drivers pkg.init, especially > theyre defined down in the driver's syscfg > https://github.com/apache/mynewt-core/blob/master/hw/drivers/drv2605/syscfg.yml#L21 > > My ideal world would probably be something conditional like > pkg.init.DRV2605_CLI: > drv2605_shell_init 501 > > but that would need newt tool changes I presume. > > Uglier, but we could make some new second init function which does #ifdef > and calls drv2605_shell_init > > pkg.init: > drv2605_init_thesecond > > Thoughts (especially from vipul)

Re: JSON Encoding and Decoding

2018-02-28 Thread marko kiiskila

> On Feb 28, 2018, at 10:10 AM, Aditya Xavier <adityaxav...@me.com> wrote: > > Yes, that was derp from my end. > > Any clue on how to encode the JSON structure I mentioned ? > > Is this method correct ? You need to initialize the encoder; it needs to be told where to write the encoded data. Specifically, you need to at least fill in je_write function pointer. This is who’ll get the stream of encoded data. Take a look at unit test @ encoding/json/test/src/testcases/json_simple_encode.c Otherwise it looks pretty good, based on my cursory inspection. > > struct json_encoder *encoder, *module; > struct json_value data; > > memset(, 0, sizeof(encoder)); > memset(, 0, sizeof(module)); > > json_encode_object_start(encoder); > > JSON_VALUE_INT(, 1); > json_encode_object_entry(encoder, “name1", ); > > JSON_VALUE_STRING(, “value2"); > json_encode_object_entry(encoder, “name2", ); > > json_encode_array_name(encoder, “name3"); > json_encode_array_start(encoder); > > if(getType){ > json_encode_object_start(module); > > JSON_VALUE_INT(, 4); > json_encode_object_entry(module, “name4", ); > > JSON_VALUE_INT(, 5); > json_encode_object_entry(module, “name5", ); > > json_encode_object_finish(module); > } > > json_encode_array_finish(encoder); > json_encode_object_finish(encoder); > > > >> On 28-Feb-2018, at 1:18 PM, marko kiiskila <ma...@runtime.io> wrote: >> >> Hi Aditya, >> >>> On Feb 28, 2018, at 9:26 AM, Aditya Xavier <adityaxav...@me.com> wrote: >>> >>> HI Mynewt Team, >>> >>> Wanted some assistance on how to encode and decode the following JSON >>> string. >>> >>> {“name1":1,”name2”:"value2”,"name3":[{“name4":1,”name5":5}]} >>> >>> Because of sparse documentation, I used the Test sample; however am >>> stuck with encoding an array of objects. >>> >> >> … >> >>> >>> I followed the example provided at >>> https://mynewt.apache.org/latest/os/modules/json/json_encode_object_entry >>> <https://mynewt.apache.org/latest/os/modules/json/json_encode_object_entry> >>> >>> And it gives me error :- >>> error: implicit declaration of function 'json_encode_object_start' >>> >>> Thanks, >>> Aditya Xavier. >> >> you need to #include to see function/macro declarations. >> >

Re: JSON Encoding and Decoding

2018-02-27 Thread marko kiiskila

Hi Aditya, > On Feb 28, 2018, at 9:26 AM, Aditya Xavier wrote: > > HI Mynewt Team, > > Wanted some assistance on how to encode and decode the following JSON > string. > > {“name1":1,”name2”:"value2”,"name3":[{“name4":1,”name5":5}]} > > Because of sparse documentation, I used the Test sample; however am > stuck with encoding an array of objects. > … > > I followed the example provided at > https://mynewt.apache.org/latest/os/modules/json/json_encode_object_entry > > > And it gives me error :- > error: implicit declaration of function 'json_encode_object_start' > > Thanks, > Aditya Xavier. you need to #include to see function/macro declarations.

Re: mynewt OS Shell over BLE?

2017-12-09 Thread marko kiiskila

So one idea would be to use the UART service for BLE. We don’t have this, but I’d like us to. I think I’ve mentioned this earlier, but there have not been takers to implement this yet. UART service which is actually console backend. It’s sort of a standard service, so this might show up as a tty on Linux side. If not, I’m sure a kernel module could make it so. Or even a user land program which pipes between BLE and a pty. I’m sure there would be users for this. Any takers? ;) > On Dec 9, 2017, at 8:49 PM, Carl Turner wrote: > > I've followed the mynewt sensors tutorial and it's working well. :-) I > managed to augment the code to communicate with a couple of BME sensors via > I2C. The shell is pretty handy for development. I've been accessing the > shell through the serial port that appears when I have the nrf52 dev kit > connected via USB. > > I was wondering if there is a way to access the mynewt OS Shell over BLE > from a Linux computer? > > Thanks, > > Carl

Re: newt load hang

2017-12-07 Thread marko kiiskila

> On Dec 6, 2017, at 11:14 AM, mostafa.ud...@gmail.com wrote: > >> Make sure that that old version of process JLinkExe is not running anymore. >> Sometimes that process fails to exit, and if itâs still there, itâs >> going to get in >> the way of ânewt loadâ/ânewt debugâ. >> >> Also, the MCU running JTAG adapter on the board might get stuck, in which >> case powering on/off will unwedge it. >> >> > > I have tried to turn on/off it didn't work. I have also make sure no JLinkExe > is running. Still no luck Next you could try running the commands invoked by newt manually; one one window start the jlink sw with GDB interface: JlinkGDBServer -device nRF52 -speed 4000 -if SWD -port -singlerun and another window start gdb arm-none-eabi-gdb bin/targets/nrf52_boot/app/apps/boot/boot.elf connect to JlinkGDBserver from gdb: target remote localhost: If this works, then turn on more debugging within download shell script. i.e. add ‘set -x’ somewhere on the top of the hw/bsp/nrf52dk/nrf52dk_download.sh, and then run ‘newt -lDEBUG load nrf52_boot’. I’m guessing you're using MacOS as your dev environment?

Re: newt load hang

2017-12-06 Thread marko kiiskila

Try running JLinkExe manually, see if that thing connects ok. I think we invoke something like this: JLinkExe -device nRF52 -speed 4000 -if SWD > On Dec 6, 2017, at 11:21 AM, mostafa.ud...@gmail.com <muddi...@odu.edu> wrote: > > > > On 2017-12-06 11:53, marko kiiskila <ma...@runtime.io > <mailto:ma...@runtime.io>> wrote: >> >>> On Dec 6, 2017, at 8:03 AM, Christopher Collins <ch...@runtime.io> wrote: >>> >>> Hi Mostafa, >>> >>> On Wed, Dec 06, 2017 at 10:45:16AM -0500, Mostafa Abdulla Uddin wrote: >>>> Hello, >>>> >>>> I have install mynewt 1.2.0 in my Mac OS 10.11.6. >>>> I am using Nordic Board >>>> nRF52 Development Kit (for nRF52832) >>>> >>>> I am trying do load blinky project with shell enable. Unfortunately, my >>>> load command paused. Note that I have erase previous image using Jlinkexe. >>>> I see it paused at following point >>> >>> Could you please run the `newt load` command again, but also specify the >>> `-v` and `-ldebug` command line switches? Then include the output in a >>> follow up email. >>> >> >> Make sure that that old version of process JLinkExe is not running anymore. >> Sometimes that process fails to exit, and if itâ€™s still there, itâ€™s >> going to get in >> the way of â€˜newt loadâ€™/â€˜newt debugâ€™. >> >> Also, the MCU running JTAG adapter on the board might get stuck, in which >> case powering on/off will unwedge it. >> >> > > I turned it on/off it didn't work. Also I have make sure no JLinkExe is > running, but no luck > > regards > Mostafa

Re: [VOTE] Release Apache Mynewt 1.3.0-rc1

2017-12-01 Thread marko kiiskila

> On Dec 1, 2017, at 1:29 PM, Christopher Collins wrote: > > On Thu, Nov 30, 2017 at 10:10:00PM -0200, Fabio Utzig wrote: > [...] >> [X] +1 Release this package >> [ ] 0 I don't feel strongly about it, but don't object >> [ ] -1 Do not release this package because... > > +1 (binding) > +1 (binding)

Re: Cannot build lora_app_shell

2017-11-29 Thread marko kiiskila

I don’t think the system is even booting properly. If you run it under debugger, can you verify that you’re not reaching main()? Here’s few things that you should look at: TIMER_4 does not exist with the BSP you’re using. So you could try adjusting LORA_MAC_TIMER_NUM to 3, and saying TIMER_3=1, instead of TIMER_4. Look for the hal timers for this BSP in hw/bsp/nrf51dk/syscfg.yml > On Nov 29, 2017, at 9:02 AM, K Dmitry wrote: > > > I've connected SX1276 with some wires but not sure if connection is good. > Also I've added debug info: > > $ newt target show > targets/nrf51lora_app >app=@apache-mynewt-core/apps/lora_app_shell >bsp=@apache-mynewt-core/hw/bsp/nrf51dk >build_profile=debug > > syscfg=BASELIBC_ASSERT_FILE_LINE=1:LORA_MAC_TIMER_NUM=4:SHELL_CMD_ARGC_MAX=20:SYSINIT_PANIC_FILE_LINE=1:SYSINIT_PANIC_MESSAGE=1:TIMER_4=1 > targets/nrf51lora_boot >app=@apache-mynewt-core/apps/boot >bsp=@apache-mynewt-core/hw/bsp/nrf51dk >build_profile=optimized > > Then build image: > > $ newt clean nrf51lora_app > $ newt build nrf51lora_app > $ newt create-image nrf51lora_app 0.0.1 > $ newt load nrf51lora_app > > Nothing has changed in UART: > > 00 ICSR:0x00421002 > 00 Assert @ 0x10e0d > 00 Unhandled interrupt (2), exception sp 0x200013d0 > 00 r0:0x r1:0x r2:0x8000 r3:0xe000ed00 > 00 r4:0x00010e0d r5:0x0044 r6:0x0008 r7:0x20002820 > 00 r8:0x r9:0x r10:0x r11:0x > 00 r12:0xf7fe lr:0x906b pc:0x81cc psr:0x81000200 > > Using gdb I got to these lines: > os_arch_os_init () at > repos/apache-mynewt-core/kernel/os/src/arch/cortex_m0/os_arch_arm.c:195 > 190 os_error_t err; > 191 int i; > 192 > 193 /* Cannot be called within an ISR */ > 194 err = OS_ERR_IN_ISR; > 195 if (__get_IPSR() == 0) { > 196 err = OS_OK; > > And a bit later: > > os_init (main_fn=0x84dd ) at > repos/apache-mynewt-core/kernel/os/src/os.c:186 > 186 assert(err == OS_OK); > (gdb) p err > $5 = OS_ERR_IN_ISR > > Not sure if this it cause or consequence.

Re: Mutex oddities with v1.0.0

2017-11-06 Thread marko kiiskila

> On Nov 6, 2017, at 5:23 PM, Jitesh Shah <jit...@liveathos.com> wrote: > > Alright, > I think I have an idea of whats going on here. > > So the structure of my code is like this -> > os_mutex_pend(); > .. trigger operation here .. > os_sem_pend(); // Wait for operation to complete. ISR calls > os_sem_release() > os_mutex_release(); > > First of all following variables from task object are shared between mutex > and semaphore implementations: t_obj, t_flags, t_lockcnt, t_prio. This > basically guarantees that one *cannot* nest mutex and semaphore operations. > Overwriting t_obj on sem_pend() basically guarantees that current task will > never be off the mutex pending list. t_obj is only used when waiting for lock, to link the tasks which are waiting for the lock. Not after lock has been obtained. Task can only sleep on one lock at a time; it’s not possible to wait for 2 simultaneously. So semaphore and mutex using the same t_obj while waiting is ok; preferable even. You can mix using semaphores and mutex. > > Secondly, I have some fundamental doubts about the semaphore implementation: > 1) os_sem_release() code has a snippet like so: > >>if (--current->t_lockcnt == 0) { >>current->t_flags &= ~OS_TASK_FLAG_LOCK_HELD; >>} > > For semaphores, (as opposed to mutexes) the task which is pending on > semaphore might NOT be the task that releases the semaphore. Thus, reducing > the "lockcnt" or adjusting the flags field of the "current" task inside > os_sem_release() doesn't make sense. What are your thoughts on this? You’re right; the bookkeeping for the flag OS_TASK_FLAG_LOCK_HELD is incorrect. However, this is only checked when os_task_remove() is called. It was added to safeguard user from deleting a task which is still holding locks. Given the nature of semaphores, we probably cannot do this for that style lock. I think we should remove that from os_sem_XXX() calls. > > Jitesh > > On Mon, Nov 6, 2017 at 4:18 PM, marko kiiskila <ma...@runtime.io> wrote: > >> I’d start by looking for memory corruption. You could try adding >> guard variables around your send_mutex(), and see if anything >> stomps on them. Another option could be to change mutex_release() to >> write something other than 0 at mu_owner, and then add a conditional >> hardware watchpoint which looks if anything tries to zero out mu_owner >> of your send_mutex. >> >> Good luck with the hunt. >> >>> On Nov 6, 2017, at 3:39 PM, will sanfilippo <wi...@runtime.io> wrote: >>> >>> Yeah, Chris is right here. I did not read the email thoroughly enough >> and if what I described happened, the owner would not be NULL. Sorry about >> that. >>> >>> So while it would explain lockcnt and level, it would not explain why >> the owner is NULL, as failing to release the mutex would have the owner set >> to something. >>> >>> >>> >>>> On Nov 6, 2017, at 3:33 PM, Christopher Collins <ch...@runtime.io> >> wrote: >>>> >>>> I agree that a mutex should never have a null owner and a nonzero level. >>>> >>>> Unfortunately, my first guess is some form of memory corruption: >>>> it seems like a null value accidentally got written to `mu_owner`. I >>>> could be missing it, but I don't see any logic error in the mutex code >>>> which could cause this. >>>> >>>> Getting to the bottom of this is probably going to be difficult, >>>> especially if it is not easy to reproduce. I don't know how valuable >>>> they are, but my two suggestions are: >>>> >>>> 1. Look at the `.lst` file that newt generates during a build to >>>> determine what object immediately follows the mutex in RAM. Maybe an >>>> errant write intended for this object is clearing the owner field. >>>> >>>> 2. Instrument the code with a bunch of asserts and logs. Maybe you can >>>> catch the problem shortly after it happens. >>>> >>>> Like I said, probably not the most helpful advice, but I don't think >>>> this is going to be an easy one to solve! >>>> >>>> Chris >>>> >>>> On Mon, Nov 06, 2017 at 03:16:06PM -0800, Jitesh Shah wrote: >>>>> Hey wil, >>>>> Are you saying that because "mu_level" is set to 1? >>>>> >>>>> It is set to 1 because the last call to os_mutex_release() failed on >>>>> account of "mu_owner" not matching. Thus, t

Re: Mutex oddities with v1.0.0

2017-11-06 Thread marko kiiskila

I’d start by looking for memory corruption. You could try adding guard variables around your send_mutex(), and see if anything stomps on them. Another option could be to change mutex_release() to write something other than 0 at mu_owner, and then add a conditional hardware watchpoint which looks if anything tries to zero out mu_owner of your send_mutex. Good luck with the hunt. > On Nov 6, 2017, at 3:39 PM, will sanfilippo wrote: > > Yeah, Chris is right here. I did not read the email thoroughly enough and if > what I described happened, the owner would not be NULL. Sorry about that. > > So while it would explain lockcnt and level, it would not explain why the > owner is NULL, as failing to release the mutex would have the owner set to > something. > > > >> On Nov 6, 2017, at 3:33 PM, Christopher Collins wrote: >> >> I agree that a mutex should never have a null owner and a nonzero level. >> >> Unfortunately, my first guess is some form of memory corruption: >> it seems like a null value accidentally got written to `mu_owner`. I >> could be missing it, but I don't see any logic error in the mutex code >> which could cause this. >> >> Getting to the bottom of this is probably going to be difficult, >> especially if it is not easy to reproduce. I don't know how valuable >> they are, but my two suggestions are: >> >> 1. Look at the `.lst` file that newt generates during a build to >> determine what object immediately follows the mutex in RAM. Maybe an >> errant write intended for this object is clearing the owner field. >> >> 2. Instrument the code with a bunch of asserts and logs. Maybe you can >> catch the problem shortly after it happens. >> >> Like I said, probably not the most helpful advice, but I don't think >> this is going to be an easy one to solve! >> >> Chris >> >> On Mon, Nov 06, 2017 at 03:16:06PM -0800, Jitesh Shah wrote: >>> Hey wil, >>> Are you saying that because "mu_level" is set to 1? >>> >>> It is set to 1 because the last call to os_mutex_release() failed on >>> account of "mu_owner" not matching. Thus, the task that got the mutex >>> failed to release it. That explains t_lockcnt and mu_level, right? >>> >>> Jitesh >>> >>> On Mon, Nov 6, 2017 at 7:56 AM, will sanfilippo wrote: >>> What this looks like to me is that there was a nested pend without the same number of releases. Maybe some path out of some code that is rarely hit where a mutex is granted but not released? Just a guess... > On Nov 5, 2017, at 8:26 PM, Jitesh Shah wrote: > > Hey Guys, > I am running v1.0.0 branch (0db6321a75deda126943aa187842da6b977cd1c1). > Seeing some strange mutex behaviour. > > So once in a bazillion times, a mutex fails to release. Here is how the > structure looks like when it fails: > >> (gdb) p/x send_mutex >> $1 = {mu_head = {slh_first = 0x0}, _pad = 0x0, mu_prio = 0x1, mu_level = >> 0x1, mu_owner = 0x0} > > > Why is mu_owner set to 0? That causes the os_mutex_release call to fail > since the current task doesn't match the owner task anymore. > > The task which holds the mutex looks like this: > >> (gdb) p/x cent_task >> $3 = {t_stackptr = 0x20008a28, t_stacktop = 0x20008ac8, t_stacksize = >> 0x80, t_taskid = 0x6, t_prio = 0x1, t_state = 0x1, t_flags = 0x10, >> t_lockcnt = 0x1, t_pad = 0x0, >> t_name = 0x22378, t_func = 0x90ad, t_arg = 0x0, t_obj = 0x0, >> t_sanity_check = {sc_checkin_last = 0x0, sc_checkin_itvl = 0x0, sc_func = >> 0x0, sc_arg = 0x0, sc_next = { >>sle_next = 0x0}}, t_next_wakeup = 0x0, t_run_time = 0x0, >> t_ctx_sw_cnt = 0x213d, t_os_task_list = {stqe_next = 0x0}, t_os_list = >> {tqe_next = 0x20001338, >> tqe_prev = 0x21a8}, t_obj_list = {sle_next = 0x0}} > > > Comparing t_prio and mu_prio, this confirms that this task is indeed > holding the mutex (no other task is waiting on the mutex). > > What can happen that set mu_owner to 0? My original theory was that if a > mutex_pend was called from an interrupt context, mu_owner would be 0. But > in this case, the only task that is calling mutex is running an eventq, so > that is unlikely. > > Any ideas? > > Jitesh > > -- > This email including attachments contains Mad Apparel, Inc. DBA Athos > privileged, confidential, and proprietary information solely for the use > for the addressed recipients. If you are not the intended recipient, please > be aware that any review, disclosure, copying, distribution, or use of the > contents of this message is strictly prohibited. If you have received this > in error, please delete it immediately and notify the sender. All rights > reserved by Mad Apparel, Inc. 2012. The information contained herein is the >

Re: [mynewt-newtmgr] 01/01: Merge pull request #46 from mkiiskila/lora

2017-10-27 Thread marko kiiskila

Probably should’ve mentioned: this code does do fragmentation/reassembly to fit into lora frames (which might be quite limited). > On Oct 27, 2017, at 1:40 PM, marko kiiskila <ma...@runtime.io> wrote: > > Hi, > > added CoAP over LoRa option when running on Multitech gateway. > > root@mtcdt:~# ./newtmgr conn show mt > Connection profiles: > mt: type=oic_mtech, connstring='' > root@mtcdt:~# ./newtmgr -c mt -t 120 --name 00-13-50-04-04-50-13-00 taskstat > > task pri tid runtime cswstksz stkuse last_checkin > next_checkin > idle 255 0 481470 4337 64 3100 >loramac 0 2 551 3699 256 8700 > main 127 1 58 1386 1024 46900 > root@mtcdt:~# ./newtmgr -c mt -t 120 --name 00-13-50-04-04-50-13-00 res get > public /oic/res > ^Croot@mtcdt:~# ./newtmgr -c mt -t 120 --name 00-13-50-04-04-50-13-00 res get > puic /oic/d > ^Croot@mtcdt:~# ./newtmgr -c mt -t 120 --name 00-13-50-04-04-50-13-00 res get > puic d > Error: NotFound (132) > root@mtcdt:~# ./newtmgr -c mt -t 120 --name 00-13-50-04-04-50-13-00 res get > public /oic/p > /oic/p > map[mnos:MyNewt rt:[oic.wk.p] if:[oic.if.r oic.if.baseline] p:5 > pi:fd0edd1a-5de2-44d2-400f-74b9369db40d mnmn:MyNewt] > root@mtcdt:~# ./newtmgr -c mt -t 120 --name 00-13-50-04-04-50-13-00 > --connextra="segsz=33,confirmedtx=true" image list > Images: > slot=0 > version: 3.0.0 > bootable: true > flags: active confirmed > hash: 2fb91d83abd0ea3c3a76c78462ccc287de60d83300a66c153af4a666adce6862 > Split status: N/A (0) > root@mtcdt:~# lora-query --node-list > Net Addr Dev EUI Class JoinedSeq Num >Up Down 1st 2nd Dropped RSSI min max avg SNR min > max avg > 00:00:00:01 00-13-50-00-00-50-13-00 A 2017-06-23T00:20:40Z1 > 00000 0 0 00 > 0 0 > 00:00:00:02 00-13-50-02-02-50-13-00 A 2017-10-10T20:06:51Z 10 > 00000 0 0 00 > 0 0 > 00:00:00:03 00-13-50-03-03-50-13-00 C 2017-10-26T23:33:21Z 28 > 483 520 426 940 -96 -40 -60 -1.8 > 13 10.6 > 00:00:00:04 00-13-50-04-04-50-13-00 C 2017-10-27T19:28:39Z 603 > 4995 6856 4986 18700 -83 -36 -545 > 14.5 10.5 > > connection parameter segsz controls the size of the frame sent out by the > app, and > confirmedtx=true|false controls whether gw uses lora confirmed vs unconfirmed > frames. > > —name option is the deveui. > > > >> Begin forwarded message: >> >> From: ma...@apache.org <mailto:ma...@apache.org> >> Subject: [mynewt-newtmgr] 01/01: Merge pull request #46 from mkiiskila/lora >> Date: October 27, 2017 at 1:18:53 PM PDT >> To: "comm...@mynewt.apache.org <mailto:comm...@mynewt.apache.org>" >> <comm...@mynewt.apache.org <mailto:comm...@mynewt.apache.org>> >> Reply-To: dev@mynewt.apache.org <mailto:dev@mynewt.apache.org> >> >> This is an automated email from the ASF dual-hosted git repository. >> >> marko pushed a commit to branch master >> in repository https://gitbox.apache.org/repos/asf/mynewt-newtmgr.git >> <https://gitbox.apache.org/repos/asf/mynewt-newtmgr.git> >> >> commit 8039e8cf1c823e894a0ae8f4a439774165cbb27c >> Merge: bb86eb9 1d9bba8 >> Author: mkiiskila <ma...@runtime.io <mailto:ma...@runtime.io>> >> AuthorDate: Fri Oct 27 13:18:51 2017 -0700 >> >>Merge pull request #46 from mkiiskila/lora >> >>OIC over Lora >> >> newtmgr/cli/common.go | 14 ++ >> newtmgr/config/connprofile.go | 20 +-- >> newtmgr/config/mtech_lora_config.go | 87 +++ >> nmxact/lora/lora_coap.go | 31 >> nmxact/mtech_lora/listen.go | 201 >> nmxact/mtech_lora/mtech_lora_sesn.go | 257 +++ >> nmxact/mtech_lora/mtech_lora_xport.go | 277 >> ++ >> nmxact/sesn/sesn_cfg.go | 12 +- >> 8 files changed, 889 insertions(+), 10 deletions(-) >> >> -- >> To stop receiving notification emails like this one, please contact >> "comm...@mynewt.apache.org <mailto:comm...@mynewt.apache.org>" >> <comm...@mynewt.apache.org <mailto:comm...@mynewt.apache.org>>. >

Fwd: [mynewt-newtmgr] 01/01: Merge pull request #46 from mkiiskila/lora

2017-10-27 Thread marko kiiskila

Hi, added CoAP over LoRa option when running on Multitech gateway. root@mtcdt:~# ./newtmgr conn show mt Connection profiles: mt: type=oic_mtech, connstring='' root@mtcdt:~# ./newtmgr -c mt -t 120 --name 00-13-50-04-04-50-13-00 taskstat task pri tid runtime cswstksz stkuse last_checkin next_checkin idle 255 0 481470 4337 64 3100 loramac 0 2 551 3699 256 8700 main 127 1 58 1386 1024 46900 root@mtcdt:~# ./newtmgr -c mt -t 120 --name 00-13-50-04-04-50-13-00 res get public /oic/res ^Croot@mtcdt:~# ./newtmgr -c mt -t 120 --name 00-13-50-04-04-50-13-00 res get puic /oic/d ^Croot@mtcdt:~# ./newtmgr -c mt -t 120 --name 00-13-50-04-04-50-13-00 res get puic d Error: NotFound (132) root@mtcdt:~# ./newtmgr -c mt -t 120 --name 00-13-50-04-04-50-13-00 res get public /oic/p /oic/p map[mnos:MyNewt rt:[oic.wk.p] if:[oic.if.r oic.if.baseline] p:5 pi:fd0edd1a-5de2-44d2-400f-74b9369db40d mnmn:MyNewt] root@mtcdt:~# ./newtmgr -c mt -t 120 --name 00-13-50-04-04-50-13-00 --connextra="segsz=33,confirmedtx=true" image list Images: slot=0 version: 3.0.0 bootable: true flags: active confirmed hash: 2fb91d83abd0ea3c3a76c78462ccc287de60d83300a66c153af4a666adce6862 Split status: N/A (0) root@mtcdt:~# lora-query --node-list Net Addr Dev EUI Class JoinedSeq Num Up Down 1st 2nd Dropped RSSI min max avg SNR min max avg 00:00:00:01 00-13-50-00-00-50-13-00 A 2017-06-23T00:20:40Z1 00000 0 0 00 0 0 00:00:00:02 00-13-50-02-02-50-13-00 A 2017-10-10T20:06:51Z 10 00000 0 0 00 0 0 00:00:00:03 00-13-50-03-03-50-13-00 C 2017-10-26T23:33:21Z 28 483 520 426 940 -96 -40 -60 -1.813 10.6 00:00:00:04 00-13-50-04-04-50-13-00 C 2017-10-27T19:28:39Z 603 4995 6856 4986 18700 -83 -36 -545 14.5 10.5 connection parameter segsz controls the size of the frame sent out by the app, and confirmedtx=true|false controls whether gw uses lora confirmed vs unconfirmed frames. —name option is the deveui. > Begin forwarded message: > > From: ma...@apache.org > Subject: [mynewt-newtmgr] 01/01: Merge pull request #46 from mkiiskila/lora > Date: October 27, 2017 at 1:18:53 PM PDT > To: "comm...@mynewt.apache.org" > Reply-To: dev@mynewt.apache.org > > This is an automated email from the ASF dual-hosted git repository. > > marko pushed a commit to branch master > in repository https://gitbox.apache.org/repos/asf/mynewt-newtmgr.git > > commit 8039e8cf1c823e894a0ae8f4a439774165cbb27c > Merge: bb86eb9 1d9bba8 > Author: mkiiskila > AuthorDate: Fri Oct 27 13:18:51 2017 -0700 > >Merge pull request #46 from mkiiskila/lora > >OIC over Lora > > newtmgr/cli/common.go | 14 ++ > newtmgr/config/connprofile.go | 20 +-- > newtmgr/config/mtech_lora_config.go | 87 +++ > nmxact/lora/lora_coap.go | 31 > nmxact/mtech_lora/listen.go | 201 > nmxact/mtech_lora/mtech_lora_sesn.go | 257 +++ > nmxact/mtech_lora/mtech_lora_xport.go | 277 ++ > nmxact/sesn/sesn_cfg.go | 12 +- > 8 files changed, 889 insertions(+), 10 deletions(-) > > -- > To stop receiving notification emails like this one, please contact > "comm...@mynewt.apache.org" .

Re: BLE + LoRa

2017-10-05 Thread marko kiiskila

RF signal leaking to one of the debug cables, and then that acts as an antenna? Is the frequency difference between actual signal and ‘shadow’ always the same, or about the same? Do you see the ‘shadow’ ever come before the frame with good RSSI? I don’t know where the time stamping happens, but if that happens after frame delivery has been serialized… In that case you could have timestamps which are slightly different, but actually for frames which arrive at the same time. I’m just guessing here ;) > On Oct 5, 2017, at 8:10 AM, will sanfilippo wrote: > > I cannot say that I have seen this. I do have a question though. You said > that the device is not physically sending these packets because they overlap > in time. You also mentioned that the shadow packets are within 10-30 msecs of > the real packet. Is what you are saying that the real packet is > 10-30 msecs > in length and the start of the shadow packet overlaps with the end (or some > portion) of the real packet? > > In my past RF experiences I have seen something like this with a device that > transmitted at a high power level and the signal bled into other channels > (i.e. device A transmitting on channel X; device B receives that packet, at a > much reduced RSSI, on channel Y). That explanation does not explain the delay > of 10-30 msecs however. > > Of course, attaching a cable could create another path/antenna. Still does > not explain the delay. I would have suspected the firmware doing another > transmission but you have ruled that out… > > Others I am with are scratching their heads (as am I). > > >> On Oct 5, 2017, at 6:31 AM, Gordon Klaus >> wrote: >> >> Thanks for sharing your experiences, Will. Sorry for the delayed reply. >> >> Our device is a BLE peripheral. We've haven't been moving data at all in >> BLE. It seems clear that BLE is not at fault. >> >> Our latest findings show that having a connection to the console is causing >> strange LoRa behavior. In particular, we observe that our gateway is >> receiving "shadow packets": messages with low signal strength (RSSI < -100) >> simultaneously (usually within 10-30 ms) with the actual packets (RSSI >> -40). These shadow packets are received on different channels (867.x MHz) >> than the actual packets (868.x) and are usually corrupt. Our network >> server was not handling these duplicate, corrupt messages correctly and so >> they interfered with the join procedure and transmitting other data. >> >> We see these shadow packets very often (90% of the time) when the debug >> cable is connected and with a console connection open in telnet or >> JLinkRTTClient. Without a console connection, never at all. We see the >> shadow packets in tcdump and in the network server logs. >> >> We have verified that the device is not actually sending more than once (it >> would be impossible anyway, as the packets overlap in time). >> >> We've tried it with several different device<->programmer setups (always on >> the EE-02), and with a couple different gateways. >> >> It would be interesting to hear if you have the same experience, or any >> inkling of an explanation. >> >> On Mon, Sep 25, 2017 at 9:44 PM, will sanfilippo wrote: >> >>> Not sure this helps, but here is what I have seen after pulling latest and >>> doing some quick testing: >>> >>> It does appear that the first join attempt fails fairly often. I tried >>> half a dozen times and it appears that the first transmission succeeded >>> only once. It always succeeded on the second attempt however. I am doing US >>> band testing btw; I have not done any non-US band testing. One item I need >>> to verify is actual transmission attempts and what is reported in the >>> statistics. In the US there are two join requests transmitted: one in the >>> “normal” channels and one in the channels that are in 64 plus range. So I >>> have to verify if both are being sent and both are actually failing. I have >>> noticed that the gateway I am using has only reported a received join >>> request on the normal channels (channel number < 64). >>> >>> A quick note: I am using a multitech gateway and when the joins fail the >>> multitech gateway is not reporting any received packets. So the gateway is >>> simply not seeing the transmissions. I looked at the gateway stats and I do >>> not see any error statistics so it looks like it simply does not see the >>> packet or there is a MIC failure (seems like the multitech gateway does not >>> report MIC failures). >>> >>> My test setup is far from ideal though; the gateway is seeing me very >>> poorly; not sure if it is the antenna or maybe antenna connection to module >>> but I would have expected better than the -97 to -100 RSSI being reported. >>> I will dig into that in a bit. >>> >>> Oh, I should probably mention that the BLE app I am using is a peripheral >>> that should be constantly advertising. I have

Re: task stack initialisation change proposal

2017-09-14 Thread marko kiiskila

+1 from me. After merging this, I’d also want to change the native target stack initialization to do same thing (as that has similar alignment restrictions). > On Sep 14, 2017, at 3:33 AM, Julian Ingram wrote: > > Hi All, > > Currently the stack top and size are initialised just after the architecture > specific initialisation of the stack, I propose moving the architecture > specific initialisation so they can be modified within it and not overwritten. > > The PIC32 port needs the stack to be 8 aligned, currently that is achieved by > constructing the stack from uint64_ts however this is not guaranteed by the C > spec to be effective. A solution would be to align the stack within > os_arch_task_stack_init (in case the former method is not effective). The > lazy FPU context is stored at the stack top, so this needs to be coherent. > > As discussed: > > https://github.com/apache/mynewt-core/pull/474#discussion_r131878603 > > I have made a PR with these changes: > > https://github.com/apache/mynewt-core/pull/548/commits/37e4b27eb2736cd8221b63ff8a88b1bf566d94e0 > > Any comments would be appreciated. > > Thanks, > > Julian Ingram > Software Design Engineer > MIPS Platforms > Imagination Technologies Limited > t: +44 (0)113 2429814 > www.imgtec.com >

Re: Regarding Arduino M0 zero serial communication implementation

2017-08-29 Thread marko kiiskila

> On Aug 28, 2017, at 11:49 PM, jyoth...@aritron.com wrote: > > On 2017-08-28 17:41, marko kiiskila wrote: >> I just tried it, it worked for me at least. >> Take a look at output from ‘newt target dep ’, make sure you >> seen console/full, as well as shell as listed packages. >> Make sure that main() goes and executes os_eventq_run(os_eventq_dflt_get()) >> in >> a loop, as that’s needed for shell to pick up uart input. >>> On Aug 27, 2017, at 9:24 PM, jyoth...@aritron.com wrote: >>> On 2017-08-25 17:21, Christopher Collins wrote: >>>> On Fri, Aug 25, 2017 at 09:53:26AM -0700, marko kiiskila wrote: >>>>> Also note that blinky does not have shell compiled in. It’s a very simple >>>>> app which just blinks an LED. Try the app slinky instead; that one has >>>>> shell >>>>> enabled. >>>> I believe Jyothi is following this tutorial which adds console and shell >>>> to blinky: >>>> https://mynewt.apache.org/latest/os/tutorials/blinky_console/. >>>> Chris >>> Hi chris, >>> Yes chris I am following that tutorial only. But not able to succeed any >>> one has tried for arduino M0 pro for console and shell. > Hi marko, > Thqs for your reply. > I already implemented all the packages and able to see console/full and > shell. And even I checked in main() which has > os_eventq_run(os_eventq_dflt_get()) in while loop. > In serial port setup tutorial is it must to connect to board FT232H to > arduino M0 pro to get the shell commands in console using minicom. > I am connecting programming port of arduino M0 pro to my ubuntu system didn't > connect FT232H board and can able to see the blink on the board but unable to > get the shell console. https://mynewt.apache.org/latest/os/get_started/serial_access/ <https://mynewt.apache.org/latest/os/get_started/serial_access/> The tutorial expects you to use the UART pins from pin header (labeled RX<-0 and TX>-1). Are you using those? Tutorial also calls out minicom as the terminal program, which enables hardware flow control by default. Remember to turn that off.

Re: Regarding Arduino M0 zero serial communication implementation

2017-08-28 Thread marko kiiskila

I just tried it, it worked for me at least. Take a look at output from ‘newt target dep ’, make sure you seen console/full, as well as shell as listed packages. Make sure that main() goes and executes os_eventq_run(os_eventq_dflt_get()) in a loop, as that’s needed for shell to pick up uart input. > On Aug 27, 2017, at 9:24 PM, jyoth...@aritron.com wrote: > > On 2017-08-25 17:21, Christopher Collins wrote: >> On Fri, Aug 25, 2017 at 09:53:26AM -0700, marko kiiskila wrote: >>> Also note that blinky does not have shell compiled in. It’s a very simple >>> app which just blinks an LED. Try the app slinky instead; that one has shell >>> enabled. >> I believe Jyothi is following this tutorial which adds console and shell >> to blinky: >> https://mynewt.apache.org/latest/os/tutorials/blinky_console/. >> Chris > Hi chris, > Yes chris I am following that tutorial only. But not able to succeed any one > has tried for arduino M0 pro for console and shell.

Re: Best practice for usage of the log_fcb_handler

2017-08-25 Thread marko kiiskila

> On Aug 25, 2017, at 10:28 AM, Alfred Schilken <alf...@schilken.de> wrote: > > Thanks Marko, this helps. > > So I can cut off some Kb from the FLASH_AREA_REBOOT_LOG area, > create an own slot with it and bind it to an own log_fcb_handler. > > Right? Yes, all that should work. > > I wanted to be sure, that the FLASH_AREA_NFFS can’t be shared by several > handlers. > flash_map thing is a convenience thing which allows us to have a way of specifying flash regions meant for a specific purpose and be platform independent. In general, the thinking was that an entry in the flash_map would be used by one consumer only (image slots for images, bootloader etc). Also, to create an FCB, you don’t necessarily need a flash_map entry. If I remember correctly, you pass it an array of flash sectors which you’d want to use (which don’t necessarily have to be contiguous either). FLASH_AREA_NFFS is special in this regard, because the thinking was that if you’d need a place to store config, and you’d use either NFFS or FCB. Some platforms don’t have that many flash sectors (STM32F2/4), so we ended up reusing that same area of flash. If you’re not going to use sys/config, or NFFS, you can use that space for your logs as well. > > EDV-Beratung Schilken > alf...@schilken.de > www.schilken.de > mobil: +49 178 1475677 > >> Am 25.08.2017 um 19:06 schrieb marko kiiskila <ma...@runtime.io>: >> >> >>> On Aug 25, 2017, at 9:29 AM, Alfred Schilken <alf...@schilken.de> wrote: >>> >>> Hello, >>> >>> I couldn’t find an example usage of the log_fcb_handler and just used the >>> reboot_log for writing to the 16 kB FLASH_AREA_REBOOT_LOG area. >>> >>> This works fine but it a bit dirty. >>> >>> Is there a cleaner way to use both the CONFIG_FCB and the LOG_FCB at the >>> same time in an app? >>> Maybe both can use the FLASH_AREA_NFFS? >>> >>> The BSP is an nRF51, so no chance to use a real filesystem - I think. >> >> >> True. However, nrf51 has small flash blocks, so you should be able to have >> dedicated >> flash areas for different uses. So maybe it’ll be ok? >> >> At least the intent has been that you should be able to have multiple, >> separate areas, >> for logs with FCB. >> I.e. create separate FCB structures, tying them to their respective >> log_handlers. >> Then direct logs of the types you want to that specific log handler. >> >> I’m pretty sure we have specific sample apps showing this. I’d recommend >> looking >> at the unit test we have for sys/log, specifically the ones which use FCB as >> the >> log target. >> >> Hope this helps, >> M >> >

Re: Best practice for usage of the log_fcb_handler

2017-08-25 Thread marko kiiskila

> On Aug 25, 2017, at 9:29 AM, Alfred Schilken wrote: > > Hello, > > I couldn’t find an example usage of the log_fcb_handler and just used the > reboot_log for writing to the 16 kB FLASH_AREA_REBOOT_LOG area. > > This works fine but it a bit dirty. > > Is there a cleaner way to use both the CONFIG_FCB and the LOG_FCB at the same > time in an app? > Maybe both can use the FLASH_AREA_NFFS? > > The BSP is an nRF51, so no chance to use a real filesystem - I think. True. However, nrf51 has small flash blocks, so you should be able to have dedicated flash areas for different uses. So maybe it’ll be ok? At least the intent has been that you should be able to have multiple, separate areas, for logs with FCB. I.e. create separate FCB structures, tying them to their respective log_handlers. Then direct logs of the types you want to that specific log handler. I’m pretty sure we have specific sample apps showing this. I’d recommend looking at the unit test we have for sys/log, specifically the ones which use FCB as the log target. Hope this helps, M

Re: Regarding Arduino M0 zero serial communication implementation

2017-08-25 Thread marko kiiskila

> On Aug 25, 2017, at 8:39 AM, Christopher Collins wrote: > > Hi Jyothi, > > On Fri, Aug 25, 2017 at 12:10:50PM +, jyoth...@aritron.com wrote: > [...] >> After we run the application, cant able to get the shell prompt as >> mentioned by you through minicom. With Arduino IDE and the arduino >> EDBG boot loader we can able to communicate with the board. But with >> the arduino_boot and arduino_blinky targets in mynewt cant able to >> communicate. > > Did you set the BSP_ARDUINO_ZERO_PRO syscfg setting to 1, as indicated > in https://mynewt.apache.org/latest/os/tutorials/arduino_zero/? That > step is easy to miss. > Also note that blinky does not have shell compiled in. It’s a very simple app which just blinks an LED. Try the app slinky instead; that one has shell enabled.

duplicate BSP under mynewt_nordic repository?

2017-08-17 Thread marko kiiskila

Hi, PWM API and driver for nordic were merged in today (yay for mlaz). In order to make it easy to try out, I’m proposing creating a BSP for nrf52dk under mynewt_nordic. Basically a duplicate one which is present in apache-mynewt-core, but one which enables additional peripherals. Specifically ADCs and PWMs. AFAIK, we cannot have dependencies from mynewt-core to packages in nordic repository. Therefore we can’t have config knobs within core's ‘vanilla BSP’ including these drivers. With this other BSP in nordic you could have syscfg knobs allowing the inclusion of these drivers, therefore a) allow people to see how to build their BSPs, b) allow people an easy way to test ADC/PWM and c) allow developers construct test build targets to verify that they haven’t broken support by accident. Any opinions on this? Or better ideas than this one?

Re: duplicate repositories mynewt_arduino_zero, mynewt_nordic, mynewt_stm32f3

2017-07-11 Thread marko kiiskila

> On Jul 11, 2017, at 2:53 PM, marko kiiskila <ma...@runtime.io> wrote: > > >> On Jul 11, 2017, at 11:09 AM, Fabio Utzig <ut...@utzig.org> wrote: >> >> On Tue, Jul 11, 2017, at 12:51 PM, Todd Mitton wrote: >>> It would be nice to transfer the ownership of the repos from the >>> runtimeinc >>> organization to the runtimeco organization. That way github would >>> redirect >>> from the old location to the new location and old links would continue to >>> work. You'd have to delete the repos from runtimeco, then transfer from >>> runtimeinc to runtimeco. >> >> Apart from redirection it also transfers stars/forks. > > Fair enough. I’ll apply changes made to runtimeco version to runtimeinc > version, > remove runtimeco version, and transfer the ownership from runtimeinc to > runtimeco. Ok, done.

Re: PWM Driver

2017-07-11 Thread marko kiiskila

Hi, > On Jul 10, 2017, at 8:31 PM, Miguel Azevedo wrote: > > I am currently developing a PWM driver for mynewt, more specifically a > driver for nRF52 based hardware. > Therefore I came up with this PWM high level API, which will be > described ahead on this e-mail. > Its source code: > https://github.com/mlaz/mynewt-core/blob/pwm_dev/hw/drivers/pwm/include/pwm/pwm.h > > This API is based in both the current ADC high level API > https://github.com/apache/mynewt-core/blob/master/hw/drivers/adc/include/adc/adc.h > and the abandoned hal_pwm API > https://github.com/apache/mynewt-core/blob/090_dev/hw/hal/include/hal/hal_pwm.h > . > The API itself is roughly the same as hal_pwm exposes, which aligns > with the following concepts: > -It is assumed that within a system there is a number of discrete PWM > devices which provide a number of channels per device. > -These devices are configurable, its configuration typically > contemplates all the parameters which affect all the provided channels > (global to the device). > -A channel is also configurable and its configuration may or may not > affect other channels provided by the same device, depending on the > device's configuration. > > I would be glad to have some feedback from the community, in order to > validate this approach. > In general this seems reasonable, I like it. And thanks for picking up the effort. For clarification; setting frequency for a pwm_dev would set it for all channels belonging to that pwm_dev? Comment on the function prototype for pwm_set_frequency_func_t() says that ‘it might’ affect other channels, and this confuses me :) What do you mean by that comment? — M

duplicate repositories mynewt_arduino_zero, mynewt_nordic, mynewt_stm32f3

2017-07-10 Thread marko kiiskila

Hi, currently we have these repositories (with almost the same contents), the new one in github.com/runtimeco and old one in github.com/runtimeinc Although from pulling point of view it is somewhat more convenient to users to have them like this (as the old versions of documentation were point to runtimeinc, new versions point to runtimeco), it is painful to maintain. We’ve already made mistakes when tagging; pull requests were made against old repo etc. Would anyone object if I remove the old repositories completely? It appears that you can do git remote set-url to point to new repo, if people have lingering links.

Re: How to use flash circular buffers (FCB)

2017-06-26 Thread marko kiiskila

Hi, > On Jun 26, 2017, at 3:29 AM, Laczen JMS wrote: > > Hi, > > I would like to use flash circular buffers for variable storage and > logging. I am not sure how to initialize and use the buffers. I am working > on a nrf51 system. > > The first use case is storing of data (e.g. integer), I would like to store > data1 (int), data2 (int), data3 (int) in the flash area FLASH_AREA_NFFS: > (in my case only 2kb). How do I initialize and use a FCB for each data > element (data1 ... data3) in one flash area (FLASH_AREA_NFFS)? as you probably have gathered, FCB works on units of sectors. These sectors being defined in the flash driver. FCB can work with one sector present only, but if you want some data retention when your area overflows, you’ll probably want to allocate at least 2 sectors per area. If you need to create 3 separate FCB areas, you’ll have to set aside space accordingly. I imagine you should start by setting your BSP’s bsp.yml such that you have the space to keep those FCBs. Note that the flash_map, with these ids (e.g. FLASH_AREA_NFFS) is an abstraction layer which we needed to make it easier to have an code which is platform independent regarding locations. I.e. you don’t have to use those ids for your data. You can, of course, should you choose :) Unfortunately I don’t think there’s specific documentation written for FCB, but for simple use cases, take a look at unit tests in fs/fcb/test/src/testcases. > > The second use case is for logging. I would split the FLASH_AREA_REBOOT_LOG > (16kb) area in 2 area's of each 8kb: FLASH_AREA_REBOOT_LOG (8kb) and > FLASH_AREA_LOG (8kb), how do I setup a logger to use the FLASH_AREA_LOG? You create 2 different loggers, and then assign logs from subsystem(s) to go to these different logger targets. Intent was that you should be able to have multiple separate FCB areas where you log data to. I believe this to be the case, but I have not tried that myself. Again, the unit tests for package sys/log/full would probably be helpful in getting started. These are in sys/log/full/test/src/testcases Hope this helps, M

63 matches

Mail list logo