New from ST: "Nucleo" boards

[jcw]

I wonder if these new boards are covered by the same evaluation license as discovery?

On the card shipped with the product is a reference to http://www.st.com/epla - seems to be unchanged, although I doubt that the "by using ... you accept ..." phrasing can be enforced.

-jcw

[JohnL]

Has anyone had any luck running the STML32 discovery demo code on the nucleo L152?

[Giovanni]

Hi,

Small update, I am committing demos for the INEMO-M1 and NUCLEO boards. So far the F401, F103 and F030 are done. I am working on the L152 but I don't have a F302 so I will not be able to test it.

The nice thing about those NUCLEO boards is that it is a single board, the very same PCB with just different devices mounted (differences are handled by few solder bridges).

The schematic is a good example about how to do a "universal" STM32 board.

The code is in the 2.6.x branch, I will port it to 3.0 during the weekend.

Giovanni

[klpauba]

Hi,

Small update, I am committing demos for the INEMO-M1 and NUCLEO boards. So far the F401, F103 and F030 are done. I am working on the L152 but I don't have a F302 so I will not be able to test it.

[snip]
Giovanni

Giovanni (or anyone else),

I'm a beginner with ChibiOS-RT. I was wondering if you have the demo files that you used to test the L152RE board. I copied/modified some chconf.h, halconf.h and mcuconf.h files from your release of a month or so ago but I can't get a blinky app working. I have managed to program it with openocd and I've been using DDD with the GCC Arm Embedded toolchain but it enters an infinite loop in _port_irq_epilogue(void) (as far as I can tell). I cloned the current git repository and recompiled but the behavior remains the same.

Thanks!

[Giovanni]

Hi,

Support for that board is the repository under the 2.6.x branch, including an untested demo.

I've been unable to program the L152 (no problems with the others) using the latest OpenOCD, which configuration file are you using?

Giovanni

[klpauba]

I'll give the 2.6 branch a try then. Thanks.

Here's my openocd version and configuration file -- again, take the configuration with a grain of salt with me being a newbee but I was able to issue a "monitor load ..." command and it appeared to work.

Code: Select all

[pauba@localhost test (master)]$ openocd -v
Open On-Chip Debugger 0.8.0 (2014-05-15-12:53)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.sourceforge.net/doc/doxygen/bugs.html


[pauba@localhost test (master)]$ cat nucleo.cfg 
# This is an Nucleo-l152RE board
# 

source [find interface/stlink-v2-1.cfg]

set WORKAREASIZE 0x2000
# source [find target/stm32lx_stlink.cfg]
source [find target/stm32lx_dual_bank.cfg]

# use hardware reset, connect under reset
reset_config srst_only srst_nogate

[pauba@localhost test (master)]$ cat /usr/local/share/openocd/scripts/interface/stlink-v2-1.cfg
#
# STMicroelectronics ST-LINK/V2-1 in-circuit debugger/programmer
#

interface hla
hla_layout stlink
hla_device_desc "ST-LINK/V2-1"
hla_vid_pid 0x0483 0x374b

[klpauba]

Hi,

Support for that board is the repository under the 2.6.x branch, including an untested demo.
[snip]
Giovanni

Well, consider the demo tested! I cheated and copied the binary to the USB file system (I'll try openocd next).

Code: Select all

[pauba@localhost ARMCM3-STM32L152RE-NUCLEO ((d5648b9...))]$ /usr/local/bin/socat READLINE /dev/ttyACM0,echo=0,raw,crlf,nonblock,b38400
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 1.3 (Threads, priority change)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 1.4 (Threads, delays)
--- Result: SUCCESS
--------------------------------------------------- Score : 101109 msgs/S, 202218 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.4 (Benchmark, context switch)
--- Score : 435560 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.5 (Benchmark, threads, full cycle)
--- Score : 78453 threads/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.6 (Benchmark, threads, create only)
--- Score : 114161 threads/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.7 (Benchmark, mass reschedule, 5 threads)
--- Score : 31628 reschedules/S, 189768 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.8 (Benchmark, round robin context switching)
--- Score : 222720 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.9 (Benchmark, I/O Queues throughput)
--- Score : 321480 bytes/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.10 (Benchmark, virtual timers set/reset)
--- Score : 353884 timers/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.11 (Benchmark, semaphores wait/signal)
--- Score : 461528 wait+signal/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.12 (Benchmark, mutexes lock/unlock)
--- Score : 321708 lock+unlock/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.13 (Benchmark, RAM footprint)
--- System: 468 bytes
--- Thread: 72 bytes
--- Timer : 20 bytes
--- Semaph: 12 bytes
--- EventS: 4 bytes
--- EventL: 16 bytes
--- Mutex : 16 bytes
--- CondV.: 8 bytes
--- Queue : 36 bytes
--- MailB.: 40 bytes
--- Result: SUCCESS
----------------------------------------------------------------------------

Final result: SUCCESS

Simply AWESOME! Thanks!

[klpauba]

Works with openocd too. Here's a snippet from my session:

Code: Select all

(gdb) monitor flash write_image erase build/ch.bin 0x08000000 bin
auto erase enabled
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20014000
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20014000
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20014000
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20014000
wrote 28672 bytes from file build/ch.bin in 4.447694s (6.295 KiB/s)
(gdb) reset
Undefined command: "reset".  Try "help".
(gdb) monitor reset

[jcw]

I'm not succeeding in getting the Nucleo F103RB to work with Chibios v3 - sample code:

Code: Select all

#include "ch.h"
#include "hal.h"

int main () {
  halInit();
  chSysInit();

  palSetPadMode(GPIOA, GPIOA_LED_GREEN, PAL_MODE_OUTPUT_PUSHPULL);
  
  while (true) {
    palTogglePad(GPIOA, GPIOA_LED_GREEN); // updated, thx @tectu
    chThdSleepMilliseconds(500);
  }

  return 0;
}

I verified that the internal oscillator is being used:

Code: Select all

#define STM32_NO_INIT                       FALSE
#define STM32_HSI_ENABLED                   TRUE
#define STM32_LSI_ENABLED                   FALSE
#define STM32_HSE_ENABLED                   FALSE
#define STM32_LSE_ENABLED                   FALSE

Compiles ok, but the "L2" LED on PA5 stays off, is there anything else I need to do / check?

-jcw

[Tectu]

Compiles ok, but the "L2" LED on PA5 stays off, is there anything else I need to do / check?

When I remember correctly you have to manually change the PLL values to work with the HSI clock speed. What is happening for your right now is that the CPU is working but just very slow (probably at a few kHz).

Side note: I always use palTogglePad() to save time when writing these test cases.


~ Tectu