Cannot upload neorv32_exe.bin for demo CFS on NexysA7

[JC-LL]

Describe the bug cannot upload neorv32_exe.bin for demo CFS with nexys-a7-test-setup. The upload process freezes

To Reproduce Switch IO_CFS_EN=true in neorv32_top.vhd then restart synthesis : cd neorv32-setups/vivado/nexys-a7-test-setup/ vivado -mode tcl -source create_project.tcl # and push bitstream cd neorv32/sw/example/demo_cfs make exe run neo on FPGA and interrupt the boot process to 'u'pload neorv32_exe.bin (me : using gtkterm or minicom) the process freezes

Expected behavior The upload should finish.

Screenshots

[umarcor]

FTR, we are also having issues with the bootloader on an Arty-A7. For now, we are disabling the bootloader so that the app is started straightaway. However, that requires resynthesising if we want to change the software.

/cc @Unike267

[stnolting]

Hey @JC-LL!

Hmm this problem sounds familiar...

Does the upload only freeze when you upload your specific program? Can you try compiling a simpler one (e.g. sw/example/hello_world) and try uploading that?

I guess your executable is larger than 4kB, which is a known problem with GTKTerm: https://github.com/stnolting/neorv32/pull/215#issuecomment-975836572

Can you try a different terminal program like cutecom or picocom?

@umarcor

Which terminal program are you using?

[JC-LL]

Hello @stnolting !

First, congrats for this interesting project.

Yes, smaller binary programs run fine, like the LED demo provided, that works like a charm.

Gtkterm is the issue here. However, I'v just tried picocom, that also seem to freeze (I hope I have used it correctly for sending the code). On my Linux Mint, cutecom does not seem to simply react when booting Neorv32...

I'm still investigating.

Update : Ok, cutcom now reacts, but gives this :

CMD:> u
Awaiting neorv32_exe.bin... <0x07>
ERR_EXE

[stnolting]

First, congrats for this interesting project.

Thank you very much! :)

I'v just tried picocom, that also seem to freeze (I hope I have used it correctly for sending the code). On my Linux Mint, cutecom does not seem to simply react when booting Neorv32...

Have you tried this one? (from https://github.com/stnolting/neorv32/pull/215#issuecomment-1827396315) $ sudo picocom /dev/ttyUSBx -b 19200 --send-cmd="ascii-xfr -s -n"

Ok, cutcom now reacts, but gives this : [...] ERR_EXE

This is a signature error, so the first 4 bytes are not the expected ones:

https://github.com/stnolting/neorv32/blob/8e5223485da326448500f97e4c3ebbe45f845470/sw/bootloader/bootloader.c#L202-L205

Are you uploading the right executable file (neorv32_exe.bin and not main.bin)?

[JC-LL]

Things are a bit weird. My first attempt with picocom (with the correct neorv32_exe.bin) went wrong...

I just retried, and I finally managed to upload the executable. Hurray !

Well...not perfect still.

CMD:> u
Awaiting neorv32_exe.bin... 
*** file: /home/jcll/JCLL/exp/neorv32/sw/example/demo_cfs/neorv32_exe.bin
$ ascii-xfr -s -n /home/jcll/JCLL/exp/neorv32/sw/example/demo_cfs/neorv32_exe.bin
ASCII upload of "/home/jcll/JCLL/exp/neorv32/sw/example/demo_cfs/neorv32_exe.bin"

*** exit status: 0 ***
OK
CMD:> e
Booting from 0x00000000...

Error! No CFS synthesized!

[stnolting]

I just retried, and I finally managed to upload the executable. Hurray !

Great to hear! 🎉

Well...not perfect still. [...] Error! No CFS synthesized!

Seems like the CFS was not enabled before synthesizing. You need to set the according configuration generic to "true" in your instance of the processor:

https://github.com/stnolting/neorv32/blob/8e5223485da326448500f97e4c3ebbe45f845470/rtl/core/neorv32_top.vhd#L139

[JC-LL]

That surprised me much because, IO_CFS_EN was indeed correctly set to true...That was my initial goal ! I probably made a mistake renaming bitstream. I'll try again tomorrow.

Update : "Tomorrow will soon come" (new James Bond film ?)

It works. It seems that modifying generic definition (which I did) is not sufficient. I don't see why. It really needs to be set in the generic map, while instanciating neorv32_top in neorv32_test_setup_bootloader.vhd. Better practice for sure, but weird that it didn't work at first try.

For completeness, here is the uart log :

CMD:> u
Awaiting neorv32_exe.bin... 
*** file: /home/jcll/JCLL/exp/neorv32/sw/example/demo_cfs/neorv32_exe.bin
$ ascii-xfr -s -n /home/jcll/JCLL/exp/neorv32/sw/example/demo_cfs/neorv32_exe.bin
ASCII upload of "/home/jcll/JCLL/exp/neorv32/sw/example/demo_cfs/neorv32_exe.bin"

*** exit status: 0 ***
OK
CMD:> e
Booting from 0x00000000...

<<< NEORV32 Custom Functions Subsystem (CFS) Demo Program >>>

NOTE: This program assumes the _default_ CFS hardware module, which implements
      simple data conversion functions using four memory-mapped registers.

Default CFS memory-mapped registers:
 * NEORV32_CFS->REG[0] (r/w): convert binary to gray code
 * NEORV32_CFS->REG[1] (r/w): convert gray to binary code
 * NEORV32_CFS->REG[2] (r/w): bit reversal
 * NEORV32_CFS->REG[3] (r/w): byte swap
The remaining 60 CFS registers are unused and will return 0 when read.

--- CFS 'binary to gray' function ---
0: IN = 0xb11ddc17, OUT = 0xe993321c
1: IN = 0x59781258, OUT = 0x75c41b74
2: IN = 0x3d54c7e1, OUT = 0x23fea411
3: IN = 0x10be1395, OUT = 0x18e11a5f

--- CFS 'gray to binary' function ---
0: IN = 0x8b578493, OUT = 0xf265071d
1: IN = 0x037ef751, OUT = 0x0254a59e
2: IN = 0x6f038afb, OUT = 0x4a02f352
3: IN = 0xd5c05f75, OUT = 0x997f95a6

--- CFS 'bit reversal' function ---
0: IN = 0x1bfc9c22, OUT = 0x44393fd8
1: IN = 0x876b9bde, OUT = 0x7bd9d6e1
2: IN = 0x76141b16, OUT = 0x68d8286e
3: IN = 0x5ba2940d, OUT = 0xb02945da

--- CFS 'byte swap' function ---
0: IN = 0x2d45231c, OUT = 0x1c23452d
1: IN = 0xadfa166f, OUT = 0x6f16faad
2: IN = 0x09c7bf74, OUT = 0x74bfc709
3: IN = 0x3b014c60, OUT = 0x604c013b

CFS demo program completed.

[stnolting]

It works. It seems that modifying generic definition (which I did) is not sufficient. I don't see why. It really needs to be set in the generic map

Right, the instantiation will override the defaults from the entity declaration.

For completeness, here is the uart log

:+1: :rocket:

[Unike267]

Hi @stnolting

Which terminal program are you using?

We are using cutecom terminal. The problem was that the type of file that we set in cutecom was Script and if you set this type the cutecom responds with ERR_EXE.

So to fix it you must set Plain type. As shown in the following image:

/cc @umarcor

[stnolting]

Thanks for the information!