Cortex-M3 Debugger & Tools

What tools are available for debugging the Cortex-M3 micros, such as the ST32 and Luminary Micro lines? Also, has a GCC toolchain been ported to those processors?

My understanding is that the Cortex-M3 core has a new debug port - the Serial Wire JTAG Debug Port.

I see SF carries an ST32 board. I wonder what folks have used to develop with it? It is from IAR and might include a trial version of their software.

Thanks!

There is an experimental WinARM toolchain that supports the Cortex-M3:

http://www.siwawi.arubi.uni-kl.de/avr_p … tml#winarm

I am using it for my project and it seems to work.

Fantastic.

What debugger are you using? Are you using a Solaris or ST32 device?

For what it is worth, the Luminary Micro development kits serve not only as starter kits, but can also debug an external target. The only other board I have seen that can do that is the AVR Dragon. I don’t know if the LM kits would work with OpenOCD or not, though Codesourcery has their own port of the Gnu toolchain that works with it they call G++.

I have really warmed up to the LM devices, but I need a really fast SPI and so far the SAM7 family is the only thing that gets me the speeds I need.

A quick question for the ARM gurus, is the Thumb2 mode of the CM3 the same as the ARM7 Thumb mode, or are there differences? I had the impression the CM3 Thumb mode is a superset of the previous Thumb mode, so Thumb mode code could work on the CM3, but a compiler optimized for the CM3 would be better.

Regards

I am using STM32. Thumb2 is different from Thumb, it has both 16 and 32 bit instructions and other improvements.

OpenOCD supports the STM32 but I have not tested it with GDB yet.

About speed and performance, read this thread:

viewtopic.php?t=10870

SAM7 is not the fastest thing around it seems.

regards,

Giovanni

Thanks!

I would definitely prefer to go with a CM3 processor if I could. The LM devices’ SPI port is much too slow and the STM32s do not have built-in Ethernet controllers.

On the flip side, Atmel is coming out with their own CM3 micros later this year, including ones with Ethernet early next year - the SAM3 line. According to their early claims, they are looking to really increase the clock speed up near the ARM9 speeds. While SAM7 is my default choice due to the SPI issue, I am hoping that down the road it gives us a good migration path to the SAM3 line.

I have been a fan of the CM3 ever since it was announced and I am glad that we finally have silicon to work with. I may break down and work with the 28-SOIC LM device at home just to get some time on a CM3 processor.

Regards

Here are some links:

Article:

http://www.design-reuse.com/news/18545/ … ex-m3.html

Atmel Website:

http://www.atmel.com/products/AT91/

According to their early claims, they are looking to really increase the clock speed up near the ARM9 speeds.

I agreed with Cortex-M3 is a really good processor, and my impression is CM3 is aimed for ARM7 replacement. The CM3 "virtue" is made with the reversed disciplines; extremely short pipleline and cache less memory architecture. Note that longer pipeline and complicated cache mechanics have been the essentials of modern ultra fast processors. CM3 looks like a small blass instrument unearthed from a lost civilization while your Pentium stands high and noisely like a moutain pile of plumber works. We should wait for the arrival of A1 class to see how ARM camp approachs to win the classic speed competitions.

Toru Nishimura / ALKYL Technology

That is interesting that you mention the pipeline length. ST promotes their STR9 single-chip micros as being better than their ARM7 competitors in part because of their larger pipeline. The logic might appear backwards, however. If either pipeline remains full in theory they should essentially run the same, but just as soon as you flush the pipeline I would think you would prefer a shorter pipeline to get your pipeline full and running again.

I just pulled up the chart I read the comparison in and they make the argument that load and store regs stall out the processor on the ARM7 3-stage pipeline, but that they flow seamlessly in the 5 stage pipeline. They also claim that typically 30% of instructions are of this type. I can only guess that the CM3 may have found a way to streamline those sequences and avoid that penalty. The chart I am referring to is part of an online presentation at DigiKey:

http://dkc1.digikey.com/us/en/tod/STMic … Audio.html

Regards

The lag of the pipeline is pretty impressive on the Cortex-M3. We were synchronizing Luminary’s the other day with I/Os & spinloop, and the latency of the pipeline stall coupled with the IOs was not very pretty. It was pretty clear on the scope. About 12 cycles worth of stall…

Ouch.

I can’t recall where I saw it exactly, but I recall seeing a chart that shows Cortex-M3 performance being greater than ARM7-Thumb and even ARM7-ARM modes, but it did not compare them with ARM9 and its 5-stage pipeline (if memory serves correctly.) They also claim 1.25 DMIPS per MHz.

The goal of CM3 was to target 8 bit applications, and one way to do that is by reducing transistor count. A simplified architecture and instruction set is one way to accomplish that goal, and is true to some of the founding principles behind RISC.

I for one was surprised to see data suggesting that CM3 would be faster than ARM7, as I expected the opposite for the sake of reduced complexity and cost. If what I am reading is true, it is hard to imagine how ARM7 will have a future as manufacturers move over to CM3.

(Now if I can only get my Olimex debugger and development board up and running like I need to, I can at least join the ARM7 crowd!)

Regards

Domestic news source tells that NXP is developing their version of CM3. The product line will become LPC1700 and LPC1000. I naively feel confused about how the company aligns LPC2917/LPC3180 and LH7A product lines.

Toru Nishimura / ALKYL Technology

The Cortex-M3 has certainly created a lot of confusion in the ARM(7) market.

Another source of reasonably priced quality development tools for the Cortex-M3:

www.code-red-tech.com

Red Suite makes full use of the on-chip debug features on the M3 to show runtime trace information graphically and textually.

Unless I am mistaken, the price is 1,000 USD.

If you want free tools look to CodeSourcery Lite or a GCC Compiler from Anglia.

You can use these with free Eclispe and OpenOCD if you wish.

I can recomend FreeRTOS as a starting point.

This is the best starting point I have found :-

http://www.freertos.org/portLM3Sxxxx_Eclipse.html

Good Luck!

I had discovered that application. In fact, I have been in touch with a Luminary Micro rep about an application for work and he provided information regarding three commercial development solutions. I made him aware that it might be possible to go the route you recommended.

I am toying with the idea of using that board and environment at home. I like the LM line. I like their hardware but I also like their innovative attitude. If they need an application engineer in the Midwest of the USA, I might talk to them!

Regards

I’ve been evaluating the Rowley CrossWorks for ARM tools and I’m very favorably impressed with the results so far.

If you’re a hobbyist doing non-commercial work, a personal license is only $150, which is a bargain for a commercially-supported toolset.

SodaAnt:
I’ve been evaluating the Rowley CrossWorks for ARM tools and I’m very favorably impressed with the results so far.

If you’re a hobbyist doing non-commercial work, a personal license is only $150, which is a bargain for a commercially-supported toolset.

You do know that Rowley uses GCC?

Yep, but with its own rather good libraries. And use the debugger… I was sold.

Any new thoughts on this? I’m wanting to make the move from the LPC2000 series to the LPC1768 for my next project. I’ve been using WinArm.