Can't program new TinyFPGA BX ~ 2023-08-22, possibly no metadata? #37
Comments
eyz
changed the title
eyz
changed the title
|
@eyz Confirming that I am running into this same issue. Received this board from Crowd Supply today. If you solve it, would be interested. looking at the code: Looks like these cmd are not working and meta is returning None. Maybe our boards didn't come with the meta json included? |
I suspect the bootloader is programmed (because tinyprog indicates it's there) but the metadata file wasn't uploaded. I wonder if it's a known issue for any of the boards produced. I ordered two more and would be overjoyed if they had the metadata on them, so I don't have to figure out how to upload the metadata myself. That said, if it's super easy to connect some SPI up and use an Arduino sketch to upload the metadata I would be up for it. |
|
@tinyfpga is there another TinyFPGA BX production run that includes these metadata files? |
|
@eyz I did a bit of hacking on the tinyprog project to bypass the meta check. This is only a temporary solution and will break your other fpga's if you do this. You have been warned! Find where tinyprog source code is at. should be under If you want to be extra safe, copy or fork the project somewhere and then run this python script directly instead of using the one in the path. (Note: I generated a UUID to avoid conflicts) |
Nice! It looks like you are simply hard-coding the expected metadata where it would normally be retrieved from the Tiny FPGA BX. Since I'm only using this one FPGA with tinyprog that's a completely acceptable solution. Great hack! If the USB ID is specific to the tiny FPGA BX maybe this could be a suitable workaround for others as well, such as if that USB ID is found it would simply drop this in if it couldn't be located, like a "use default metadata" flag. In my case, I found the file you patched in ~/.local/lib/python3.10/site-packages/tinyprog/init.py (for my user install) and /usr/local/lib/python3.10/dist-packages/tinyprog/init.py (for an old root install) on my Ubuntu 22.04.3 system - class TinyMeta(object):
def __init__(self, prog):
self.prog = prog
prog.wake()
# self.root = self._read_metadata()
self.root = {
"boardmeta": {
"hver": "0.0.0",
"name": "TinyFPGA BX",
"fpga": "ICE40LP8K-cm81",
"uuid": "4a300a6f-895a-44d3-b021-356c6b38b339",
},
"bootmeta": {
"bver": "2.0.0",
"bootloader": "TinyFPGA USB Bootloader",
"update": "https://tinyfpga.com/update/tinyfpga-bx",
"addrmap": {
"bootloader": "0x00000-0x28000",
"userimage": "0x28000-0x50000",
"userdata": "0x50000-0xFC000",
"desc.tgz": "0xFC000-0xFFFFF"
}
}
}Great idea! Thanks! A solid red light is a good red light (flashed successfully, thus solid red now) -
|
|
See https://github.com/tinyfpga/TinyFPGA-Bootloader#fpga-board-metadata for some context on the following if you want to dig in. Security page dumps from an older TinyFPGA BX boardI was successfully able to dump security pages 1, 2, and 3 to binary files from my older model TinyFPGA BX. However, when I tried to program them onto my new TinyFPGA BX (where they are blank, all default flash 0xFF) I saw no evidence of the security pages being updated, presumably because they are write-protected. I suspect there is some process to unlock the write-protection outside of tinyprog. Without this information I believe I cannot proceed further in correcting the security page metadata. What I modified to dump out the security pages from a TinyFPGA BX that is about 3 years old - def read_security_register_page(self, page):
data = self.cmd(self.security_page_read_cmd, addr=page << (8 + self.security_page_bit_offset), data=b'\x00', read_len=255) # Isaac debug
print("read_security_register_page", page, data) # Isaac debug
with open("tinyfpga-bx-security-page." + str(page), "wb") as security_page_file: # Isaac debug
security_page_file.write(data) # Isaac debug
return data # Isaac debug
#return self.cmd(self.security_page_read_cmd, addr=page << (8 + self.security_page_bit_offset), data=b'\x00', read_len=255)Dumped security pages resulted in - Security pages likely are write-protected, otherwise this could work to update themI tried reading back the binary dumps (above) and update the security pages on the newer board using this function, but no luck (probably due to write protection?) - def program_security_register_page(self, page, data):
self.write_enable()
self.cmd(self.security_page_write_cmd, page << (8 + self.security_page_bit_offset), data)
self.wait_while_busy() ^ I did not include the wrapper that calls this to attempt to re-program each security page, as it wasn't successful. This function is included in this GitHub comment for context only. No differences once flashed between old and new boards in pages outside of security page areaI also compared my older board with the newer board with the same user bit-stream flashed, and I only saw a difference between the security pages, not the rest of the pages being read during programming, as confirmed by outputting the raw bytes in the rest of the read function calls - def read(self, addr, length, disable_progress=True):
data = b''
with tqdm(desc=" Reading", unit="B", unit_scale=True, total=length, disable=disable_progress) as pbar:
while length > 0:
read_length = min(255, length)
data += self.cmd(0x0b, addr, b'\x00', read_len=read_length)
self.progress(read_length)
addr += read_length
length -= read_length
pbar.update(read_length)
#print("read",addr,length,data) # Isaac debug
return dataPhysical write-protection investigationFrom https://github.com/tinyfpga/TinyFPGA-BX/blob/master/board/TinyFPGA-BX-Schematic.pdf, perhaps this needs to be brought high to allow the security pages to be written? -
Datasheet for the AT25SF081-SSHD-B
|
|
@eyz According to https://github.com/tinyfpga/TinyFPGA-BX/blob/master/TinyFPGA%20BX%20Card%20Back.png pin 10 (H4|spi_io2|SPI Flash WP_B/IO2) looks like it might also be the same write protect pin. |
^ It looks like that net (circled in green) is pulled-up to 3.3 volts (circled in purple). In addition to the labeled circular WP pad on the back, it looks like solder pad # 27 on the back is the same net. Regarding the mention of pin 10 I think they mean labeled pad # 27, not the outside through-hole pin 10 on the edge of the board, see -
The datasheet states that the WP signal is active low, so I'd assume the pull-up means it's not hardware write-protected. Perhaps another layer of protection is preventing the security page area from being programmed -
At this point, I believe the security register lock bits have likely been set, which appears to permanently (one-time program) set the values in those pages, see -
Given this, I suspect those security page areas with the metadata may not be possible to change, even though the WP net is being pulled up high (which would otherwise disable the hardware write protection on the SPI flash chip) Here are the security lock registers (LB3-LB1) -
|
|
After doing some more research it does appear the fix is going to be a little harder.
|
Yep. I saw that at the end of yesterday, prior to my deep dive research today in this comment / thread. I'm now deferring to those here to come up with a solution, or possibly return these units for replacements that are programmed properly. I'm only using the BX personally, so I'm fine leaving that workaround in my tool chain for the foreseeable future, although the proper solution is certainly having the metadata stored properly on the physical hardware. |
|
I edited the init method as suggested and was able to program my board, but is there a way that I can program the needed metadata onto the board myself? |
Based on my extensive research in the thread above, it's extremely unlikely that you can program the metadata into the security protected portion of the SPI flash. My finding was that it's most likely locked when they program the firmware on the board as part of their programming workflow, and effectively read only in that area, thus you can't update it again. |
|
Should hack a solution in this driver to handle the broken boards? Maybe something like: if the query to the metadata fails, use this default json file. |
Right now this is the only board I'm working with... At some point if this isn't fixed in some way officially, I expect I'll do exactly that, --- if it can't get metadata, substitute in this metadata... quite a hack though. but the state of the software is already such that I have to hack around anyway to get apio and tinyprog to work on a mac. |
It's really only a hack for the toolset that integrates between the metadata in the secure part of the flash and tinyprog though. It was clearly a design decision, and this is where it breaks down in case the secure area gets locked on the flash unusable. Patching the software side is not horrible considering it can potentially be corrected if the manufacturer acknowledges the issue, and I'm fine if that is via any form of communication we can see here. I just got two more from Mouser a few days ago and I'll report back if they have the same issue, or if this batch I received it seems to be resolved. |
|
I believe the only true fix to this issue is to de-solder the the flash, reprogram it, and solder it back in place. |
If the flash security section is locked, then yes- that's the only solution that I'm aware of. Patching the software toolchain is way easier though, so unless you are really fond of working on boards (for fun?) and you also need to use a certified / checksum-verified toolchain from the original release, I don't recommend replacing the flash. |
|
I don't know anywhere near enough about USB, but it sounds like there are possibly different levels of problems with the latest batch of BX boards. (I got one via Mouser.) Mine, for example, fails to complete the USB initialization with the host, and so the host doesn't even get far enough to present a usable device for tinyprog to use. I filed a bug about it: |
|
I'm getting the "No metadata" error too. Bummed out. |
Yes, please. I'm a FPGA beginner, and it looks like I can't use this TinyFPGA BX board without hacking some source files. Thanks! |
|
Even after getting my TinyFPGA BX from Crowd Supply to program (by working around the no metadata bug), I noticed the 3v3 pin is actually 5v. This explains why the LED's are so insanely bright. The 3v3 regulator is not functional. If I can't even program it out of the box without hacking the programming software, something is wrong. How was this ever shipped? |
|
The company I work for has had this problem. Apart for the issues with the LDO, it seems that the AT25SF081 memory piece has been replaced by a revision AT25SF081B I made a branch of the tinyprog repo which includes an --atb switch to account for this discrepancy. It is nasty hack, but works until someone can find a way to automate this process. (There seems to be a SFDP record that is different from the original model, so maybe we could use that) Now, while it is true that security page 1 is locked from factory in these devices, it is possible to write the metadata that should be in page 1 in page 2, and the metadata for page 2 in page 3. Page 3 is usually empty, so this should suffice to enable the boards to be used. So, to program the security pages you can use the attached files (basically, extracted from an older batch tinyfpga) and use my forked tinyprog with the commands And then the --atb switch to program, to let the script to know it has to read metadata from these modified addresses These seem to have worked for us. Note: The page1 metadata includes an uuid that should be unique per board. I strongly encourage writing a new one per board. This simple online generator should generate random ones. |
|
This is great, Aarón: just tried your patch, and it worked: thanks! I patched it a bit further (PR issued--I wanted to be able to use all my BX using the same commands, so the -atb can be dropped once the fix is applied to a board). |
|
Cool! This is a nice patch, as at least normal operation can be done as normally. Thanks! I think some automation should still be possible to tell chips apart and not require the --atb flag at all. It's annoying that they did not update the DeviceID command, which is for this case specifically. Bur probably the SFPD records can be used for this, even if it's in a very naïve and hacky way, |
|
hi @aacuevas , THanks for all of this, is there a place to download the final exe of the programmer? Can you also elaborate more on the LDO issue making the led blinding and if it can also be fixed. ok found the this for the LDO will try it out: But question about a compiled exe for the programmer still reamin as not yet to familiar with python stuff |
|
Did anyone get a board without this issue? If so, when did you order it, and when did you receive it? |
I've also got this issue - came through in the latest Crowdsupply batch, received a week or two ago. Tried emailing tinyfpga but not heard anything back. |
|
Received two BX boards from Mouser late August 2023 and just now getting to them, both have no metadata issue |
That's great news. Also, can you confirm the voltage on the 3.3 volt and 5 volt rails? I think that was the only other concern. Additionally, if you have any markings from the metadata or physically please let us know the batch numbers or whatever you can applicable from your builds. |
sorry 'No Metadata' issue |
|
Hi Aarón, thanks a lot for figuring that out. Your solution is working perfectly. I'm a little bit disappointed about Crowd Supply, that there is no patch or notice about the issue(s) with some of the modules... Many thanks again Aarón for your patch. Perfect work.... |
|
@AaronJackson Just ran into this issue as well, but unfortunately i seem to not be able to get to work with your fork/hack. I'm getting:
Whenever I try to write security page 3, or a .bin. Any guidance is much appreciated. |
|
@taylor-hartman there are two Aarons in this thread, think you mean @aacuevas I am useless and a newb and gave up as soon as I ran into the issue. Maybe I'll try again eventually but so far it was a waste of $60 😭 |
I'll withhold my opinion of this situation and just say if you follow this thread carefully, you will have a good chance of getting your board working. If not it's a 60 dollar lesson you've learned. |
|
Sure feels like we're on our own. Who's going to fork this and fix the remaining issues, and start a new board run? |
|
Unable to upload here too, system report doesn't see the board, quite disappointing there was never a statement on this and crowdsource keeps selling them |
|
i am currently working on a pi pico uf2 that will be able to reprog the spi flash. to be able to be recognized by tinyprog. it will require either a soic8 programmer clip or some minor soldering to work. more to come in the next week/month. also, my boards came with the 5v0 LDO instead of the 3V3.... SMH. i dont even want to see what the EX board is going to be like... |
Quite unfortunate, to be honest I am tempted to just returning this and trying the new batch as it seems like a solid bit of effort. But then who knows if the new batch will be any better |
|
I have now tried this in windows and the errors are different though I am confused about the cause |
|
Would anyone be up for a full PCBA (gerber and BOM file) project export for these with one or more common PCBA vendors, including any recent passive swap-outs and zero firmware flashing? I think we need to take this over, because there have been no updates from the original project owner on this for some time, and power regulator and PROM flashing have had problems, as documented in this GitHub issue |
|
Let's try to ensure the next round of boards won't have 5V on the 3.3V pin (#39 (comment)) due to a Per Mouser, there is a batch expected out around May 2025. If these are also botched, let's try and get PCBA files to produce these instead. If anyone has a contact for who is producing the next run, could you please reach out to them and let them know of these two critical issues? A Mouser contact here who is on Github would also be appreciated to share the findings. |
I believe the flash overwriting thing only happened to some people, as it worked for me after cutting off the extra pin to make it 3.3v, as well as some others, so it's worth trying. |
Maybe these were two different events that could have overlapped, with some of the 5V on 3.3V pin boards not having been one-time programmed with incorrect metadata; perhaps there were multiple production runs with different conditions. Thanks for the insight |
|
Ola @aacuevas, |
I just received a new TinyFPGA BX which was ordered through Crowd Supply and shipped by Mouser. I cannot program this new one, but I have an older TinyFPGA BX that programs fine with the same tools.
The power LED is solid red, and the boot LED is pulsing red (during all commands captured below)
Any tips on how to proceed? The messages seem to imply there's a bootloader, but maybe no metadata. Do I need to manually write metadata to the board somehow?
I have many micro-controller boards on hand and in theory could send some SPI commands or similar if needed to resolve this. I believe I have a TinyFPGA programmer as well, if applicable.
The text was updated successfully, but these errors were encountered: