Nucleo-F401RE with stlink

[jgriessen]

I've done the steps to get all the toolchain compiling and stlink compiled and executables installed
in /usr/local/bin

When I try flashing I get the nucleo st link card lights flashing green/red then staying on orange:

Code: Select all

john@ecolab3 [stmhal]make BOARD=NUCLEO_F401RE deploy-stlink
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
GEN build-NUCLEO_F401RE/genhdr/qstrdefs.collected.h
QSTR not updated
Writing build-NUCLEO_F401RE/firmware0.bin to the board via ST-LINK
2016-06-30T16:33:12 INFO /usr/local/src/stlink/src/common.c: Loading device parameters....
2016-06-30T16:33:12 WARN /usr/local/src/stlink/src/common.c: unknown chip id! 0
Makefile:316: recipe for target 'deploy-stlink' failed
make: *** [deploy-stlink] Error 255

What is the chip ID about? have I got the wrong stlink version of udev rules? I used the one for /dev/stlinkv2-1

Code: Select all

john@ecolab3 [~]ll /dev/stl*
lrwxrwxrwx 1 root root  3 Jun 29 09:38 /dev/stlinkv2-1_ -> sdb
lrwxrwxrwx 1 root root 11 Jun 29 09:38 /dev/stlinkv2-1_0 -> bsg/5:0:0:0
lrwxrwxrwx 1 root root  3 Jun 29 09:38 /dev/stlinkv2-1_2 -> sg2

I checked solder balls and jumpers and read about other cases of unknown chip id!
and tried pushing reset and then it worked fine. I tried power off and program the flash again and no
stopping, no unknown chip ID... This hangup seemed to happen only with the board programmed by ST with a
flashing lights user button program.

[dhylands]

Each chip type has a unique id, which st-link needs in order to work properly. So if it fails to read the chip id then it can't proceed.

I've had boards get into weird states and stuff and sometimes I've had to press and hold the reset button and release it just when st-link is running.

I haven't done enough investigation to know why this happens and when exactly its needed, but you might try it to see if it helps.

[jgriessen]

Thanks. Sounds like the need for reset button pushing with my friend Nathan's blink LED program is related somehow.

Is there a time period during boot that micropython listens and then if your main.py is not listening after that you can't use the serial port?
Is the problem just no serial port listening in the main program?

[dhylands]

I don't think that the serial port and the chip-id thing are related.

The stlink board actually uses the JTAG/SWD interface to talk to the board, so the chip-id not being detected is happening through that interface.

One possibility that just occurred to me would be if one of the JTAG/SWD pins were being used for some purpose that interfered with JTAG/SWD then that might cause a problem.

[nmz787]

Any tips on getting serial writes to work with this board? I tried a few things and have no luck
[quote]
#import pyb
#usb = pyb.USB_VCP()
from pyb import UART

#uart = UART(2) # init with given baudrate
uart = UART(6) # init with given baudrate
uart.init(9600, bits=8, parity=None, stop=1)


def output():
while True:
#usb.write("hello!\n")
uart.write('abc')
pyb.delay(1000)

output()
[/quote]


and the client-side script to read it:
[code]
import serial
ser = serial.Serial('/dev/ttyACM0',9600, timeout=1)
while True:
ser.readline()
[/code]

[dhylands]

It would be useful to describe what you're connecting to where.

By default, UART-2 is connected to he stlink processor, which will be advertised as /dev/ttyACM0 when plugging in the NUCLEO board to your host via USB. Also, by default, the repl runs on UART2 as well. I modified your program to use 115200 since that was the default baud rate and ran it successfully. I also uncommented he import of pyb which you'll need since you call pyb.delay:

Code: Select all

import pyb
from pyb import UART

uart = UART(2) # init with given baudrate
uart.init(115200, bits=8, parity=None, stop=1)

def output():
    while True:
        uart.write('abc')
        pyb.delay(1000)

output()

and just running it from the REPL I see:

Code: Select all

MicroPython v1.8.1-90-gab8a5d5-dirty on 2016-06-26; NUCLEO-F401RE with STM32F401xE
Type "help()" for more information.
>>> import f401_uart
abcabcabcabcabcabcabc

Now your host program calls readline, which waits for a newline, and since you don't send any, it will wait forever. You also don't print anything in your host program - you just read the data over and over in an infinite loop.

When I modified your program running on the F401 to look like:

Code: Select all

import pyb
from pyb import UART

uart = UART(2) # init with given baudrate
uart.init(115200, bits=8, parity=None, stop=1)

def output():
    while True:
        uart.write('abc\n')
        pyb.delay(1000)

output()

and I also modified your host side program to look like:

Code: Select all

#!/usr/bin/env python3

import serial
ser = serial.Serial('/dev/ttyACM0',115200, timeout=1)
while True: 
    line = ser.readline()
    print('Read', line)

then I get the following output from the host program when the F401 program is running:

Code: Select all

2044 >./f401_uart_host.py 
Read b'abc\n'
Read b'abc\n'
Read b'abc\n'
Read b'abc\n'
Read b'abc\n'
Read b'abc\n'
Read b'abc\n'

Note: If you're going to use UART-2 then you need to quit whatever program you were using for the REPL before running your host program. If you're going to use UART-6 then you need to connect a USB-to-serial adapter to the appropriate pins on the board and also use the appropriate /dev/ttyACMx for the usb--to-serial adapter.

You'll need to connect Tx from the USB-serial adapter to Rx on the F401, Rx on the USB serial adpater to Tx on the F401, and GND from the USB-serial adapter to GND on the F401.

[nmz787]

[quote="dhylands"]It would be useful to describe what you're connecting to where.

By default, UART-2 is connected to he stlink processor, which will be advertised as /dev/ttyACM0 when plugging in the NUCLEO board
[/quote]

yeah that is what I figured when I was going through the schematic from STM, and also suspected it from eyeing the traces on the board for PA2 and PA3 (they looked unconnected, as in the schematic, and by default being routed to the ST-LINK TDI and TDO pins)

That's why I tried both USB_VCP, thinking well, I guess maybe that sends JTAG-encapsulated commands when you call write on it, while the UART would have its RS232-style protocol wrapping the data.

[quote="dhylands"]I also uncommented he import of pyb which you'll need since you call pyb.delay:
[/quote]

Strangely it seems like pyb either carries over from boot.py, or it just magically is there, as I find pyb calls to work from the non-boot.py scripts that boot.py calls... without importing. Good style though for sure.

[quote="dhylands"]
Now your host program calls readline, which waits for a newline, and since you don't send any, it will wait forever.
[/quote]

Yeah I was trying all sorts of things, with ser.read() and sending different strings from the MCU side.

[quote="dhylands"]
You also don't print anything in your host program - you just read the data over and over in an infinite loop.
[/quote]

D'OH! That was the key here... I changed the device program back to UART 2, and prepended a 'print' on the client-side and voila!

Glad it was a stupid error... now back to co-routine mutlitasking for a GPIO cap-sense to LED-brightness visual-theremin!


[quote="dhylands"]
Note: If you're going to use UART-2 then you need to quit whatever program you were using for the REPL before running your host program. If you're going to use UART-6 then you need to connect a USB-to-serial adapter to the appropriate pins on the board and also use the appropriate /dev/ttyACMx for the usb--to-serial adapter.

You'll need to connect Tx from the USB-serial adapter to Rx on the F401, Rx on the USB serial adpater to Tx on the F401, and GND from the USB-serial adapter to GND on the F401.[/quote]

Thanks, I figured as much, having some prior experience with microcontrollers and JTAG.

So does this mean that USB_VCP is useless for the F401? It seems LED.intensity is also broken or not implemented... though I was able to get a busy-loop with a delay to effectively dim an LED. Thanks! Will update with visual-theremin code if/when I get it to work.

[dhylands]

The USB_VCP can be used on the 401 if you connect your own USB connector to the appropriate pins. But it will go over the USB connected to the F401, not the USB connected to the stlink processor (which is the mini-B connector on the board).

UART2 (on the 401) is connected to a UART on the 103 (what I call the stlink processor) and the mini-B USB connector is connected to the USB pins on the 103. The default software on the 103 acts like a USB-to-serial adapter (so no JTAG magic happening when in this mode).

LED.intensity will only work if there is a Timer PWM output pin connected to the LED and things have been configured properly.