BlackIce myStorm board NOT getting programmed

hatim 2017-08-15 15:50:02 UTC #1

Hello!

I am seeking help regarding the BlackIce myStorm board. Through multiple tries I have been unable to program it.

Here are the steps I follow -
0. Running on a MacBook Pro with macOS Sierra. Yosys, IceStorm, Arachne-pnr are all compiled and installed from scratch on my machine. I am using a tutorial folder, pretty_colours, from this repo. In order to get the Mac to detect the board over USB, I had to install the drivers from here. Pin 14 and 16 of the RPi headers on the myStorm board are tied using a jumper.
1. Inside the cloned repo, inside pretty_colours directory, run make clean and then make.
2. Connect the microUSB cable to the port (closest to the corner) on the BlackIce board and insert the USB-A into the USB port on the Mac. /dev/cu.wchusbserial1410 has turned up in the /dev listing.
3. In a terminal window, type stty -f /dev/cu.wchusbserial1410 115200 && cat chip.bin >/dev/cu.wchusbserial1410 while in the pretty_colours directory i just ran make in (yes, there is no space between > and / in the cat section of that command chain). Wait for it to silently complete. Cannot run screen simultaneously because otherwise it will show resource busy.
4.once stty … completes, run screen /dev/cu.wchusbserial1410 115200 and press the reset on myStorm board. screen shows "Setup done Waiting for UART" (only these two lines).

My problem is that the onboard LEDs (close to the PMOD14 section) only glow statically. If you look at the pretty_colours directory above, you'll see that it is a counter, but I just get to see a couple of red and green and blue LEDs glowing in the PMOD14 section and none of them are blinking. Most certainly the LEDs are not counting on the board.

Could anyone please help me or point me in the right direction?

Thanks a lot.

Regards,
Hatim

BigEd 2017-08-15 17:29:34 UTC #2

My machine is running an older OS so I can't even connect. But looking elsewhere on the forum, you might need 'raw' and 'cs8' as well as the speed setting:

stty raw cs8 115200 </dev/something

ken.boak 2017-08-15 18:03:06 UTC #3

Hatim,

When you plug into the microUSB socket (closest to the corner) and have a terminal program running on the MAC, when you press the reset button of the BlackIce board - are you seeing a start-up message on the screen? You should get the whole message which includes the firmware version number. The firmware should read

Mystorrm version 0.2

If you are getting version 0.1, then your board will ultimately be in need of a firmware update - but should still program at 115200 baud via the corner microUSB port - provided that you use a raw or binary file format.

Please let me know what startup/version number you get - and that will allow us to guide you.

All of the myStorm BlackIce boards distributed since July 25th will have been programmed with IceBoot firmware version 0.2.

regards

Ken

hatim 2017-08-15 18:52:35 UTC #4

Hi @ken.boak ,

I don't get any version number at the output. Here is what I do, step by step -
1. Plug in the microUSB cable into the myStorm board (port closest to the corner). Connect the other end to the USB port on the Mac.
2. Open a terminal. Run screen /dev/cu.wchusbserial1410. Press the reset button on the myStorm board. The output I get is -

Setup done
Waiting for UART

Those are the only two lines of output I get.

There is another thing I noticed with my board. The output of stty -f /dev/cu.wchusbserial is as follows (the f flag for stty on a Mac is in lowercase) -

speed 9600 baud;
lflags: -icanon -isig -iexten -echo
iflags: -icrnl -ixon -ixany -imaxbel -brkint
oflags: -opost -onlcr -oxtabs
cflags: cs8 -parenb

Shouldn't it be speed 115200 baud?

Regards,
Hatim

hatim 2017-08-15 19:01:58 UTC #5

Hi @BigEd,

I tried what you are suggesting. I did not notice anything different.

Regards,
Hatim

ken.boak 2017-08-15 19:04:53 UTC #6

If you are using the port closest to the corner - then the speed should be 115,200 baud.

However as you are getting part of the start-up message - I suggest that the terminal is missing the first part because the STM32 output is missed.

Instead of plugging fresh into the USB port each time, plug in once and press the reset switch - which is the push button on it's own next to the white power LED. This will put the STM32 through a clean reset sequence and hopefully you should see the whole message.

Please let me know if this makes any change.

Ken

hatim 2017-08-15 19:16:58 UTC #7

@ken.boak,

Yes, I am using the port closest to the corner. When I connect the other one it doesn't even turn up in the /dev/cu.* list.

This is the output I get when I try plugging in once and then pressing the reset switch -

Setup done
Waiting for UART
Setup done
Waiting for UART
Setup done
Waiting for UART

I have waited for a minute or two between subsequent resets.

Regards,
Hatim

ken.boak 2017-08-15 19:27:59 UTC #8

Hi Hatim,

It sounds like you may have an older board with an early version of firmware.

Was this the only board that Jeremy has sent to you several weeks ago - I thought that you were prioritised to get one of the new batch that were delivered in late July.

Dan Gorringe at Embecosm is also using MAC. Perhaps we can recreate your issue over here - and advise you of a fix.

I have heard that CoolTerm is often used with MAC OS - and offers the option to send files to a target device.

https://learn.sparkfun.com/tutorials/terminal-basics/coolterm-windows-mac-linux

This might help you get over your programming difficulty.

My only other suggestion is that the file is not being transmitted in it's raw binary form - and this will certainly cause it to corrupt the loading mechanism. Try to find the binary option.

The regular flashing green LED that you are seeing is an indication that the loading process has not worked correctly.

regards

Ken

ken.boak 2017-08-15 19:45:37 UTC #9

Hatim,

I have downloaded CoolTerm for windows on my old Win 7 Laptop and successfully programmed the board using CoolTerm's "Send Text File" option. Make sure you check Raw Mode for the transmit option.

Perhaps this will work on Apple

Ken

Folknology 2017-08-16 09:29:04 UTC #10

I am not sure that adding a new piece of software into the equation will help there seems to be an issue with either the bitfile being uploaded or the version of the board/firmware, it is very suspicious that the firmware is not reporting it's version, that suggests a very old board

hatim 2017-08-16 19:27:53 UTC #11

Hi @ken.boak and @Folknology ,

Dan and I spent yesterday's day getting it to work but our attempts failed and thus I turned to the forums for help. He does not use CoolTerm though.

I am very pleased to say that CoolTerm worked. When I chose to send the text file over to myStorm using port closest to corner in raw mode at 115200 baud, the green LED turned off and there was a blinking LED probably indicating that bin file was being written. Once the transfer was complete, I pressed the reset switch and it was working perfectly. But surprisingly, CoolTerm console still shows only two lines upon reset, Setup done. Waiting for UART. The version of the myStorm firmware is NOT shown in the console.

Could you explain what the problem was? What could be the factors causing the binary file to NOT be transferred properly in the non-CoolTerm method(s)? Why does the firmware version not show up upon reset? Is there a way to upgrade the firmware? How can I do it?

Thanks a lot for your time and assistance.

Best,
Hatim

Folknology 2017-08-17 08:26:57 UTC #12

Now I feel really stupid duh! I have no idea why using this software works...

ken.boak 2017-08-17 17:08:42 UTC #13

Hatim,

There have been a couple of posts on this forum on how to upgrade the firmware using the "device firmware upgrade" dfu-util application - which apparently comes with some linux distributions - but can be found here.

http://dfu-util.sourceforge.net/

There is a link on that page to the version that runs on MAC OS X.

With this you first remove the shorting jumper between pin 14 and 16 of the 2 x 13 header. This puts the ARM into "dfu" mode and allows you to send the new firmware file to the ARM via the centre USB socket.

Alternatively you can use a programmer called a ST Link and program the firmware. The ST link programmer has been widely copied in China and is very cheap to buy - alternatively it is part of every ST Microelectronics Discovery board.

A final method is to use the later Arduino IDE - which now has support for some of the STM32 M4 processors.

The current firmware (Version 0.2) is located as IceBoot.raw in this repository - some programmers require the .hex version - which is also included.

If you can't get dfu-util to work with MAC, but you have access to a Windows machine - I have a set of instructions that use the official STMicroelectronics software tools to program a device via dfu.

Let me know how you get on.

I hope this helps.

hatim 2017-08-20 04:29:27 UTC #14

@Folknology, I have checked quite a few Verilog designs and they all seem to work as expected using CoolTerm.

@ken.boak, thanks for explaining the process so well. Here is what I have done.

On Mac,

Downloaded, compiled and installed dfu-util for macOS from here. It was pretty straightforward. MacPorts and Homebrew were having some issues.
Disconnected the jumper from pins 14, 16 of RPi header, connected microUSB cable to the port closer to the RPi header and closer to the ARM chip, insert the other end into a USB port on the Mac.

In a Terminal, execute dfu-util -l -v to look for connected devices in DFU mode. The output is -

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found Runtime: [05ac:8290] ver=0146, devnum=2, cfg=1, intf=5, path="20-3", alt=0, name="UNKNOWN", serial="UNKNOWN"
Found DFU: [0483:df11] ver=2200, devnum=7, cfg=1, intf=0, path="20-1", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="206132AE3141"
Found DFU: [0483:df11] ver=2200, devnum=7, cfg=1, intf=0, path="20-1", alt=2, name="@OTP Memory /0x1FFF7000/01*0001Ke", serial="206132AE3141"
Found DFU: [0483:df11] ver=2200, devnum=7, cfg=1, intf=0, path="20-1", alt=1, name="@Option Bytes  /0x1FFF7800/01*040 e", serial="206132AE3141"
Found DFU: [0483:df11] ver=2200, devnum=7, cfg=1, intf=0, path="20-1", alt=0, name="@Internal Flash  /0x08000000/0128*0002Kg", serial="206132AE3141"

Then execute, dfu-util -s 0x08000000:leave -a 0 -v -D iceboot.raw -S 206132AE3141 in the same Terminal. Was using iceboot.raw from here, as you pointed out. Had to include -S flag because dfu-util said More than one DFU capable USB device found! Unfortunately, dfu-util throws an error at the end of the process. Here is the entire output from the execution of this command,

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Memory segment at 0x08000000 128 x 2048 = 262144 (rew)
Downloading to address = 0x08000000, size = 38480
Download	[                         ]   0%            0 bytes   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
   Poll timeout 22 ms
 Download from image offset 00000000 to memory 08000000-080007ff, size 2048
   Poll timeout 21 ms
   Poll timeout 21 ms
 Download from image offset 00000800 to memory 08000800-08000fff, size 2048
   Poll timeout 21 ms
   Poll timeout 21 ms
dfu-util: Error during download get_status

Disconnect the cable, insert it into the other microUSB port on the myStorm (closer to the corner), reconnect the jumper between pins 14, 16 of RPi header. Now when I connect the board to the Mac, I notice two things -
- once connected to CoolTerm, pressing the reset switch on the board produces NO output in CoolTerm. Earlier I used to see Setup done Waiting for UART, now I see nothing at all.
- the onboard LED lighting has changed - the green LED that used to flash is now red.

Then, I tried to upgrade the firmware on a Windows machine.

On Windows,

Install DfuSe from STMicroelectronics and related software as mentioned in this blog post.
Convert the iceboot.hex to .dfu using DfuFileMgr utility and then burn it on the myStorm board using the DfuSeDemo utility. Of course, the jumper was disconnected and microUSB cable plugged in to the middle port on the board.
The utility shows that the upload process was successful, however, the red LED is still on and there is NO output on CoolTerm.

I am worried whether the board is damaged. How do I recover from this? Could you explain what has occurred and why?

Thank you for your time and effort. That blog post was really nice.

Regards,
Hatim

ken.boak 2017-08-20 07:29:50 UTC #15

Hatim,

The dfu bootoader is permanently stored in factory programmed rom on the STM32 -so there is no chance that you will have damaged the board by unsuccessful programming

When to first attach the dfu capable device you get the dialog

Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface..

The important part here is the dfu device iD - which for the STM32l433 is 0483:df11

You should see this each time you try to connect.

If you have used the iceboot.hex and iceboot.raw from this repository

There have been minor changes this week, in the way that the STM32 presents its startup message from the port nearest the corner of the board - it only does it once following a reset.

With the usb plugged into the lower port and Coolterm set to 115200, try resetting the board with the reset button - and see if there is any output.

I will try to go through the windows ST dfuse method today to see if I can help diagnose your problem.

I did however find the last time I tried that the process was not successful every time and it took me several tries before I got the image programmed correctly.

regards

Ken

ken.boak 2017-08-20 07:40:49 UTC #16

Hatim,

One of our forum members Matthew Venn wrote up this description of how he got dfu-util to work - it may be worth looking again at his notes - and the command he used

gist.github.com

https://gist.github.com/mattvenn/293c3007fae978cfb3c3eb81c7464349

blackice.md

[Ken wrote up the process on windows here](https://forum.mystorm.uk/t/getting-started-with-windows-mystorm-for-dummies/143)

Here's how on Linux (works for Ubuntu 14).

Unplug blue jumper on pin7&8.

Plug USB cable into socket closest to ARM chip.

Use lsusb to find the device:
```

This file has been truncated. show original

regards

Ken

ken.boak 2017-08-20 09:10:38 UTC #17

Hatim,

I have now generated the .dfu file from iceboot.hex and successfully programmed it into my board here.

I have added the IceBoot3.dfu file to my github repository here:

You can download this knowing that it will work with Windows dfuse programming application.

All dfu programming worked correctly through the centre USB socket.

After dfu programming, I replaced the jumper, plugged into the lower socket - and can confirm that there is no longer any output from the lower socket - as it is now dedicated to just UART output from the FPGA.

Once you have sent the bitstream to the device using coolterm via the centre port - there will be some message back from the STM32

UART Error!
Config done
Waiting for UART or USB serial

This appears to be an interim firmware, purely to disconnect the STM32 from the UART port to give the FPGA sole access - and has not yet officially been named "Version 0.3"

Further Points:

If you use the STM dfuse application with windows, use the "Choose" option in the lower right pane of the Dfuse window to select this IceBoot3.dfu file and also make sure that you highlight the "Select Targets"

00 Internal Flash 128 Sectors

This will ensure that the internal flash is programmed. Then press the Upgrade button.

If all is well you should get a successful upgrade. You can now replace the jumper

When plugged in the centre port should appear to Windows Device Manager as STMicroelectronics Virtual Com Port

Pressing the reset switch should bring up the following message in CoolTerm - it will communicate at any baudrate you choose

Setup done
Waiting for UART or USB serial

This should get you started again.

Ken

BigEd 2017-08-21 15:15:57 UTC #18

We've tried this version (we believe!) and we don't see any difference - the FPGA still can't send data on the UART - so, do you have a high degree of confidence that it is a pre-release v3?

ken.boak 2017-08-21 16:12:27 UTC #19

Ed,

I cannot vouch for the version currently on the repository.

I'll speak to my colleagues to try to shed some light on what is currently up there.

Ken

BigEd 2017-08-21 17:55:52 UTC #20

Thanks, no rush, we've parked the use-the-serial-port and embarked on a use-the-SRAM adventure.