Open Erhannis opened 5 years ago
Wait, no - after reupdating tinyprog (it said everything was already up to date), I tried again and it started to work, but then errored out on phase 2, as shown below:
erhannis@mnode6:~/3dPrinting/created$ tinyprog --update-bootloader
TinyProg CLI
------------
Using device id 1d50:6130
Only one board with active bootloader, using it.
The following update:
New Version: 1.0.1
Notes: Updates USB VID:PID to fix issues with APIO not recognizing the board.
is available for this board:
/dev/ttyACM0: TinyFPGA BX 1.0.0
UUID: c891d325-51c8-4372-bc74-5de497c7379f
FPGA: ice40lp8k-cm81
Would you like to perform the update? [y/N] Y
Fetching stage one...
Programming stage one...
Programming and Verifying: 100%|██████████| 135k/135k [00:03<00:00, 42.2kB/s]
...Success!
Waiting for stage one to reconnect....connected!
Fetching stage two...
Programming stage two...
Programming and Verifying: 1%|▏ | 4.10k/299k [00:01<01:23, 3.51kB/s]
Traceback (most recent call last):
File "/usr/local/bin/tinyprog", line 11, in
Further attempts yield the following:
erhannis@mnode6:~/3dPrinting/created$ tinyprog --update-bootloader
TinyProg CLI
------------
Using device id 1d50:6130
Only one board with active bootloader, using it.
All connected and active boards are up to date!
That makes me concerned that my board is only half programmed. Anybody know?
Hmmmmm. Trying to upload a program eventually timed out in
144.7 s apio upload Error: board TinyFPGA-BX not connected
So I disconnected and reconnected the device. The power LED came on, but not the boot LED. (The boot LED had previously been pulsing.) Trying to update the bootloader resulted in the following:
erhannis@mnode6:~/3dPrinting/created$ tinyprog --update-bootloader
TinyProg CLI
------------
Using device id 1d50:6130
No port was specified and no active bootloaders found.
Activate bootloader by pressing the reset button.
Pressing the reset button made the boot LED glow dimly while I held down the button, but it stayed off when I let the button go.
So is my device bricked now, or what?
I have the same issue you describe in your second comment, but luckily read your issue before trying again to upgrade my bootloader. My bootloader still seems intact, but trying to program the board with the demo project gives the same error (tried with multiple versions of tinyprog, both as user and root on an up-to-date Archlinux (4.20.11-arch1-1-ARCH) with python 3.7.2)
$make sudo-prog
Executing prog as root!!!
sudo tinyprog -p top.bin
TinyProg CLI
------------
Using device id 1d50:6130
Only one board with active bootloader, using it.
Programming /dev/ttyACM0 with top.bin
Programming at addr 028000
Waking up SPI flash
135100 bytes to program
Programming and Verifying: 14%|█▏ | 19.2k/135k [00:01<00:08, 13.5kB/s]
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/tinyprog/__init__.py", line 51, in to_int
return ord(value)
TypeError: ord() expected a character, but string of length 0 found
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/tinyprog", line 10, in <module>
sys.exit(main())
File "/usr/lib/python3.7/site-packages/tinyprog/__main__.py", line 401, in main
if not fpga.program_bitstream(addr, bitstream):
File "/usr/lib/python3.7/site-packages/tinyprog/__init__.py", line 505, in program_bitstream
return self.program_sectors(addr, bitstream)
File "/usr/lib/python3.7/site-packages/tinyprog/__init__.py", line 449, in program_sectors
max_length=256)
File "/usr/lib/python3.7/site-packages/tinyprog/__init__.py", line 411, in write
self._write(addr, write_data)
File "/usr/lib/python3.7/site-packages/tinyprog/__init__.py", line 397, in _write
self.wait_while_busy()
File "/usr/lib/python3.7/site-packages/tinyprog/__init__.py", line 327, in wait_while_busy
while to_int(self.read_sts()) & 1:
File "/usr/lib/python3.7/site-packages/tinyprog/__init__.py", line 53, in to_int
return int(value)
ValueError: invalid literal for int() with base 10: b''
make: *** [Makefile:56: sudo-prog] Error 1
I switched to Windows (with Python 3.7.2) and tinyprog v1.0.23 works just fine, I'll try updating the bootloader here and going back to linux. Updating the bootloader worked fine.
Only one board with active bootloader, using it.
All connected and active boards are up to date!
Both with pyserial and libusb options set it still does not work. It manages different amounts of progress before yielding that error, one time it got to "Reading 100%", but then printed "Failure!", other times it fails while erasing or programming with the error message above.
Ok, so I made it work under linux once: I modified TinyProg.cmd to re-issue the command if the read timeouts before receiving the appropriate number of bytes. Also TinyProg.wait_while_busy needs to discard exceptions.
This worked once, but every time I try it now, it errors out more often than not:
Programming and Verifying: 26%|██ | 34.6k/135k [00:00<00:02, 40.6kB/s]received less bytes than expected, retrying (0)
Programming and Verifying: 33%|██▋ | 45.1k/135k [00:02<00:06, 14.4kB/s]received less bytes than expected, retrying (0)
Programming and Verifying: 36%|██▉ | 49.2k/135k [00:03<00:11, 7.75kB/s]received less bytes than expected, retrying (0)
received less bytes than expected, retrying (1)
received less bytes than expected, retrying (2)
Programming and Verifying: 49%|███▉ | 66.3k/135k [00:06<00:09, 7.30kB/s]received less bytes than expected, retrying (0)
I'll include the two modified functions below.
def cmd(self, opcode, addr=None, data=b'', read_len=0, retrycounter=0):
addr_a = b'' if addr is None else struct.pack('>I', addr)[1:]
write_string = bytearray([opcode]) + addr_a + data
cmd_write_string = b'\x01' + struct.pack(
'<HH', len(write_string), read_len) + write_string
self.ser.write(bytearray(cmd_write_string))
self.ser.flush()
datar = self.ser.read(read_len)
if len(datar) == read_len:
return datar
else:
print(
f'received less bytes than expected, retrying ({retrycounter})')
return self.cmd(opcode, addr, data, read_len, retrycounter + 1)
def wait_while_busy(self):
while True:
try:
if not to_int(self.read_sts()) & 1:
break
except Exception as exc:
print("exception in wait_while_busy:", exc)
I'll wait for a proper fix now, no point in wearing out my flash any more
For anyone stumbling over this issue in the future: uninstall modemmanager from your system. The udev rules alone did not work for me, now it works flawlessly on linux too!
Fixing the bootloader is described here
I have modemmanager removed, yet seem to run into the same error as above (that ends line: ValueError: invalid literal for int() with base 10: b''
) while programming (tinyprog -p
).
(When updating bootloader it errors out with another error, so probably it doesn't get that far)
For anyone else finding this, see also https://github.com/tinyfpga/TinyFPGA-Bootloader/issues/18, https://github.com/tinyfpga/TinyFPGA-Bootloader/issues/43, and https://discourse.tinyfpga.com/t/error-while-updating-bootloader-invalid-literal-for-int-with-base-10/484/3 (the last one with some hints on fixing a bricked board if you know how to solder and have a SPI flash programmer, or something that can work that way).
The description for fixing the board at:
https://discourse.tinyfpga.com/t/bx-bootloader-bricked/852/3
(from the earlier comment -- https://github.com/tinyfpga/TinyFPGA-Bootloader/issues/42#issuecomment-468900157) contains a range of possible ways to reprogram the SPI flash, and links to other people's fixes.
Ewen
While following the instructions at https://tinyfpga.com/bx/guide.html , I typed the following and received the displayed response:
erhannis@mnode6:~/Documents/tinyfpga$ tinyprog --update-bootloader
Traceback (most recent call last): File "/usr/local/bin/tinyprog", line 11, in
sys.exit(main())
File "/usr/local/lib/python2.7/dist-packages/tinyprog/main.py", line 308, in main
check_for_wrong_tinyfpga_bx_vidpid() +
File "/usr/local/lib/python2.7/dist-packages/tinyprog/main.py", line 91, in check_for_wrong_tinyfpga_bx_vidpid
if m[u"boardmeta"][u"name"] == u"TinyFPGA BX":
TypeError: 'NoneType' object has no attribute 'getitem'
Anybody know why?