A week with CrossWorks

RE: A week with CrossWorks

Francis Henderson — Thu, 10 Nov 2016 01:18:04 GMT

I've come to like Crossworks even though getting started with their Tasking lIbrary on the Raspberry Pi wasn't as easy as I thought it should be. For the $150 personal license it's a good deal, however be prepaired to spend a couple of intense weeks getting your application to run. I succeeded. Following are some things Rowley marketing doesn't tell you:

Their Raspberry Pi Board Support Package (BSP) targets the RPi Model A that is no longer in production. I got a Model A on Ebay for simplification. You'll have to change at least the GPIO base memory address in software when targeting other RPi Models.
Their documentation does not tell you anywhere that you must import and build the Crossworks Tasking Library (CTL) into your project to use it. I found a 2011 discussion about this requirement that still is not in their documentation (2016).
Their code is sparcely commented. Some pages have none. You're on your own figuring out how to change the GPIO base address, for example, to run on a RPi Model B+. Recommend getting up and running on a Model A, first.

So yes, the provided BSP with CTL can save a lot of development effort from scratch. However, you'll have some pain to go through figuring out the instructions they left out and apparently no intention to improve. Regardless, it's a nice clean tool that has worked flawlessly for me. No compiler to install or configure, or make files, or linker files to worry with. It's all nicely hidden and easy to use. Love it.

RE: A week with CrossWorks

Susheel Nuguru — Tue, 20 Sep 2016 11:19:30 GMT

I just got the license and starting to like many features in it. The import project became much easier now, probably because CrossWorks is starting to identify nRf5x targets.

RE: A week with CrossWorks

Ole Bauck — Thu, 07 Jan 2016 11:44:59 GMT

I have been testing out Crossworks and yesterday I was able to port SDK projects over from Keil to Crossworks and get them working, both for nRF51 and nRF52. The procedure is shown in this post (the last 4 points can be skipped if using nRF51). Please feel free to check if you also are able to do this, and make suggestions to improve the answer.

RE: A week with CrossWorks

drkow19 — Fri, 12 Jun 2015 17:32:28 GMT

Their flash code loader is slightly unusual. Instead of using the JLink to dump code in flash, it uploads a small loader to RAM and then drives it with JLink, setting the PC and registers and running it, very cool idea. I had some problem because my chip had previously been used with a softdevice and code in RAM can't write to flash in code region 0. Rowley were super helpful and got me going and I learned about the loader in the process (it's documented) and even wrote my own to be softdevice-aware.

I think I am running into the problem you mentioned here. I will flash the soft-device using nRFGo Studio, then flash my program to 0x18000 using CrossStudio, but any soft-device function will fail. I have the same code, compiled with Keil uVision, and the soft-device code works fine. But as soon as I port it over to CrossStudio it does not work. I have read some topics on nRF51 and CS, but nothing is working. How did you get around this issue?

RE: A week with CrossWorks

tomtom07121 — Thu, 07 Aug 2014 11:46:42 GMT

@RK

How exactly did you get the Nordic blinky example working in crossworks?

RE: A week with CrossWorks

sandeep — Mon, 04 Aug 2014 11:30:59 GMT

has anyone used the crossworks with different programmers (like the ulink2/stlink v2) for nrf51822 ? I'm hoping someone has a workflow that does include all the mergehex (to combine SD, DFU and app) and is able to debug using the programmer.

RE: A week with CrossWorks

cocoa — Sun, 20 Jul 2014 10:07:05 GMT

Hit the nail on the head.

-c

RE: A week with CrossWorks

Scott Piette — Mon, 14 Jul 2014 17:48:08 GMT

I have been struggling with setting up a development environment that works on the Mac. Using Eclipse is not straight forward and there are several paths to getting it set up. All seem to fall short in one way or another. Unless you are already familiar with Eclipse you are lost.

Needless to day after several days and numerious re-installs (to start over) I sort of have Eclipse working but can't seem to get it debugging properly. I first tried the Mac but found it would not talk reliably with PCA10000, I moved back to Windows and now can't get the debugging to work correctly with Eclipse (I am using the JLink tools and installed their plugin).

Anyway after investing a ton of time without success I came across this posting. I found it interesting and hopeful. So I have downloaded the Crossworks application for both Windows and Mac. I seem stuck in getting the proper library settings so that the nRF SDK sample applications will compile.

I am a bit concerned that after searching their community support blog there are unanswered questions from 2010. Many of the searches I did resulted in finding similar questions w/o answers. I have posted a question and hopefully someone will respond.

What would be great would be a tutorial, or writeup on how to get one simple application to compile, flash and debug. Even nan29 falls short on this.

I am trying to build and run the simple led_radio_example that Nordic supplies with the PCA10000. Its under nRF51822/Board/pca10000.

Under crossworks I had to add the include path and define the board to get it to compile, but I still need to get the linker to find the libraries such that it can resolve the external calls.

It looks promising because it has taken less time than Eclipse to set up so far. Any help would be appreciated - either in getting CrossWorks to work, or going back to Eclipse.

UPDATE - 7/23/2014

I really am liking CrossWorks. They have good support, their tools work on Mac and Windows. I even have an environment with a shared drive that allows me to move between Mac and Windows using the same project tree.

I had a bit of difficulty at first because the default configuration project setting for nRF51822 only had a stack memory allocation of 128 bytes, that will get you a few function calls and end up putting you into a HardFault_Handler. So if you are trying to debug - take a look to make sure you have enough memory for the stack. You can check your .hzp file and look for

arm_linker_stack_size="128"

change it to 1024 or 2048.

There are some other convenience settings such as setting up Macros for the SDK base path and if you use the softdevice you need to set this

linker_section_placement_macros="FLASH_START=0x14000;RAM_START=0x20002000"

and this

debug_entry_point_symbol="nonexistent"

so your binary will be placed in the proper memory location after the softdevice.

In summary - The CrossStudio IDE was easier to setup, easier to use, and is cross platform (i.e. - they have installs for Windows and Mac).

RE: A week with CrossWorks

K. Townsend — Tue, 10 Jun 2014 02:19:00 GMT

I've been a long time Crossworks user, and it definately doesn't get the love that it deserves, especially from silicon vendors ... which is a shame. Every silicon vendors I've worked at or worked with only seems to know and accept Keil. Like you, I really dislike Keil. I know how to use it (warts and all), I have a license for it, but I hate using it. Good compiler, hideous, awkward, painful 1980s IDE. For example ... forcing a flat file structure in your projects? Seriously?! ;)

I have a commercial license for CW3, but I do like the fact that it's all based on GCC so I'm never locked into their IDE or activation servers since I can always create a makefile, as long as I avoid some of the proprietary libs like their tasking library (which I never used with the 51822 anyway).

I really wish Nordic would get in touch with Rowley Associates, though. Paul Curtis is a great guy to deal with, and he has a top notch team and product. It's the only professional quality IDE today that just works out of the box on OSX, Windows or Linux with no hassle moving between platforms (Eclipse just isn't there for ease of use or out of the box anything).

It seems like win-win for everyone to at least put this on the radar for non Windows Nordic customers. Given the dominance of iOS for BLE I'm guessing there is a pretty decent percentage of users who would prefer to be working natively on OSX, and CW is the best solution for that today in my opinion.

Glad to see someone else discovering it!