Search Results
Search results 1-20 of 45.
This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.
-
Quote from SEGGER - Nino: “Hello, Thank you for your inquiry. We were able to reproduce this issue with macOS and US keyboard layout. This issue will be investigated further and is planned to be fixed with the next Embedded Studio release version. Sorry for any inconveniences caused. As a workaround you can either change the keyboard layout to one that does not show this behaviour e.g. German keyboard layout or edit the keyboard.xml in the Embedded Studio install folder under /bin. Best regards,…
-
I've been trying to learn some of the shortcuts in SES and couldn't work out why I kept getting compile errors afterwards until I noticed that typing (for instance) Alt-g as well as performing the action of 'going to the reference' also inserts a 'g' into the source code just before it jumps to the reference. The same seems to occur with all the Alt+<letter> combinations I've tried, they all perform the action, but insert the <letter> into the source as well. So currently I'm back to using the r…
-
Absolutely - I'm a regular on the Nordic dev site and there have been a number of posts in the last few months asking if Nordic's 'nrfjprog' could be made available for ARM, specifically RaPi. I'm fairly certain from looking at the code and post on the site that they are using the JLinkSDK, in fact I'm 100% certain. It doesn't do anything amazingly special, you could do it with JLinkExe and scripts, it's just a command line tool which is tailored for the series and people find very valuable. The…
-
You provide a JLink package for using JLink from source systems running on ARM (eg Raspberry Pi). Do you now also provide JLink SDK support for that target as well so that people using JLink SDK to write products can compile a version which runs on ARM? I'm seeing more and more people who are developing on a RaPi and asking for native versions of code using the JLinkSDK. Not asking here about the standard JLinkExe etc which I know is available, but SDK support for ARM-based development (just to …
-
Thank you Niklas, as usual. Possibly worth pointing out I typed "Atmel", "Atmel EDBG" and "Atmel D21" into the search box and didn't find that page, or actually any page. Am I using the search incorrectly? I will upgrade the firmware tomorrow when I have access to a windows box, I so prefer the JLink interface to the EDBG one.
-
Segger has released several upgrades for both ST boards and Atmel EDGB boards converting them into Segger OB, I know because I've upgraded all my STs and it seems I've upgraded an Atmel SAM4S at some point. I now have one other Atmel board, a SAM D21 Xplained Pro but I can't work out if there is a Segger OB upgrade for it or if this board needs to continue to run in CMSIS-DAP mode. The documentation from Atmel seems to indicate it is compatible, perhaps they ship their new boards with OB install…
-
I see JTAGLoad released as part of production v6.10e which I just downloaded, and it's for Linux and MacOS which is great. I'll put my test hardware back together and go start testing it and will report any issues; I'm sure if it's worked for Windows for such a long time it'll work just fine for the others too. Thanks for the continual cross platform support.
-
Looking for BSDL tools I found a few posts mentioning JTagLoad, which is pretty much exactly what I need. However it doesn't appear to exist in the current Linux software pack. I found this post JTAGLoad - Linux from 2+ years ago suggesting it wouldn't be too hard to add and would be added in one of the next few versions. Was it ever made available for Linux but as a separate download, or is it still windows-only?
-
This is all documented pretty well on the Nordic devzone - they even have a command-line utility, cross platform, for this. I suggest going there to find all the threads about it. The steps, for anyone finding this thread later are SWDSelect SWDWriteDP 1 0x50000000 SWDWriteDP 2 0x01000000 SWDWriteAP 1 0x00000001 sleep 500 SWDReadAP 3 SWDReadAP 3 exit
-
I haven't installed a new version of JLink for a few weeks (running 5.12F), have been using my JLink, few years old now, pretty constantly. Yesterday after about 30 minutes of use I connected to my test board and got a message that the firmware was being upgraded Quote: “Connecting to J-Link via USB...Updating firmware: J-Link V9 compiled Apr 22 2016 11:47:06 Replacing firmware: J-Link V9 compiled Oct 12 2012 BTL Waiting for new firmware to boot FAILED: Communication timed out: Requested 4 bytes…
-
It would be a very handy enhancement if you were able to name the interrupts in the .txt file as well. With the latest enhancements I've managed to move almost all the strings to the .txt file, saving code size and bandwidth. The only strings left in the instrumentation code are now the IRQ names and you have to decide how often to send them. If SystemView read them from the .txt file, it would always have them available no matter when it started up.
-
That was good timing - I see those in the most recent version from a few days ago, just what I needed. I also see you've introduced NamedType in the description file, that's really helpful too, I was just writing code to map dozens of OS-specific values to identifiers and use the %I flag to display them, which was huge code bloat on the target and a waste of bandwidth; now I don't have to do that. The manual lists the modifiers %b, %d, %D, %I, %p, %t and %u, however I needed to display a string,…
-
if you just look at the diffs in the patches for FreeRTOS V8 it's about 2 hours work to port them over to version 9. The kernel of the code is incredibly similar, there's been a little refactoring which removes a few of the places you need to add calls and the FreeRTOS piece of it stays basically the same (unless you care about instrumenting the few new calls which I didn't). So while you're waiting, you can throw this together yourself quite easily.
-
should be there, but you'll find it in the timeline under whatever 'task' happened to be running at the time, which is probably idle, it doesn't get a separate row. If you find it in the list at the top and click on it there, the cursor will jump to it, then zoom in really far and you should see the tiny tick mark.
-
The 'cause' flag in OnTaskStopReady() isn't defined anywhere I can see, however it must have a meaning as SystemView decodes the reason and adds it to the Task Block lines in the viewer. It's possible to guess at a few, eg 0x0C == Wait for event with timeout 0x04 == Wait for timeout those are out of one of the sample traces. So 0x04 looks like the 'timeout' flag and 0x08 the 'event' flag. There must be more however, the FreeRTOS port for instance sends ((3u << 3 )|3) == 0x1B for tasks being susp…