Saturday, April 21st 2018, 3:25pm UTC+2

You are not logged in.

  • Login
  • Register

Search results

Search results 1-11 of 11.

Tuesday, March 27th 2018, 8:33pm

Author: akohlsmith

building firmware on windows with msys2 (cygwin), ozone can't find source

Quoted from "SEGGER - Nino" Quoted I'm not sure what you mean "path or name will not change" -- I'm not moving anything. I'm literally running make, and then loading the .elf file from (PROJECTDIR)/_build, with the source in (PROJECTDIR). How did you create the Ozone project? Did you create it and then move it around? Did source files or the output file change path or filenames? In all these cases Ozone won't know where the files are located and the path functions need to be used. Or you can si...

Tuesday, March 27th 2018, 7:34pm

Author: akohlsmith

vcom RTS (from JLink to Nordic) "sticks"

*bump* Any word on this? It's completely reproducible. Alternatively, is there a better way to contact Segger for support on this issue?

Tuesday, March 13th 2018, 4:04pm

Author: akohlsmith

building firmware on windows with msys2 (cygwin), ozone can't find source

Quoted from "SEGGER - Nino" When creating a new Ozone project and opening a corresponding elf file Ozone expects that the output file path or name will not change. Sometimes projects need to be moved. To keep them portable you can use function: Project.AddPathSubstitute I'm not sure what you mean "path or name will not change" -- I'm not moving anything. I'm literally running make, and then loading the .elf file from (PROJECTDIR)/_build, with the source in (PROJECTDIR). Quoted from "SEGGER - Ni...

Tuesday, March 13th 2018, 3:39pm

Author: akohlsmith

vcom RTS (from JLink to Nordic) "sticks"

It's not an issue specific to the dev board; I was using the larger devboard to try to diagnose the problem. It's the "NRF51-Dongle" (Digi-Key part number 1490-1037-ND) that we first noticed the problem on. I'm absolutely positive it can be reproduced on any J-Link using vcom. Reproducing it: - configure target to send a continuous stream of data to the Segger over UART (we are using 460800,N81 but baudrate should not matter). Make sure that target observes hardware flow control as required by t...

Monday, March 12th 2018, 1:46pm

Author: akohlsmith

Timeout while blank checking, RAMCode did not respond in time

I oftentimes get this if I've protected the Flash on my Nordic nRF51822 designs. At least for me, in those cases, I manually use w4and mem32 to erase the entire flash, reset the ARM with the r command and then I am able to use the Segger high level functions. I don't know if this will help in your case, but it might be worth a try.

Thursday, March 8th 2018, 9:38pm

Author: akohlsmith

[SOLVED] Multiple instances of Ozone on OSX?

On Windows, it's easy to load two copies of Ozone (for multi-core debugging). How do I do this on OSX?

Thursday, March 8th 2018, 8:20pm

Author: akohlsmith

vcom RTS (from JLink to Nordic) "sticks"

I've got about a dozen copies of JLink on my system now. :-) The regression occured in the firmware shipped with 610b. The firmware shipping with 610a is good. 610b (CTS does not re-assert if the UART buffer is filled and a USB connection is made) ships with J-Link OB-SAM3U128-V2-NordicSemi compiled Sep 26 2016 11:30:32 610a (CTS will re-assert if the USB buffer is full and a USB connection is made) ships with J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 5 2016 08:42:09 This regression has been...

Thursday, March 8th 2018, 5:56pm

Author: akohlsmith

vcom RTS (from JLink to Nordic) "sticks"

Another datapoint: JLink 5.10h (January 12, 2016) DOES NOT have this issue. I can start and stop the virtual COM connection as many times as I like and the CTS line to the Nordic does not get stuck.

Thursday, March 8th 2018, 4:46pm

Author: akohlsmith

vcom RTS (from JLink to Nordic) "sticks"

I'm using the Nordic 400092 nrf51 dev board with an embedded Segger. The firmware on the Segger is "J-Link OB-SAM3U128-V2-NordicSemi compiled Jan 12 2018 16:05:20". I think there has been a regression in the J-Link firmware. I have been using these boards for *months* without issue, but very recently I've been seeing a case where the RTS line (from the SAM3U to the Nordic) will go high and stay high. It's fairly easy to reproduce: Have the Nordic spew data to the Segger while the PC is reading f...

Thursday, March 8th 2018, 3:16pm

Author: akohlsmith

building firmware on windows with msys2 (cygwin), ozone can't find source

Using ozone v2.56d on Windows 7 x64. I am building code for the nRF51822 using the Nordic dev board 400092 which has a JLink embedded on it. I use msys2 and arm-gcc to build my source code because the same build environment works on Windows, OSX and Linux. I'm using CFLAGS of -Og -g to build the firmware, and the same Makefile on Linux and OSX produces .elf binaries which Ozone can work with just fine. However when I build the source in Windows and load the .elf with Ozone, it cannot find any so...