Unfortunately, the iCEcube2 download server is currently down ...
EDIT: in fact, it was simply a broken URL, I've been able to fix it manually and actually download the Linux version.
i've finally suceeded in upload a bitstream into the upduino FPGA SRAM, from my Cubieboard A10 based SBC
here a
about it..
the main issue about the connection is related documentation and use cases. Gnarly Grey doesn't describe deeply enough how one is supposed to drive the SPI interface for the two main tasks at hand:
- programming the FPGA internal SRAM for a quick test
- writing a bitstream in the external SPI flash for stable design to boot at each reset
the data flow is completely different from one case to the other.
me, i've actually tackled only th first one, also because it's the only one supported in the so called
Raspi Programmer examplri suppose for writing the SPI flash you'll need some kind of protocol to access the SPI flash registers (and eventually erase each page in advance..)
i'll try to take a stab to this SPI flash writing step before making a code drop on github.. BTW the code is currently using direct MMAP access to A10/A20 GPIO's so it's pretty dedicated to these SOCs..
Thanx for the tips on linux
Here's one in return
To make bash the default shell do this
sudo dpkg-reconfigure dash
And select No when it asks whether to use/install dash as /bin/sh.
/Bingo
Just got my board , and did a quick test on a Raspi3
The led blinks , but i get an error about CDONE still being low
running =3
running 1
running =3
CDONE is Low! Configuration Error!
bingo@raspi4:~/lattice $
Has anyone else tried a Raspi as programmer ??
Hmm seems like CDONE is not connected if one follows his wiring guide for Raspi , it seems only to be connected on TP2
/Bingo
yeah, i've been told that CDONE is missing and it was a miss.
that Raspi prog should be good also for the next "incarnation"
Upduino v2 that has a MCU on board too and should "complement" the offering.
anyway IMHO it's not a big deal.. still one could use a GPIO to assess when the bitstream is running on the device, a hackish work around..
yeah, i've been told that CDONE is missing and it was a miss.
anyway IMHO it's not a big deal.. still one could use a GPIO to assess when the bitstream is running on the device, a hackish work around..
Naah .. I'll just snag it from TP2
Will see if i can do it during this weekend
That V2 looks nice too , wonder what MCU will be onboard (Hopefully something w. USB onboard)
Ie. a STM32 , the STM32F103 is approx 1$. Even cheaper than an Atmel w. USB.
/Bingo
And now with CDONE connected to RPI pin 15
running 2
running 1
running =3
CDONE is High! End of Configuration!
bingo@raspi4:~/lattice $
Edit : But it doesn't function (aka no led blinks)
It works if i disconnect CDONE
Edit2:
Seems like the fpga wants 2 dummy bytes after CDONE goes high , now it works.
if ((pdone==0) && (bcm2835_gpio_lev(CDONE)==HIGH)) {
//The fpga doesn't start wo. sending 2 extra dummy bytes
sendbyte (0);
sendbyte (0);
printf("CDONE is High! End of Configuration!\n");
pdone = 1;
break;
/Bingo
I find it a bit strange that the "text header" in the beginning of the bin file gets sent to the fpga.
But i haven't read any of the DS doc yet
/Bingo
I find it a bit strange that the "text header" in the beginning of the bin file gets sent to the fpga.
But i haven't read any of the DS doc yet
/Bingo
The chip just hunts for a signature (0x7EAA997E) that must occur within 'x' bytes of the start of down/upload. You can trim off the header if you really want to and it should all work the same.
Ahh thnx
Just found the same on pg. 18 in the programming doc
http://www.latticesemi.com/view_document?document_id=46502Any idea why the 2 extra dummy bytes are needed ?
I'll read on in the prog manual , but if you know ....
Ahh... seems like this might be the reason (pg. 19)
But 2 bytes isn't 49 cycles.
Maybe i should just throw 8 dummy bytes after it, to be sure.
Attached a new Rpi archive w. makefile
/Bingo
Here's a fpga reset Rpi prog , for when you have had enough of the blinking.
Removing +5v doesn't stop it from running, still blinking in a strange pattern though.
And i'm to lazy to reset via JP1
Maybe we should tristate (input) all the SPI pins , must be where it gets the "phantom power from" or
/Bingo
Just threw a program together , that can program the FPGA from the binary outputfile.
Usage : ./fprog <binfilename>
It was made as a proof of concept ,and i didnt even bother to debug why getopt didn't work on the Rpi , it did on my Mint.
I just skipped getopt and hardcoded it to use last argument as binfilename.
Well it seems to work , but is something of a copy/paste kludge.
Binfiles are found here (for the original proj)
.../RGB_LED_BLINK_20170606/rgb/rgb_Implmnt/sbt/outputs/bitmap
/Bingo
I found Diamond programmer to be a bit cumbersome to use so I made this very simple iCE40 programmer for FTDI C232HM MPSSE cable.
https://github.com/siorpaes/iCE40progIt does all the job: resets FPGA, puts it in SPI slave mode and pushes the bitstream. Tested with UPDuino board on Ubuntu and Cygwin.
David
i published my programmer too here:
https://github.com/aventuri/iceProgrammerthe good thing is that can
upload bitstream both on FPGA SRAM for volatile tests, and on FLASH NOR (for fixed design). with different commands. it borrows the skeleton from
icoprog (that was Raspberry only).
the bad thing is that it's currently working on
Allwinner SOC ony and the pins are hardcoded because i wanted the less dependancy possible, so used memory map access to pins (no device tree..) and runs as root.
hope it's useful..
i'll enhance when i'll decide it's not good enough, now i want to start playing with FPGA designs..
i published my programmer too here: https://github.com/aventuri/iceProgrammer
the good thing is that can upload bitstream both on FPGA SRAM for volatile tests, and on FLASH NOR (for fixed design). with different commands. it borrows the skeleton from icoprog (that was Raspberry only).
the bad thing is that it's currently working on Allwinner SOC ony and the pins are hardcoded because i wanted the less dependancy possible, so used memory map access to pins (no device tree..) and runs as root.
hope it's useful..
i'll enhance when i'll decide it's not good enough, now i want to start playing with FPGA designs..
Nice ..
In order to use the flash , did you "turn/flip" the two resistors ?
How do you connect the Alwinner mosi/miso when doing fpga-ram vs fpga-flash ?
Don't you have to "reverse" miso/mosi when doing ram vs flash ?
/Bingo
just two notes about the HW setup:
- i didn't modify any resistor.
- the wires between A20 and FPGA board do not have to change for writing to FLASH or to FPGA SRAM
- indeed, when writing to SRAM, you need to write on MISO (as the FPGA, if SS low on CRESET posedge, stay listening for a bitstream there),
this change is made inside the program, of course.. - then, when writing to SRAM, i keep high the SS to keep FLASH Hiz
- then, when writing to FLASH, i keep CRESET down to keep FPGA Hiz
- i closed the jumper on the left of the "programming 6x pin connector
BTW i dumped also the FLASH before writing, and i found the strings of a Cisco switch firmware: CN=CiscoSystems;OU=Nexus9k;O=CiscoSystems
it looks like the flash are refurbished (desoldered?) parts by the assembly factory? who knows..
I got a strange behavior :
It is working fine for uploading in SRAM, but I'm unable into FLASH, although I've the jumper on SS
It loops forever on writting sectors ...
root@micro:~/git-work/iceProgrammer# ./programmer -f < RGB_LED_BLINK_fast.bin
flash id: 00 c0 80 00 00 02 10 42 00 00 00 00 00 00 00 84 00 00 00 00
writing 101.71kB..
0% @000000 erasing 64kB sector..
0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0% @000000 erasing 64kB sector..
0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0% @000000 erasing 64kB sector..
0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0% @000000 erasing 64kB sector..
0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Also, after doing a Ctrl-C and retrying, the FlashID seems to be destroyed :
root@micro:~/git-work/iceProgrammer# ./programmer -f < RGB_LED_BLINK_fast.bin
flash id: 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
writing 101.71kB..
0% @000000 erasing 64kB sector..
0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0% @000000 erasing 64kB sector..
0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
I guest I will have to desolder this flash and resolder a new one ...
EDIT :
I've try my second modules, still getting this strange flash id "00 c0 80 00 00 02 80 80 01 80 00 00 18 00 21 01 fc 00 00 00"
So, I decided to replace the flash of the first one with Winbond W25Q32, and now the flash id make sense "ef 40 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00", and I was able to flash bitstream this time.
So, I bet that original flash is a strange one (I can't figured out the manufacturer) which is not following conventional flashing commands ...
umh. i'm sorry for all these issues..
let me tell you that i don't think the Flash is burnt. usually they are pretty strong device, and when you read all bit high from the device is because there's something pulling-up the line.. maybe the iCE40 was not in reset state or something like that..
then also the device ID in the first trial looks a bit suspicious to me. i don't have my data here, but in my test the flash id was consistent with model stamped on the IC and the datasheet values.. the three first bytes, i mean (the other 14 are an unique random id..). a 32Mbit Flash NOR marked. 25Q03213 E40
let me know if you sort out your issues..
EDIT only rereading the thread, i did see you already solved your issue, and you found a "noname rom". so my answer above looks a bit out of context.. BTW me, i found a ROM with already a firmware inside for a Cisco Switch.. i really believe the assembly house made a good price only because has offered random stuff as parts for the design..
No worries, it is not your issue, but I think I will email gnarlygrey to figure out which flash chips was on my delivered boards since FlashID of those was unkown to me, and I'm fluent with those since years in other designs, Winbond, BergMicro, etc., even some Cypress FRAM.
I used an ICE40 for my first FPGA project and it worked very well.
It was for when I needed 16 channels of very precise timing. Something I wasn't able to do on an MCU.
Just got mine....
Friday Evening in the UK, forgot to make the account in advance.
Seems like I may not get to do anything over the whole weekend unless they activate it somehow today
theorically i couldn't believe that registering user and "releasing" free licenses for the THEIR sw to sell THEIR IC would be a manual task for an established corporation involved in the semiconductor market in 2017 (and yet to be so interesting to chinese, that the US government decided to forbid the deal), yet....
...with Latticesemi, i often get the feeling of "we do business like a Public Administration.." or something like that :-)
to Lattice guys, don't take it personally, of course! you do lot of great stuff, BUT you could do a bit better! think positive!
PS of course, not being ENG native, don't know if i convey the idea well enough.
Yay, they got their shit together and I managed to get a download.
Whats the deal between Lattice and Mentor / LSI?
"I verify that I am not an employee of Cadence Design Systems, Mentor Graphics Corporation, or Magma Design Automation "
I've finally got iCEcube2 working (MultiArch gave me some problem with X11 resolution been reset to 800x600, but I fixed that).
I've done some pratice to revamp my Verilog knowledge, not done any since a year, I modified the RGB_LED_BLINK sample code, just as PoC, to get more Colors ...
Now it is alternate with also magenta/cyan/yellow/while ...
If someone wish to test it, here in attachment ...
Next step, find duty to this small board : maybe I2C slave peripheral !
I didn't check yet if UPDuino_IOX_20170908.tar is doing so ...
Maybe DMX output thru I2C ?
I think I must dream more about it ...
I've done some pratice to revamp my Verilog knowledge, not done any since a year, I modified the RGB_LED_BLINK sample code, just as PoC, to get more Colors ...
Now it is alternate with also magenta/cyan/yellow/while ...
If someone wish to test it, here in attachment ...
Seems like you forgot to include the Project source ....
Would you mind to reupload
/Bingo