search

ZipCPU / arrowzip

A ZipCPU based demonstration of the MAX1000 FPGA board
21 stars 5 forks source link

Flash erase not recognizing finished erase #7

Closed NeuerUser closed 5 years ago

NeuerUser commented 5 years ago

Hi Dan

As you already mentioned, there is an issue with the flash controller not recognizing the finished erase cycle. I thought I could make sense to follow that issue with a separate issue. So, here is the info:

$ ./wbregs version
00600014 ( VERSION) : [....] 20190309
$ ./wbregs buildtime
00600000 (BUILDTIME) : [..GC] 00114743
$ ./zipload -v -r ../board/hello
ZipLoad: Verbose mode on
Halting the CPU
Loading: ../board/hello
Sending to flash: 01000000-01000134
Sending to flash: 01000134-01004a54
ERASING SECTOR: 01000000
Erasing sector: 000000

[not finishing at all even after 20 min]

$ ./zipload -v -r ../board/hello
ZipLoad: Verbose mode on
Halting the CPU
Loading: ../board/hello
Sending to flash: 01000000-01000134
Sending to flash: 01000134-01004a54
Writing page: 0x01000000 - 0x010000ff
Writing page: 0x01000100 - 0x010001ff
[...]
Writing page: 0x01004900 - 0x010049ff
Writing page: 0x01004a00 - 0x01004aff
Clearing the CPUs registers
Setting PC to 01000000
Starting the CPU
CPU Status is: 0000000f

A second start then recognizes that the flash is erased and starts writing.

ZipCPU commented 5 years ago

This should be fixed in the current repo by the line line "flashcfg_data = flash_data" in main.v. Please double check that you have this line, git pull otherwise, and let me know if this is still an issue.

NeuerUser commented 5 years ago

Yes, I can confirm that this line is in main.v. And the version and buildtime show that this design is really loaded on the board.

ZipCPU commented 5 years ago

Looking over this again, it looks like I read it too fast.

Can you provide a copy of whatever's going on in the netuart output when the design fails?

Thanks!

Dan

NeuerUser commented 5 years ago

yeah, tons of 

< R
> Rffffffff
< R
> Rffffffff
< R
> Rffffffff
< R
> Rffffffff
< R
> Rffffffff
< R
> Rffffffff
ZipCPU commented 5 years ago

Ok, that means its still going. It's likely in the process of verifying the erase, or perhaps checking if the next sector needs to be erased.

Specifically, "R" is a command from the host to the device, asking it to read either the same address or the next address (depending on the start of the operation. The device responds with "Rffffffff" saying that it has read the value, and it is an 0xffffffff

So ... it's working, just slowly.

ZipCPU commented 5 years ago

I'm going to close this "flash" issue as well. The design is worked as it was intended, it is just horrendously slow across the debugging bus. I'd like to come back and speed it up, but that should really be filed under another issue.