FROM_BLINKER_TO_RISCV: no terminal output for step22.v on iCEstick about learn-fpga

[BrunoLevy]

It really looks like mismatched BAUD rate but can be something else: by default, I have configured it to run at 1000000 (1 million) bauds. Some hw/OS combinations may not support it, so the first thing I'd try is changingit to a more standard 57600 bauds (line 456 of step17.v). Please tell me what it gives, hope that it will work. If it works I will add a "troubleshooting" section.

[sei-jgwohlbier]

Thanks for the comment. I tried several baud rates, setting them in both step22.v and terminal.sh, and I don't get the expected animation. I mostly get junky pixelation with brown, yellow, and red. Baud rates tested include 9600, 38400, 57600, 115200, 128000, 256000. It is the same behavior that I see for the default baud rate.

Is the animation supposed to run in a loop? In my case it terminates after running for some time. Could this be a debugging clue?

All other steps work for me, it is only 22 that does not.

[BrunoLevy]

That's weird, normally it is supposed to go on a loop (but if the tty is in a weird state this could also explain).
Which OS/tty emulator are you using ?
The demo uses RGB ansi codes to generate big pixels, some terminal emulators do not support them.
Maybe you can try another tty emulator ?
Another explanation if is iceprog did not sucessfully write the data into the SPI flash (but I doubt it).

Did you try the subsequent steps ? In particular, does pi.c works ? (this one stresses both the processor and the SPI flash access). Then you can test also tinyraytracer.c (it also uses RGB ansi codes, but sends fewer data, then it will be interesting to see what comes out). Another possibility is writing a small program that draws a testing pattern using ANSI codes and see whether it is displayed.

[wohlbier]

Everything with step23.v and step24.v works as expected, including tinyraytracer.c, so I'm doubtful that there is any issue with the OS/tty emulator. (I'm in a docker container with Ubuntu using picocom.)

If nobody else is hitting this maybe it isn't worth pursuing. I guess the next step I'd take would be to inspect the line by line differences running steps 22 and 23, since the latter works but the former does not. Below is the image I get, btw.

For reference, the steps I'm taking are

iceprog -o 1M ~/learn-fpga/FemtoRV/FIRMWARE/EXAMPLES/DATA/scene1.dat
cd /home/fpga-user/learn-fpga/FemtoRV/TUTORIALS/FROM_BLINKER_TO_RISCV
cd FIRMWARE/
make clean
make ST_NICCC.bram.hex
cd ../
./BOARDS/run_icestick.sh step22.v
cd ../
./terminal.sh

[BrunoLevy]

To figure out what's going on, would you test another program with the same design ? For instance, mandel_C.c draws graphics using ANSI sequences, it can be run as follows:

cd /home/fpga-user/learn-fpga/FemtoRV/TUTORIALS/FROM_BLINKER_TO_RISCV
cd FIRMWARE/
make clean
make mandel_C.bram.hex
cd ../
./BOARDS/run_icestick.sh step22.v
cd ../
./terminal.sh

[wohlbier]

Hi Bruno,
That one works fine. So it has to do with the scene1.dat somehow. (You have an extra cd ../ in your steps.)

[BrunoLevy]

That's weird, I do not understand what's going on then,
What is the output of

iceprog -o 1M ~/learn-fpga/FemtoRV/FIRMWARE/EXAMPLES/DATA/scene1.dat

Normally it should say that it erases/writes/checks 10 blocks of 64k, is it the case ?

[wohlbier]

fpga-user@lx-turtledove:~/learn-fpga/FemtoRV/TUTORIALS/FROM_BLINKER_TO_RISCV$ iceprog -o 1M ~/learn-fpga/FemtoRV/FIRMWARE/EXAMPLES/DATA/scene1.dat
init..
cdone: high
reset..
cdone: low
flash ID: 0x20 0xBA 0x16 0x10 0x00 0x00 0x23 0x80 0x80 0x52 0x03 0x00 0x81 0x00 0x17 0x08 0x05 0x18 0x47 0xD9
file size: 639976
erase 64kB sector at 0x100000..
erase 64kB sector at 0x110000..
erase 64kB sector at 0x120000..
erase 64kB sector at 0x130000..
erase 64kB sector at 0x140000..
erase 64kB sector at 0x150000..
erase 64kB sector at 0x160000..
erase 64kB sector at 0x170000..
erase 64kB sector at 0x180000..
erase 64kB sector at 0x190000..
programming..
done.                 
reading..
VERIFY OK             
cdone: high
Bye.

[BrunoLevy]

Thank you !

Then it is probably on my side, I have probably broken something when updating the tutorial a while ago, I will triple check and come back to you.

[wohlbier]

Yeah, if we could get someone to reproduce it I wouldn't feel so crazy.

…

On Sat, Jan 6, 2024, 1:05 PM Bruno Levy ***@***.***> wrote: Thank you ! Then it is probably on my side, I have probably broken something when updating the tutorial a while ago, I will triple check and come back to you. — Reply to this email directly, view it on GitHub <#90 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDU3JRJ5QNF4JLFXDS4HT3YNGG75AVCNFSM6AAAAAAUH7QHY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZG43TANRSG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[BrunoLevy]

I confirm something is also broken on my side (which is good news, we'll be able to figure out what's going on)

• execution from SPI flash works (steps 23, 24)
• ST_NICCC works with step 24 (it is why I could not reproduce the issue: I'm stupid, I was testing with step 24, excuse me for the time lost checking baud rate etc...)
• ST_NICCC does not work with step 22
• mandel_C works with step 22 (as you observed also)

Now investigating...
It is super weird, the only differences between step 22 and step 24 are :

• in step 24, additional wait state when we execute code from SPI flash
• in step 24, reset address jumps directly to SPI flash instead of BRAM

[BrunoLevy]

got it, the generated executable for ST_NICCC fills 99% of the 6Kb BRAM, it does not leave enough space for the stack, that quickly overwrites code and/or other variables.
A possible fix: in FIRMWARE/Makefile, replace -O2 with -Os in RVCFLAGS (then ST_NICCC's BRAM usage drops to 80% and everything works).

Thank you so much for having noticed that.

I don't know why I haven't seen that before (maybe I have added a little bit of stuff in ST_NICCC and tested it only with step24).

[BrunoLevy]

I pushed a new version (removed wireframe mode from ST_NICCC, now everything fits even with -O2).
I added also blinking lights, so that one can see whether it crashed or it is still alive.

[wohlbier]

Confirmed that the fix is working! Kudos to you for following up on an issue that is nearly a year old! Thanks!

Great tutorial, by the way. It really taught me a lot.