ARM starting platform

[newbrain]

My imaginary project needs 3 fully featured USARTs, 2 fully featured SPIs and possibly Ethernet if I can convince myself that lwIP can handle multiple concurrent connections.  You would think that is a simple answer:  Yes, No...  Something like that...  I still can't find it written down anywhere.

If you intend to use a off-the-shelf board,  have you considered this?
Ethernet, USB OTG, some leds and not much more...same MCU, detachable ST-Link 2.1.
Or even the F746 model, same price, but actually in stock at RS at least for Sweden?
Not as cheap as the smaller Nucleos, but still decent value.

Edit:
It seems that lwIP can support multiple TCP connections, from /.../.../opt.h:

Code: [Select]

/**
 * MEMP_NUM_TCP_PCB: the number of simultaneously active TCP connections.
 * (requires the LWIP_TCP option)
 */
#ifndef MEMP_NUM_TCP_PCB
#define MEMP_NUM_TCP_PCB                5
#endif

/**
 * MEMP_NUM_TCP_PCB_LISTEN: the number of listening TCP connections.
 * (requires the LWIP_TCP option)
 */
#ifndef MEMP_NUM_TCP_PCB_LISTEN
#define MEMP_NUM_TCP_PCB_LISTEN         8
#endif
But I have never used it (yet...).

[Sal Ammoniac]

Why?  I don't care for single-stepping and even though I am migrating toward the STM32F4 boards with ST-Link, I seem to get my stuff to work with just simple printf() statements.

Right. You can dig a pretty big hole with a shovel too, but I'd rather use a backhoe.

[Aodhan145]

integrated IDE around eclipse/gcc 

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!
That is precisly what I am recommending you do not do.
I have used
Code worrier - slow and cumbersome,
Atollic - slow and cumbersome,
VxWorks Workbench

Hate all of them with a passion
www.ihateeclipse.com

With ALL Eclipse embedded integrations, you cannot tell when debugging if the micro has locked up on or if Eclipse has just decided to go off and do some studpid useless background task!

TI's Code Composer Studio is very nice and I have had no problems but I run on a very powerful system. Maybe it is just your computer isn't powerful enough and thats why light weight ones run better.

[alin_im]

Do you think if I extend my price range to 40 - 50 euros I can find something superior like a full development board, something like Microchip Explorer 16, but for ARM ? I do not think at this price.

I am thinking that maybe it is ok to invest a little bit more expensive now but to have benefits in the long run, then buying now a 20 euros platform and change it after 6 months because I need something else.

I am a little bit confused at the moment with all the compilers and errors or limitations. I want something that is budget friendly, has no IDE problems, some sensors and LCD and it is based on ARM.

 

[MosherIV]

  Do you think if I extend my price range to 40 - 50 euros I can find something superior like a full development board, something like Microchip Explorer 16, but for ARM ? I do not think at this price.

I am thinking that maybe it is ok to invest a little bit more expensive now but to have benefits in the long run, then buying now a 20 euros platform and change it after 6 months because I need something else.

I am a little bit confused at the moment with all the compilers and errors or limitations. I want something that is budget friendly, has no IDE problems, some sensors and LCD and it is based on ARM.

No, your stated goal is to improve your coding skill. For learning to program, it does not really matter how much the boards cost, just that they are easy to use/develop on. Picking mbed compatible boards pretty much covers that. The more expensive boards are aimed at commercial companies that want to tailor the boards into early prototypes.

If on the other hand you have a specific project in mind, then you should work out the project requirments are and get a board that has as much as that project needs. In other word, what kind of peripherals will the project need? Work out which board has those peripherals and get that one.

Yes, sorry about all the debate on which tool is best. It is down to personal preference. There are a number of tools which should work without much setup effort. As a professional embedded software engineer, I do not have time to mess around with freeware tools that may do the job, I am interrested in tools that will work straight away and NOT waste my time. I have pretty bad experiences with commercial tools based around the open source Eclipse toolset hence I prefer not to use ANY tool that is Eclipse based, however that is not to say that all of them are bad or will not work.  I can tell you NOT to bother with the free version of Atollic, has the same code size limitations as IAR but with all the issues that put me off Eclipse. The code size limit should not be a problem if you are just doing tutorial projects, it will only be a problem if you are working on a medium to large project (you can get FreeRtos and some functiinality in the 32K!). I suggest you have a quick look at the web sites for the tools that you are interrested in, if you have used tools before in the past this may help you pick the tool which best fits with the one you used before. Otherwise, try one and see how you get on.

Make sure the tool you pick allows you to compile, download, debug, shows high level code and assembler with symbolic debugging, single step, examine and change variables and registers, examine memory and place break points.

[alin_im]

  Do you think if I extend my price range to 40 - 50 euros I can find something superior like a full development board, something like Microchip Explorer 16, but for ARM ? I do not think at this price.

I am thinking that maybe it is ok to invest a little bit more expensive now but to have benefits in the long run, then buying now a 20 euros platform and change it after 6 months because I need something else.

I am a little bit confused at the moment with all the compilers and errors or limitations. I want something that is budget friendly, has no IDE problems, some sensors and LCD and it is based on ARM.

No, your stated goal is to improve your coding skill. For learning to program, it does not really matter how much the boards cost, just that they are easy to use/develop on. Picking mbed compatible boards pretty much covers that. The more expensive boards are aimed at commercial companies that want to tailor the boards into early prototypes.

If on the other hand you have a specific project in mind, then you should work out the project requirments are and get a board that has as much as that project needs. In other word, what kind of peripherals will the project need? Work out which board has those peripherals and get that one.

Yes, sorry about all the debate on which tool is best. It is down to personal preference. There are a number of tools which should work without much setup effort. As a professional embedded software engineer, I do not have time to mess around with freeware tools that may do the job, I am interrested in tools that will work straight away and NOT waste my time. I have pretty bad experiences with commercial tools based around the open source Eclipse toolset hence I prefer not to use ANY tool that is Eclipse based, however that is not to say that all of them are bad or will not work.  I can tell you NOT to bother with the free version of Atollic, has the same code size limitations as IAR but with all the issues that put me off Eclipse. The code size limit should not be a problem if you are just doing tutorial projects, it will only be a problem if you are working on a medium to large project (you can get FreeRtos and some functiinality in the 32K!). I suggest you have a quick look at the web sites for the tools that you are interrested in, if you have used tools before in the past this may help you pick the tool which best fits with the one you used before. Otherwise, try one and see how you get on.

Make sure the tool you pick allows you to compile, download, debug, shows high level code and assembler with symbolic debugging, single step, examine and change variables and registers, examine memory and place break points.

Thank you very much for all the help and support. I will have another look on the boards and I think I will go with a one that is compatible with mbed and IAR.

[janoc]

In the early years of OpenOCD, getting a setup to work was akin to magic.  This was back, say, 10 years ago.  Give or take...
I haven't tried since and probably never will again.  But, yes, it's my fault...  There were simply too many parameters and far too many combinations...

...

If I ever get to a point where I can't get my code to run and I am truly desperate, I might try again.

All you need to do (assuming you have OpenOCD and gdb installed):

1) Create a file called openocd.cfg to save you typing parameters (this is using the ST32F042 Nucleo board with built-in STLink):
---- cut ---
source [find interface/stlink-v2-1.cfg]
transport select hla_swd
source [find target/stm32f0x.cfg]
---- cut ---

The interfaces and targets you can find either in the documentation or just look in the folder where OpenOCD was installed - there are interface and target subdirectories containing files for both the interfaces (dongles) and targets. If you want JTAG transport, just put jtag instead of hla_swd. OpenOCD ships with these files for many common devboards, including the Nucleos and Discoveries, so just look there and adapt one if you don't find a matching one.


2) Run openocd in this folder (I am on linux, adapt to your OS as needed):
$ openocd
Open On-Chip Debugger 0.9.0 (2015-05-26-21:40)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.238497
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints

3) And that's all - OpenOCD is talking to the board. Now you can either connect to OpenOCD by using telnet and use the command line interface to do things like flash the board, start/stop the cpu, use boundary scan or whatever. That's:

$ telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
>

4) Now you can flash your micro (it is possible to do it from gdb too, though). Type at the OpenOCD prompt:

init
reset halt
flash write_image erase absolute-path-to-your-bin-file 0x08000000
verify_image erase absolute-path-to-your-bin-file 0x08000000
reset run

And that's it. Just make sure you are not trying to flash the .elf file. You must flash a raw binary, not elf. And use full path, because otherwise it is relative to the folder where you have started OpenOCD from.


Most often you don't want to use that, except maybe for programming from a script.
However, gdb is just as simple:

1) Build your code with debug symbols (-g flag for GCC, you will likely want -O0 to disable optimization too)

2) Run ARM (or whatever you are debugging) gdb:

$ arm-none-eabi-gdb my-code.elf
GNU gdb (GDB) 7.10
<... snipped a lot of blurb ...>
Reading symbols from my-code.elf ...done.
(gdb)

3) now type at the (gdb) prompt:
(gdb) target extended localhost:3333
Remote debugging using localhost:3333
reset_handler () at ../../cm3/vector.c:68
68              for (src = &_data_loadaddr, dest = &_data;

(gdb) monitor reset halt
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x080012e0 msp: 0x20001800

(gdb)

4) And that's all. The first (target) command connects gdb to OpenOCD which acts as a driver for the JTAG/SWD dongle talking to your target and the second (monitor) command resets and halts the target, so that  you are starting from a defined state and not from somewhere in the middle of the code wherever the CPU was when it was halted by OpenOCD/gdb.

I have these commands in my .gdbinit file, so I don't have to retype them. If you are using an IDE, you can usually specify commands like this in the dialog box where one configures GDB (e.g. Eclipse has it)

5) Now you can start debugging - type "tb main" to set temporary breakpoint on main and "run" to start the code. The "load" command will flash the binary to the target.

Btw, CTRL+x a (press ctrl and x together, release, then press a) will give you a text UI in case you are debugging from command line directly.

There is nothing mysterious about these tools. The only problem used to be OpenOCD's documentation, but that has improved a lot in the recent years.

[nctnico]

Make sure the tool you pick allows you to compile, download, debug, shows high level code and assembler with symbolic debugging, single step, examine and change variables and registers, examine memory and place break points.

I never used something like that in the last 20 years. It is very useful to check startup code but if you need to debug a working microcontroller application printfs and status commands showing statistics go much further because they can stay in the firmware and be used as a diagnostic tool as well. In general you can't stop a microcontroller program without interrupts pilling up and tearing everything to shreds once the debugger lets go. Also you can't do meaningfull debugging on optimised code because the relationship between a line in a source file and location in the binary is gone. However with optimisation off the program will run magnitudes slower and will be significantly bigger (will it fit in flash?). All in all there really isn't any use for a debugger on a microcontroller. The low level hardware stuff you debug using collecting runtime statistics and wiggling IO ports connected to a logic analyser/scope. The high level stuff you develop on a PC. This is also where the comb GCC+ Eclipse comes in strong. With Eclipse + GCC you can compile, debug and verify your code on a PC and then compile for your microcontroller without needing to changes due to C compiler specific extensions.

[janoc]

nctnico, we all know you are superhuman and debuggers are for pussies, but most do prefer to have a debugger available. I also knew one programmer like that that never needed debugger and debugged everything with printfs and a pencil on paper printouts of the code. It took him days to discover what another developer solved in 10 minutes by calling a debugger.

[rstofer]

In the early years of OpenOCD, getting a setup to work was akin to magic.  This was back, say, 10 years ago.  Give or take...
I haven't tried since and probably never will again.  But, yes, it's my fault...  There were simply too many parameters and far too many combinations...

...

If I ever get to a point where I can't get my code to run and I am truly desperate, I might try again.

All you need to do (assuming you have OpenOCD and gdb installed):

1) Create a file called openocd.cfg to save you typing parameters (this is using the ST32F042 Nucleo board with built-in STLink):
---- cut ---
source [find interface/stlink-v2-1.cfg]
transport select hla_swd
source [find target/stm32f0x.cfg]
---- cut ---

The interfaces and targets you can find either in the documentation or just look in the folder where OpenOCD was installed - there are interface and target subdirectories containing files for both the interfaces (dongles) and targets. If you want JTAG transport, just put jtag instead of hla_swd. OpenOCD ships with these files for many common devboards, including the Nucleos and Discoveries, so just look there and adapt one if you don't find a matching one.

...

Thanks for the tutorial!  Seriously!  I have cut the text to a file where I can study it later.

[nctnico]

nctnico, we all know you are superhuman and debuggers are for pussies, but most do prefer to have a debugger available. I also knew one programmer like that that never needed debugger and debugged everything with printfs and a pencil on paper printouts of the code. It took him days to discover what another developer solved in 10 minutes by calling a debugger.

Well you can use printf to dump a stacktrace if you want! I have that enabled for the hard and bus fault interrupts on ARM.

[janoc]

Thanks for the tutorial!  Seriously!  I have cut the text to a file where I can study it later.

Welcome. However, there are plenty of OpenOCD/gdb oriented tutorials online, ARM micros are more popular than ever, so people use it.

OpenOCD is an interesting tool for boundary scan via JTAG as well. It can talk to (some) CPLDs and FPGAs as well, so you can use e.g. Xilinx XC59xxXL series CPLD as both a piece of logic in your system and also as a probe to poke the bus or memory through JTAG without having to design in a dedicated interface - you have it for free in the system already.

I suggest also looking up some gdb tutorials and documentation, most people don't know that gdb can actually execute your code backwards as well - allowing you to step back from e.g. an error handler to where the problem has actually occurred. It doesn't work on all targets, but I believe ARM should be supported.

[janoc]

Well you can use printf to dump a stacktrace if you want! I have that enabled for the hard and bus fault interrupts on ARM.

I prefer to actually put a breakpoint in the handler and investigate the issue while the system is still alive with memory and registers intact than have to do it postmortem from a trace, if possible. Stacktraces have their place, but are far from the fastest way of debugging such issue.

[dannyf]

If you intend to make a living off of this experience, I would encourage you to take a look at keil or iar or both actually, especially for cm0 where unlimited versions of keil exist for stm32f0 chips.

You have to remember that the cores are pretty much transparent to a C programmer. So it really don't matter if you are training your teeth on a çm0 or a cm4 chip. The key is to understand basic steps to set up a project and learn good coding habit.

From that perspective, don't get too tied up in the details.

[nctnico]

Well you can use printf to dump a stacktrace if you want! I have that enabled for the hard and bus fault interrupts on ARM.

I prefer to actually put a breakpoint in the handler and investigate the issue while the system is still alive with memory and registers intact than have to do it postmortem from a trace, if possible. Stacktraces have their place, but are far from the fastest way of debugging such issue.

But what if a device produces a hard fault (99.9% caused by a pointer problem) suddenly or randomly? With the debugger disconnected or breakpoints set at a different address you'll miss the event and/or don't have any data to analyse. Having the hardfault handler print a trace (the last 16 items on the stack which includes the contents of the registers) has saved my bacon so many times already (usually when including 3rd party code) that it is a standard part of my firmware.

[jokkydee]

Nonsense. I've used Eclipse extensively to develop for and debug on ARM Cortexes and I've never once had Eclipse "lock up". Do you have some specific evidence, or are you relaying anecdotal tales? Perhaps the Eclipse-based tool you've used wasn't configured correctly.

IMO most of the hate directed at Eclipse is due to vendors taking the base Eclipse and integrating every piece of plug-in garbage they can find in some lame attempt to make it more useful. All of those dodgy plug-ins just serve to make Eclipse slow and unstable. I use the bare cones Eclipse with only the CDT add-ons and it's both fast and stable.

I read a post from you earlier this year;

Just to clarify, I really like the look and feel of Eclipse. I like its window layout and I like its editor. I like just about everything about it except its performance. That's always the stumbling block for me. It just feels so sluggish and unresponsive after using something like CrossWorks.

It seems your opinion of Eclipse has changed quite dramatically since then. Does this mean you sorted out the performance issues?

[zapta]

Thank you for the reply.

The Disco is compatible with mbed: https://developer.mbed.org/platforms/ST-Discovery-L476VG/

I will have a look at IAR but I know that the free version has 32kB limit (16kB for M0+) and lets say I am not the best programmer in terms of code optimization, but I think this will force me to be.

Do you recommend other platforms at this price (20 euros) ?

I have had good experience with this board

http://www.embeddedartists.com/products/boards/lpc11u35_qsb.php

mbed compatible, single package install lpcxpresso IDE (free, eclipse based, mac, linux, windows), USB bootloader (easy firmware download, no software or special software required), simple design (easy to convert to your own custom designs).

Open source design of a similar board here https://github.com/zapta/arm/tree/master/pro-mini and it's trivial to use in your own custom PCBs https://github.com/zapta/arm/blob/master/pro-mini/board/arm-pro-mini-schematic.pdf 

[Canis Dirus Leidy]

I wanted a platform that is compatible with mbed.com because I want to start with that and the progress to IAR or GCC.

The STM board is a much powerful Cortex M4 instead of a M0+, but at this point I do not think it matters because I do not have a project in mind which requires features that M4 has and M0+ hasn't. I just want to start working with ARM 32 bit micros and "master" the interrupts and timers and communication protocols (SPI, I2C and UART especially).

I was thinking of purchasing one of those 2 boards: STM32L476G-DISCO or NXP FRDM-KL46Z. What do think or recommand ?

One of these cheap breadboard-friendly Chinese boards?

[dannyf]

One of these cheap breadboard-friendly Chinese boards?

I have used a ton of those boards. Best bang for your buck.

[alin_im]

I wanted a platform that is compatible with mbed.com because I want to start with that and the progress to IAR or GCC.

The STM board is a much powerful Cortex M4 instead of a M0+, but at this point I do not think it matters because I do not have a project in mind which requires features that M4 has and M0+ hasn't. I just want to start working with ARM 32 bit micros and "master" the interrupts and timers and communication protocols (SPI, I2C and UART especially).

I was thinking of purchasing one of those 2 boards: STM32L476G-DISCO or NXP FRDM-KL46Z. What do think or recommend ?

One of these cheap breadboard-friendly Chinese boards?

I want something with more functionality with sensors included to eliminate the hardware wiring and focus on the software. I find that NXP and STM are giving the best low cost platforms at this point. For future projects I will use only the uController but for the moment I want to learn to program better and more efficient.

Thank you for the suggestion though.

[rstofer]

I was playing with my trusty old mbed LPC1768 (the original) along with the Application Board:
https://developer.mbed.org/components/mbed-Application-Board/
https://developer.mbed.org/platforms/mbed-LPC1768/

I only really wanted to use the Ethernet port but I did play around with the LCD and the accelerometer.  There is a ton of sample code in the Handbook:
https://developer.mbed.org/handbook/Homepage

Thirty lines of code to make a TCP server that I can connect to with PuTTy on a PC.  A really nice framework for such programs.

[janoc]

But what if a device produces a hard fault (99.9% caused by a pointer problem) suddenly or randomly? With the debugger disconnected or breakpoints set at a different address you'll miss the event and/or don't have any data to analyse. Having the hardfault handler print a trace (the last 16 items on the stack which includes the contents of the registers) has saved my bacon so many times already (usually when including 3rd party code) that it is a standard part of my firmware.

 That's certainly one solution, however one I see more useful in the field on a deployed system than during development.

Another way of doing it is to use the record feature in gdb and reverse debugging. Have a look at this video:
http://undo.io/resources/presentations/cppcon-2015-greg-law-give-me-15-minutes-ill-change/

He is solving a similar problem - a semi-random crash. He puts a breakpoint in the exit handler, watchpoint on the memory location that is being changed and tells gdb to record the behaviour of the code. And then when the bug happens, he can just walk it back right to the code that has triggered it.

I haven't tried this with the hard fault handler on ARM, but don't see why it shouldn't work.

[nctnico]

But what if a device produces a hard fault (99.9% caused by a pointer problem) suddenly or randomly? With the debugger disconnected or breakpoints set at a different address you'll miss the event and/or don't have any data to analyse. Having the hardfault handler print a trace (the last 16 items on the stack which includes the contents of the registers) has saved my bacon so many times already (usually when including 3rd party code) that it is a standard part of my firmware.

 That's certainly one solution, however one I see more useful in the field on a deployed system than during development.

Another way of doing it is to use the record feature in gdb and reverse debugging. Have a look at this video:
http://undo.io/resources/presentations/cppcon-2015-greg-law-give-me-15-minutes-ill-change/

He is solving a similar problem - a semi-random crash. He puts a breakpoint in the exit handler, watchpoint on the memory location that is being changed and tells gdb to record the behaviour of the code. And then when the bug happens, he can just walk it back right to the code that has triggered it.

I haven't tried this with the hard fault handler on ARM, but don't see why it shouldn't work.

I can't watch the video from where I'm now but I assume he's using the backtrace functionality of GDB. Because the amount of data pushed onto the stack for each function is known it is not difficult for a debugger to trace the execution back and determine the function's parameters. I use this often when I need to trace the origion of a problem but always for code running on a PC. However I don't see why this shouldn't work with an embedded target (as long as the stack didn't get corrupted).

[alin_im]

I think I will go with the NXP FRDM-KL46Z because has everything I need at the moment and it is accessible in terms of price (about 15 -20 euros).

I have 2 offline compilers to choose from Keil and IAR what do you recommend ? What is most used in industry ?

[janoc]

I can't watch the video from where I'm now but I assume he's using the backtrace functionality of GDB. Because the amount of data pushed onto the stack for each function is known it is not difficult for a debugger to trace the execution back and determine the function's parameters. I use this often when I need to trace the origion of a problem but always for code running on a PC. However I don't see why this shouldn't work with an embedded target (as long as the stack didn't get corrupted).

You are assuming incorrectly. Backtrace is one thing, but won't help you any for a problem like he is solving - a stack smash.

He is using the reverse debugging feature of gdb - you record the execution of the code, gdb records changes to registers and such, and then you can step the code backwards. Here is a tutorial for that: https://www.sourceware.org/gdb/wiki/ProcessRecord/Tutorial

This certainly works on x86 native code and should work with Linux on ARM too, not sure whether native code on bare-metal ARM is supported.