jbush001 / NyuziProcessor

GPGPU microprocessor architecture

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

00000000 Did not get ack for load memory, got c8 instead

aeteijeiro opened this issue · comments

Board: DE2-115
OS: Ubuntu 20.04.7 LTS virtual machine, in VirtualBox

Hi Jeff,

I am attempting to run the run_fpga script for the blinky test, but I get the following output:

ping target.
_loading [ ] (0%)
00000000 Did not get ack for load memory, got c8 instead
182 BAD_COMMAND bytes seen, last was c8
Ping return seen.
_loading [ ] (0%)
00000000 Did not get ack for load memory, got c8 instead
182 BAD_COMMAND bytes seen, last was c8
Ping return seen.
_loading [ ] (0%)
00000000 Did not get ack for load memory, got c8 instead
182 BAD_COMMAND bytes seen, last was c8
Ping return seen.
_loading [ ] (0%)
00000000 Did not get ack for load memory, got c8 instead
182 BAD_COMMAND bytes seen, last was c8
Ping return seen.
_loading [ ] (0%)
00000000 Did not get ack for load memory, got c8 instead
182 BAD_COMMAND bytes seen, last was c8
Ping return seen.
_loading [ ] (0%)
00000000 Did not get ack for load memory, got c8 instead
183 BAD_COMMAND bytes seen, last was c8
Ping return seen.
_loading [ ] (0%)
00000000 Did not get ack for load memory, got c8 instead
50 BAD_COMMAND bytes seen, last was c8
Cannot fix connection, no ping from board received.
Try resetting the board (KEY0) and rerunning.

I get this output even after hitting KEY0 and rerunning. I am using an FTDI RS-232 cable, and I have had the same problem with multiple past builds as well as the most recent one. I have been able to debug other issues with my computer, but for this one I have no idea where to begin - can you please point me in the right direction?

This is a bit odd.

The ROM bootloader is sending back 0xc8, which it does when it doesn't recognize a command. However, it does look like it responded to the initial and subsequent pings (0xc4). This suggests the serial port is configured properly and working on both ends, as, if it wasn't, the host side would timeout without seeing a ping response at all, or it wouldn't see a valid error response.

When you say " I have had the same problem with multiple past builds as well as the most recent one."? Are you saying you rolled back to earlier commits to see if this was a recent regression? Have you ever been able to get this setup to work? And, to double check: have you made any other changes to the project source code in the process of bringing this up?

Thank you for your reply Jeff. This is my first time working with the Nyuzi platform, so I have never gotten it working before. I did checkout several past commits that appeared to be working judging from comments in forums, and I resynthesized and programmed the board for each commit, to no avail.

The only change I made was to software/bootrom/boot.c and tools/serial_boot/serial_boot.c to lower the baud rate to 115200 as suggessted by a comment in one forum, but that didn't work so I changed it back. Even then, the reason I changed it to begin with was because of this error code (so in short, no I didn't change the source code).

Thanks for the clear description. Unfortunately, I don't currently have a good theory why it is failing like this. One approach to debug might first be to add a bit more back-and-forth communication between software/bootrom/boot.c and tools/serial_boot/serial_boot.c. For example perhaps boot.c could send the bad command byte it got, which might give a clue where the protocol is going wrong. I'm not sure how comfortable you are with that kind of debugging.

I haven't done it before, but there is a first time for everything. I could try it for a few days and get back to you?

Yeah, absolutely! Unfortunately it's a bit hard for me to debug directly, but I'm happy to try to help answer questions.

Hi Jeff, I got it working! I experimented with the serial_boot.c file with a logic analyzer to figure out what was going wrong, and realized that I had not rebuilt the project correctly the last time I tried to change the baud rate (building from source is something I am still mastering). I'm sorry about that.

So anyways, lowering the baud rate to something that I knew my computer could do (115200), like you suggested in one of your readme files, did the trick. Thanks for pointing me in the right direction.

Nice work! Debugging the boot loader is always tricky, and, because of the way this is compiled into the hardware, the build system is a bit fragile and doesn't always pick up changes cleanly. I'm glad to hear you were able to get it working. :)